Проект приостановлен. Менторские проверки, группы и активности недоступны. Предлагаем только самостоятельное обучение на платформе.
Українська
Українська
Русский
Українська
Українська
Русский

Сообщение об ошибке

Вы собираетесь отправить сообщение о следующей ошибке:

Пожалуйста, опишите суть ошибки

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

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

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


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


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

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

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


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


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


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


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


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

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

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


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


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


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


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

Не надо 👎

Джек, нам нужно на этой неделе сделать смс-уведомления, эту фичу очень ждет СЕО. Она всего на 30 часов, сможем сделать?

Да, время Тома как раз еще не распределено. Закину задачи в спринт на него.

Отлично! 

Надо 👍

Джек, нам нужно на этой неделе сделать смс-уведомления, эту фичу очень ждет СЕО. Она всего на 30 часов, сможем сделать?

Да, время Тома как раз еще не распределено. Закину задачи в спринт на него. 

Подожди, а есть кто-то еще свободный? Нам же нужно заложить время на багфикс, есть технические задачи, которые нельзя уже откладывать, к тому же Том будет собеседовать 3-х разработчиков на этой неделе.

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

Нет, эти задачи стратегически важны. Я поговорю с СЕО, растянем эту фичу на 2 недели. 
Гайд по лучшим статьям skillsetter
В нашем блоге уже больше 150 статей про рост продуктов и карьеру в IT. Для удобной навигации мы объединили их в тематические подборки.
Выбрать подборку

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

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


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

Не надо 👎

В этом спринте закончим смс-уведомления. Там осталось не так много работы. 

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

Давай, вроде успеваем.

Надо 👍 

В этом спринте закончим смс-уведомления. Там осталось не так много работы. 

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

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

Ты прав. Тогда разобьем на 2 недели.

Попробуйте решить одно из заданий по этой теме из нашего курса по продакт менеджменту.

Задание 

Идет планирование спринта, и вы хотите добавить в него еще одну приоритетную фичу. Нужно понять, успеете ли вы все в одном спринте. После планирования других задач у вас осталось 25 часов разработчика. Разработчики оценили эту задачу в 22 часа. Что вы будете делать?

Выберите несколько вариантов

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

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


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


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

Не надо 👎

Майк, скоро нам нужно будет подключиться к API налоговой, чтобы выводить данные у нас. Сколько времени это займет?

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

Окей.

Надо 👍

Майк, скоро нам нужно будет подключиться к API налоговой, чтобы выводить данные у нас. Сколько времени это займет?

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

Давай тогда сначала возьмем в спринт задачу на рисерч, посмотрим что у них есть в API. После этого уже возьмем на оценку. 

Окей.

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

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


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

Не надо 👎

Майк, сколько займет у тебя эта задача?

Ну часов 6, наверно.

Окей, возьмем ее в следующий спринт тогда.

Надо 👍

Майк, сколько займет у тебя эта задача?

Ну часов 6, наверно.

А из чего она состоит? Давай подробнее опишем шаги. 

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

Может поделим на 2 задачи? Кажется, тут больше, чем 6 часов.

Согласен.

Задание

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

Выберите несколько вариантов

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

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


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


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

Не надо 👎

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

Окей.

Надо 👍

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

скрин экрана Trello про ошибку на сайте

Посмотрел, это займет где-то час.

Хорошо, добавим в следующий спринт.
Бесплатный курс по проджект-менеджменту
За 3 дня вы узнаете, какие 5 принципов помогут вам добиться успеха в проджект-менеджменте
Начать учиться бесплатно

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

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


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


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

Не надо 👎

Кейт, я не успеваю сделать тестирование поп-апа. Его добавление заняло больше времени, чем планировалось.

Том, а как так получилось? Задачу оценили в 3 часа, а у тебя ушло 9.

Ну я запутался, начал разбираться в теме, а дальше закончился рабочий день.

В следующий раз надо лучше оценивать задачу. Больше так не делай.

Надо 👍

Кейт, я не успеваю сделать тестирование поп-апа. Его добавление заняло больше времени, чем планировалось.

Том, а как так получилось? Задачу оценили в 3 часа, а у тебя ушло 9.

Ну я запутался, начал разбираться в теме, а дальше закончился рабочий день.

Поняла тебя, придется отложить тестирование на следующий спринт.

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

Хорошо, теперь буду говорить.

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

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


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


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

Не надо 👎

Я обновляю плашки на лендинге. Кажется, компонент для истории уже не доделаю сегодня. 

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

Ну я просто по порядку взял.

Надо 👍

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

Подожди, лучше начни с компонента для истории — он важен для цели спринта, а плашки — это декор, их можно напоследок оставить.

Хорошо. 

Если что бери задачи по порядку из to do, они там приоритизированы.

Читайте лучшие статьи о запуске и росте продуктов

Раз в неделю будем отправлять свежий дайджест вам на почту. Наc читает 25000 человек 🚀

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

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


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


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


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

Не надо 👎

Кейт, можно быстренько добавить несколько полей в админку? Важно для SEO.

Ладно, давай, вроде недолго.

Надо 👍

Кейт, можно быстренько добавить несколько полей в админку? Важно для SEO.

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

Это же всего пара полей. 

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

Задание 

К вам постоянно приходит маркетолог со “срочными” задачами, которые не могут ждать. 


Сегодня вам снова пишет маркетолог: “Срочно надо убрать новую продажку с сайта. Это не получится сделать через админку. Сделайте, пожалуйста”. 


Что стоит ему ответить?

Выберите несколько вариантов

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

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


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


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

Не надо 👎

Мы не достигли целей спринта в этот раз. 

Но почему?

Том заболел, мы лишились одного бека, не успели все задачи сделать.

Надо 👍

Ребят, Том заболел, он выпадает до конца недели точно. Давайте посмотрим как перераспределить его задачи. 

Давай, но там много задач

Кейт, может выкинем сортировку и фильтры? 

Сортировку надо оставить, давайте созвонимся и посмотрим на менее важные задачи. 

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

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


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


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


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

Не надо 👎

Кейт, ты поставила задачи по рассылкам в следующий спринт, но мы еще личный кабинет не покрыли тестами. А еще наш сервер падал 3 раза на этой неделе. Мы не справляемся с нагрузкой.

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

Надо 👍

Кейт, ты поставила задачи по рассылкам в следующий спринт, но мы еще личный кабинет не покрыли тестами. А еще наш сервер падал 3 раза на этой неделе. Мы не справляемся с нагрузкой. 

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

В принципе, да. Можно тогда после рассылок поставить его.

Резюмируем

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


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

Рекомендуем почитать

способы решения конфликтов на работе

5 неожиданных способов решения конфликтов в продуктовой команде

Зарплата менеджера IT-проектов

Проджект-менеджер: кто это такой, что делает и как им стать

статья 10 стыдных вопросов о no-code

10 стыдных вопросов о no-code

← Читать другие статьи в блоге Получить реальные навыки