Презентация Сергея Ткачук на встрече КУЛ-ИТ 22 августа. Сергей делился опытом, как поднять узнаваемость своей команды в компании, чтобы быть известным внутреннему и внешнему заказчику, рынку в целом и получать лучшие проекты :).
Мамонт. "Командная аллергия: как ее избежать когда в команду приходит новый ч...
Sell team results_ru
1.
2.
3.
4.
5. Новости - фундамент Sergiy Tkachuk serg.tk{at}gmail.com http://sergtk.com Новости = Блоги + уведомления Блог – облегчает снаружи знакомство с командой Уведомления – напоминать о своей команде
6. Новости - аудитория Sergiy Tkachuk serg.tk{at}gmail.com http://sergtk.com Менеджеры Разработчики Команда Пользователи / Заказчики
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
Editor's Notes
Вам почти все известно . А я собираюсь рассказать о своем опыте .
Целевая аудитория : TL и все, кто заинтересован в разработке полезного ПО .
Опыт: “ А что, у нас в компании есть такая команда ?” до “Hey, heard many about you, glad to meet you”. Часто бывали ситуации, когда я человека вижу первый раз, но четко понимаю, что он меня уже знает Может быть применимо к командам, активность которых полезна или может быть полезна для других команд в компании. BB – big bosses
Карьерное продвижение – как пример, у меня были возможности. Простое решение вопросов, связанных с вашей командой : например около 25 PM и TL знакомств буквально за 1-2 дня для нового человека . Не все проекты используются конечными пользвателями – этого гораздо больше, чем кажется на первый взгляд. Продвижение : что разработчики уже сделали, а также что МОГУТ .
Ничего страшного, что много подписок – это одноразовое действие, потом подписчики будут получать уведомления. Негативный пример одного блога: новый человек в компании, релиз продукта, появление third party.
Не спешите! Первый пост – очень важно, что бы вы сами поняли, о чем именно вы собираетесь писать в новостной ленте .
Сомнения публиковать или нет? – не публиковать или опубликовать в другом месте. Блог должен читаться легко, без особого напряжения.
Другие команды имеют похожие проблемы . Например полезные новые практики в разработке, изменения в рабочем процессе. Это поможет уменьшить использование фразы “ нужно поискать в почте ”
Другие команды имеют похожие проблемы . Например полезные новые практики в разработке, изменения в рабочем процессе. Это поможет уменьшить использование фразы “ нужно поискать в почте ”
Кейс : AEs начали между собой обсуждать как они используют фичи с опциями – я очень много узнал о том, что нужно пользователям .
Упорядоченное по приоритетом и доступное краткосрочное планирование: менеджеры не в курсе всех деталей, но эта информация открыта и актульна и вы можете объяснить в случае необходимости. Это сильно увеличивает доверие, что особенно важно, если вы инициируете новые проекты. Отчитывайтесь раз в неделю или две непосредственному босу обычными словами – не формально , как если бы вы объясняли усно. Где-то через 2 месяца я начал получать вопросы, поскольку босу стало понятно, что отчеты полезны и это позволяется быстро входить в курс дела о том, что происходит внутри команды . Благодаря этому когда у меня была командировка, мы обсуждали только идеи новых проектах.
Интерпретация планирование. В моей ситуации планирование усложнялось следующими факторами: 1. большое количество заказчиков – изменение приоритетов. 2. Много старого кода плохого качества. 3. Исследования, которые в принципе всегда плохо планируются. Планирование заставляет вас создавать правильные привычки (планировать ).
Направление улучшений : “ важно для вас ” - “ текущий статус ”. Я получил 90% ответов со второй попытки, с первой, когда была другая форма – 15%.
«У вас спросили - дайте ссылку на публикацию и предложите подписаться.» - Также облегчаете жизнь тем, кто задал вопрос, они потом просто сбрасывают ссылку по цепочке коммуникации, ну и вас пиарят Держите дела в порядке, чтобы иметь возможность дать полезную ссылку в любой момент, чтобы заинтересованные люди могли просмотреть информацию о команде в любой момент .
Ярко выражается ориентация на конечный результат пользователя (не проекта) . – не проходит “А в ы же говорили другое, мы это и сделали». Объяснять команде важность конкретных фич для заказчика – простые фичи могут быть на много важнее, чем «крутые и навороченные» ( пример: progress bar vs. new research feature. )
“ Спрашивать боссов о новых проектах ” не работает : Договоритесь с боссам о выделяемом времени на новые проекты – здесь ключевым является доверие. Ближе к заказчику, постепенно, сразу не получится – «разные языки». Напряжение на всех между вами и заказчиком. Пример с PjM -ами – они не заинтересованы с вами сотрудничать – риски.
Вам нужно самому проявлять активность – это не то, что нравится делать инженерам, это довольно необычный род деятельности в ИТ-компании . Эффект продвижения будет виден через 0.5-1 год – in my case for company of 1000 people and SoftDev related about 300-500 – just after 2 years.
Непосредственное общение с продавцами , внешними заказчиками – это особенно важно, если промежуточные звенья коммуникации напрямую не особо заинтересованы в результатах вашей команды ( например PjM не заинтересованы в reasearch-market, высокие риски ). Даже стоит взять продукт знакомый заказчику, вставить туда одну только вашу фичу и попросить попробовать . Отслеживайте, действительно ли результаты вашей команды используются конечными пользователями – вы либо узнаете, что ваша фича используется (мотивация), либо узнаете, почему не используется и будет возможность попыться исправить .