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

Что за проект

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Релиз!

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

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

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