Мотивированность команды разработчиков в стартапе или разработка застопорилась

Andrey
В недавней беседе с фаундером ВПути мы попытались составить некоторые пункты, которые могут помочь в мотивированности команды и в достижении технических результатов. Многие начинающие ИТ-предприниматели, когда переходят из личного кодинга в управление командой из трёх-четырех и более человек, сталкиваются с проблемой контроля выполнения поставленных задач. Кто – то этот процесс проскакивает, а кто – то застревает и топчется на месте.
Сам я прошел путь топтания и получил опыт потери почти более года, когда мы разрабатывали ярмап 2. Год безуспешной работы, затем шесть месяцев продуктивной работы, которые и дали основной результат.Итак, если вы столкнулись с хроническим затягиванием сроков, не хотите этого в будущем, и с вашей командой не все так хорошо
Исходим из того, что в команде более трех программистов, а срок выполнения уже отчаянно потерян.

Что не работает:

– Не пытайтесь подкупить команду, предлагая повышение зарплаты, премию или бонус, если продукт все-таки должен быть завершен в заново оговоренный срок. Скорее всего, команда хочет выполнить, но по каким-то причинам не может. А если же все – таки финансовая мотивация изменит ситуацию, значит, вы работаете с “подрывниками”, и от такой команды нужно избавляться.
– Не пытайтесь угрожать (увольнением / не выплатой зарплаты) или морально давить, это существенно снижает мотивацию: в такой обстановке выполнение задач сводится к минимальному шансу, и команда развалится.
– фирменные футболки, кружки и другая символика для поднятия корпоративного духа на этом этапе не работает, не стоит тратить деньги.

В чем причины

1. В 90% случаях основная причина в руководителе, в его неправильном управлении и построении процессов.
2. Не стоит ставить исследовательских задач разработчикам. Если вы считаете, что ваш разработчик настолько крутой, что может закодить все, что угодно, сам придумать, как выйти из тупиковой ситуации, найти и изучить все самое новое, только дай ему команду – то, скорее всего, вы ошибаетесь: ваш разработчик не так крут, иначе он бы уже работал в гугл (или вк).
3. В большинстве случаев, четко и правильно поставленная задача решается разработчиком без существенных трудностей. Но да, бывают ситуации, когда ваш разработчик действительно просто не может этого сделать. У него нет навыков, нет желания расти и изучать что-то новое. Если ваш разработчик никогда не делал того, что вы хотите от него, а чаще всего при разработке проектов так и оно есть, то срок выполнения тогда начинает плавать и затягиваться. А здесь уже смотрите пункт первый – причина в руководителе: неправильно оценил и организовал процесс.

z_d0bc162e

Что делать

– Ищем проблему в себе. Переключаем задачи на себя, исследуем тему вместе, даже если нужно сидеть за одним монитором или вместе рисовать схемы карандашом.
– Организовываем процессы, естественно используем систему постановок задач, контроля версии и багтрекер. Например, redmine.
– Ставим небольшие итерации выполнения задач. Нет такой задачи, выполнение которой нельзя декомпелировать до 3-4 дней. Выставьте реперные точки в самых мелких задачах и следуйте им. Тогда достижение этих задач будет приятной планкой для разработчиков.
– Планируйте правильно. Если проект рассчитывается на срок более 6 месяцев – смело прибавляйте 30% дополнительного времени. Тогда у вас будет более реальный срок.
– Любой малый бизнес начинается в голове. Руководитель гребет в одной лодке. Хотите, чтобы разработчик работал дольше – работайте вместе с ним. Это слова банальны, но это так часто встречается.
– Мотивировать разработчика на работу можно только интересной задачей. Программисты в большинстве случаев любят свою работу. Новые интересные задачи, которые захватят их ум, – это и есть основной движок.
– Дайте понять разработчикам, что это их дело. Подключайте их к конференциям, выступлениям. Даже если многие разработчики отказываются и говорят, что им не хочется публичности, скорее всего, хочется, но боязно. Поэтому предлагайте совместно с ними презентовать проект. Благо, конференций много, и обязательно хоть какая-то часть выступления будет принадлежать направлению разработчика. В такие моменты команда начинает действительно ощущать, что это их детище, либо разработчику становится стыдно за продукт, и у него появляется желание его усовершенствовать. Вспомните пирамиду Маслоу.
– Дайте команде почувствовать, что они делают действительно больше дело. Информируйте ее членов о своих планах и их выполнении. Оговаривайте, к чему идет вся команда, какие цели заданы. Выберите большую цель и добивайтесь ее. А на пути к этой большой цели делайте маленькие шаги и показывайте результаты всем членам команда.

Менять ли команду?

Ответ на этот вопрос решает каждый сам. Новый человек не гарантирует выполнения в срок.

Тянуть ли команду, ведь осталось то вот-вот, чуть-чуть?

Ищем причину «затыка». Отыскиваем проблему в руководстве и налаживаем процесс, даже если кажется, что это время будет потрачено я зря. Знайте, неделя, отведенная на направление всех процессов в правильное русло, окажется действительно плодотворной.

Разработчику и угрожали и предлагали бонус?

Скорее всего, у разработчика, как у любого нормального человека, уже сложилось о вас негативное мнение, и он сам присматривает новое место работы.

 

Да, мало кто учится на чужих ошибках. Выбрав путь предпринимателя, будем готовы – впереди ждет огромное количество неправильных шагов.

9
Share

2 Comments

  1. Alexey Fadeev

    Андрей, спасибо за интересную заметку. Просьба на будущее: не ставьте вместо дефиса тире – это разные знаки препинания, служащие разным целям. Из-за путаницы парсер сбивается, тяжело читать (на конструкциях типа “кто – то”, “всё – таки” и т.п.).

Leave a Reply