Как делать проект восемь месяцев вместо двух. Вредные советы для менеджеров

Как делать проект восемь месяцев вместо двух. Вредные советы для менеджеров

Привет! Меня зовут Виталий Павленко, я тимлид одной из продуктовых команд в Профи. Расскажу, как мы хотели сделать технический проект за пару месяцев, но закончили через восемь. По пути прошли демотивацию всей команды, выгорание и желание делать что угодно, кроме этого проекта. В итоге забрали с собой классный опыт, которым хочется поделиться.

Будет полезно начинающим менеджерам и тимлидам.

Что за проект

Проект был технический — хотели вынести модуль из большого монолита на PHP в отдельный сервис на Node.js. Мы не собирались его менять или рефакторить, нужно было только переписать на Node.js. Должны были сделать за пару месяцев.

Вредный совет №1. Не надо разбивать проект на этапы, если есть одна большая цель

Проект небольшой, в котором нужно просто переписать код с PHP на Node.js. Что тут разделять? У нас была одна понятная цель — релиз.

Эта ловушка загнала команду в дофаминовую яму.

Наша система мотивации устроена так, что организм вырабатывает дофамин после выполнения трудной задачи или достижения какой-то цели. Если мы делаем задачу, у которой нет конца, то погружаемся в очень неприятное состояние — дофаминовую яму. И это чувствовалось: у команды плохое настроение, руки опускаются, хочется отвлечься на другие задачи.

Как делать проект восемь месяцев вместо двух. Вредные советы для менеджеров

Если бы мы разбили проект на более мелкие этапы, то лучше бы чувствовали прогресс и получали бы дофамин чаще.

Нужно было разбить проект на несколько этапов со своими целями, а не ставить одну большую цель на весь проект.

Вредный совет №2. Амбициозные цели на спринт мотивируют сделать больше

В начале мы так в себя верили, что ставили большие цели на каждый спринт, а иногда даже повышали планку. Например:

Спринт 1. Запустить форму на тестовых сборках — не сделали.

Спринт 2. Запустить форму на проде без ошибок — тем более не сделали.

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

Как делать проект восемь месяцев вместо двух. Вредные советы для менеджеров

Оглядываясь назад, я бы сформулировал более приземлённые и реалистичные цели. Например:

Спринт 1. Закончить разработку компонента Х.

Спринт 2. Разработать модуль Х.

Вредный совет №3. Не надо определять роли. Все в команде сами знают, кто за что отвечает

Из-за того, что плохо декомпозировали проект в самом начале, мы не определили ответственных за каждый этап. Вначале его лидировал я, но потом контроль перешёл к разработчику без опыта ведения проектов. Из-за этого проект на какое-то время ушёл из фокуса, все переключились на другие задачи и перестали следить за статусами. Мы потеряли время.

В следующий раз решили на старте проекта определять все роли, особенно драйверов и ответственных. А если будем меняться по ходу проекта, то очень тщательно передавать дела и говорить об ожиданиях.

Вредный совет №4. Твой проект никого не касается. Делай так, как считаешь нужным

Мы думали, что качество кода в нашем проекте — забота только нашей команды. На деле всё оказалось иначе — нужно было пройти ревью команды платформы. И это было больно: мы застряли на несколько месяцев и пришлось переписать почти всё.

Как делать проект восемь месяцев вместо двух. Вредные советы для менеджеров

Почему так вышло?

Тогда компания только начинала распиливать монолит на сервисы, и требования к новым сервисам оказались высокие. Нужно было заранее всё узнать и обсудить с командой платформы, которая отвечала за новые стандарты. Но мы этого не сделали.

После каждой новой правки мы думали: «ну, это точно последнее». А потом получали ещё порцию. И мы принимали это как данность: «снова правки — надо переделать».

Проект растягивался, а мы всё чаще отвлекались на другие задачи.

Только через несколько месяцев мы не выдержали и решили всё обсудить с командой платформы. Договорились, какие правки критично внести сейчас, а какие могут подождать. Спустя неделю мы получили долгожданный апрув.

Как делать проект восемь месяцев вместо двух. Вредные советы для менеджеров

А стоило всего-то сразу провести встречу и решить, как будет проходить процесс ревью. И, скорее всего, мы бы просто согласовали GraphQL-схему до начала переноса сервиса, а потом написали бы под эту схему код. После этого мы решили, что будем всегда максимально учитывать все возможные проблемы и ограничения на ранних этапах.

Релиз!

Многострадальный проект закончился, все счастливы, никто не уволился и ничего не сломалось. А мы унесли с собой классный опыт.

Крупные проекты редко получается сделать идеально и в срок — сам не встречал таких чудес. Главное — проводить подробные ретроспективы по итогам, делать выводы и учиться на ошибках.

Гораздо приятнее учиться на чужих ошибках. Поэтому надеюсь, что моя статья была полезной :-)

7
5 комментариев

А из взрослых есть кто-нибудь дома?

3
Ответить

В советских трудовых коллективах коллегиальность была основой достижения поставленных задач. А при автократичном руководстве всегда возникали конфликты, коллектив разлагался на группки, и росла текучка. В итоге... в зависимости от уровня компании, "летели шапки", сменялись руководители и т.д...и все шли ко дну..

Ответить

Про коллегиальность в советских коллективах - очень похоже на начало истории про альтернативную реальность.

1
Ответить

А вы еще сомневаетесь в эффективности метода 'взять и сделать за пару месяцев'? Почему же вам не удалось закончить проект вовремя, если все было настолько просто? Наверное, просто команда была составлена из неправильных людей. В следующий раз лучше нанять роботов, они точно справятся за пару дней.

Ответить