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