10 ошибок в управлении разработкой: советы от опытного проджект-менеджера

Эту статью мы написали вместе с Анастасией Борисюк, проджект-менеджером.

Жил-был продакт Джек. Он анализировал аудиторию, считал метрики и работал с гипотезами. Все шло хорошо, пока проджект не уволился, а тимлид не ушел в отпуск. Теперь Джеку надо планировать спринты, участвовать в оценке технических задач, мотивировать разработчиков и контролировать релизы.

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

Мы готовим серию статей с ошибками и советами для начинающих продакт-менеджеров. Читайте еще одну статью в таком формате — о том, как управлять командой.

А разве продакт-менеджер этим всем занимается?

Зависит от компании.

Бывают компании, в которых есть несколько ролей: продакт, проджект и тимлид. При таком составе управлением разработкой занимаются тимлид и проджект. Продакт дает обратную связь тимлиду и проджекту по ходу разработки продукта. Например, просит разобраться с низким качеством тестирования или тем, что команда систематически забывает планировать приемку. 

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

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

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

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

1. Неправильно оценивать, из чего состоит спринт 

Во время спринта разработчик не только кодит. Еще он участвует в командных мероприятиях и 1:1 встречах, делает багфикс, код ревью и так далее. 

Это занимает время, которое стоит учитывать. Многие прикидывают это время на глаз, например, закладывают 10 часов на коммуникации и 30 часов на разработку. Но эти цифры могут не подходить вашей команде.

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

Ситуация: Кейт работает продактом в компании, которая разрабатывает платформу для электронного документооборота. Проджекта в команде нет, поэтому его функции также выполняет она.

Идет планирование спринта. СЕО попросил поднять приоритет фичи смс-уведомлений. Текущие задачи в спринте также важны, их нельзя убирать. Кейт кажется, что можно взять фичу в этот спринт без ущерба другим задачам. Она пишет тимлиду Джеку.

2. Не закладывать время на приемку и тестирование

Разработка фичи не заканчивается написанием кода и его ревью. Еще пару дней может занять тестирование, а потом — приемка продактом. Это нужно учитывать при планировании.

Ситуация: Идет планирование следующего спринта. Тимлид говорит, что команда успеет закончить смс-уведомления, и еще останется много времени.

3. Оценивать незнакомые задачи без учета времени на погружение

Иногда команда сталкивается с чем-то новым, что она не в состоянии оценить. Например, осваивает новую технологию, внедряет стороннее решение. 

Чтобы минимизировать риск провалить бизнес-цели, нужно предварительно поставить разработчикам задачи на рисерч или анализ. Знакомство с контекстом поможет корректно оценить задачи. 

Ситуация: Кейт планирует сделать интеграцию с налоговой, чтобы показывать пользователю данные. Она просит разработчика оценить задачу.

4. Не работать с командой над навыком оценки задачи

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

Ситуация: Команде известно, что план/факт выполненных задач сильно отличается. Команда точно попадает в оценки 1-4 часа, а все, что выше, всегда вылезает за пределы. Кейт нужно оценить одну из задач, поэтому она пишет разработчику Майку.

5. Не давать требования к задачам 

Продакт является единой точкой входа для разработки. Он должен решить, зачем и что нужно сделать, и дать понятную задачу. С момента оценки и обсуждения задачи до того, как ее возьмут в работу, может пройти много времени. 

Описания должны быть такими, чтобы человек без контекста мог его прочитать и понять, что надо делать и зачем. Если из описания это непонятно, то решение задачи затянется, разработчик может сделать что-то не так.

Ситуация: Кейт пришел запрос из отдела маркетинга “обнаружили ошибку на сайте, нет поля  "itemListElement". В админке нет инструментов, чтобы это исправить. Просьба указать код навигации на страницах”. Во время груминга Кейт заносит эту задачу разработчикам.

6. Не прививать привычку вовремя говорить о проблемах 

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

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

Ситуация: Сейчас четверг, завтра заканчивается спринт. Разработчик должен сделать еще несколько задач, но у него возникает проблема. Он провозился с ней и никому не сказал о проблеме. 

7.  Не давать команде четкое понимание приоритетов

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

Чтобы разобраться в этом подробнее, читайте нашу статью о том, как приоритизировать гипотезы. Там мы рассказываем об ICE Score, RICE Score и Lean Prioritization Canvas. Каждый метод тестируем на пяти гипотезах для RPG игры, а в конце даем бесплатный шаблон для приоритизации гипотез.

Ситуация: Идет дейли. Разработчик рассказывает о своих задачах и проблемах.

8. Добавлять новые задачи во время спринта

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

По scrum влеты делать нельзя. Однако этим правилам не всегда следует бизнес-заказчик или сам продакт. В итоге, команда отвлекается и не успевает выполнить все задачи. Приходится делать вылет — убирать часть задач из спринта. 

Поэтому не делайте влеты, ответьте сначала на вопрос: “А что случится, если мы сделаем это не сегодня, а в следующем спринте?”. Если у вас часто бывают влеты, возможно scrum вам не подходит. Мы написали об этом отдельную статью.

Ситуация: Маркетолог пишет Кейт и просит поменять добавить новые поля в админку.

9. Не адаптировать спринт под изменения

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

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

Ситуация: Один из разработчиков заболел. Тимлид пишет в чат.

10. Не работать над качеством продукта

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

Также нужно работать с техническим долгом. Сам по себе он не критичен, но, когда накапливается, сильно влияет на здоровье продукта. Начинают постоянно прилетать критичные инциденты и баги. Команде приходится бросать бизнес-цели и чинить то, что сломалось.

Работа над качеством продукта требует времени разработчиков, ее нужно учитывать в планах.

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

Резюмируем

Часто продакт-менеджеры относятся к разработке как к чему-то скучному. Гораздо интереснее сделать дашборд в амплитуде, провести кастдевы или потестить гипотезы. Но разработка — важная часть продакт-менеджмента. Стоит в этом разобраться, чтобы в случае чего, взять на себя ответственность.

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