Привет! Меня зовут Виталий Павленко, я тимлид одной из продуктовых команд в Профи. Расскажу, как мы хотели сделать технический проект за пару месяцев, но закончили через восемь. По пути прошли демотивацию всей команды, выгорание и желание делать что угодно, кроме этого проекта. В итоге забрали с собой классный опыт, которым хочется поделиться. Будет полезно начинающим менеджерам и тимлидам.
Что за проект
Проект был технический — хотели вынести модуль из большого монолита на PHP в отдельный сервис на Node.js. Мы не собирались его менять или рефакторить, нужно было только переписать на Node.js. Должны были сделать за пару месяцев.
Вредный совет №1. Не надо разбивать проект на этапы, если есть одна большая цель
Проект небольшой, в котором нужно просто переписать код с PHP на Node.js. Что тут разделять? У нас была одна понятная цель — релиз.
Эта ловушка загнала команду в дофаминовую яму.
Наша система мотивации устроена так, что организм вырабатывает дофамин после выполнения трудной задачи или достижения какой-то цели. Если мы делаем задачу, у которой нет конца, то погружаемся в очень неприятное состояние — дофаминовую яму. И это чувствовалось: у команды плохое настроение, руки опускаются, хочется отвлечься на другие задачи.
Если бы мы разбили проект на более мелкие этапы, то лучше бы чувствовали прогресс и получали бы дофамин чаще.
Нужно было разбить проект на несколько этапов со своими целями, а не ставить одну большую цель на весь проект.
Вредный совет №2. Амбициозные цели на спринт мотивируют сделать больше
В начале мы так в себя верили, что ставили большие цели на каждый спринт, а иногда даже повышали планку. Например:
Спринт 1. Запустить форму на тестовых сборках — не сделали.
Спринт 2. Запустить форму на проде без ошибок — тем более не сделали.
Это было нереально за такой промежуток времени и очень абстрактно. Мы каждый раз разочаровывались, что не можем достичь цели, и приближались к выгоранию.
Оглядываясь назад, я бы сформулировал более приземлённые и реалистичные цели. Например:
Спринт 1. Закончить разработку компонента Х.
Спринт 2. Разработать модуль Х.
Вредный совет №3. Не надо определять роли. Все в команде сами знают, кто за что отвечает
Из-за того, что плохо декомпозировали проект в самом начале, мы не определили ответственных за каждый этап. Вначале его лидировал я, но потом контроль перешёл к разработчику без опыта ведения проектов. Из-за этого проект на какое-то время ушёл из фокуса, все переключились на другие задачи и перестали следить за статусами. Мы потеряли время.
В следующий раз решили на старте проекта определять все роли, особенно драйверов и ответственных. А если будем меняться по ходу проекта, то очень тщательно передавать дела и говорить об ожиданиях.
Вредный совет №4. Твой проект никого не касается. Делай так, как считаешь нужным
Мы думали, что качество кода в нашем проекте — забота только нашей команды. На деле всё оказалось иначе — нужно было пройти ревью команды платформы. И это было больно: мы застряли на несколько месяцев и пришлось переписать почти всё.
Почему так вышло?
Тогда компания только начинала распиливать монолит на сервисы, и требования к новым сервисам оказались высокие. Нужно было заранее всё узнать и обсудить с командой платформы, которая отвечала за новые стандарты. Но мы этого не сделали.
После каждой новой правки мы думали: «ну, это точно последнее». А потом получали ещё порцию. И мы принимали это как данность: «снова правки — надо переделать».
Проект растягивался, а мы всё чаще отвлекались на другие задачи.
Только через несколько месяцев мы не выдержали и решили всё обсудить с командой платформы. Договорились, какие правки критично внести сейчас, а какие могут подождать. Спустя неделю мы получили долгожданный апрув.
А стоило всего-то сразу провести встречу с командой платформы, решить как будет проходить процесс ревью. И скорее всего мы бы просто согласовали GraphQL схему до начала переноса сервиса, а потом написали бы под эту схему код. После этого мы решили для себя, что будем всегда максимально учитывать все возможные проблемы и ограничения на ранних этапах.
Релиз!
Многострадальный проект закончился, все счастливы, никто не уволился и ничего не сломалось. А мы унесли с собой классный опыт.
Крупные проекты редко получается сделать идеально и в срок — сам не встречал таких чудес. Главное — проводить подробные ретроспективы по итогам, делать выводы и учиться на ошибках.
Гораздо приятнее учиться на чужих ошибках. Поэтому надеюсь, что моя статья была полезной
Интересные статьи
Интересные статьи
