Друзья, всем привет!
Это вторая части истории продакта, который использовал Agile и наломал дров. В ней мы подробно разбираем допущенные ошибки и формулируем гипотезы для их устранения.
И так, допущенные ошибки:
| № | Ошибка | Гипотеза для ее устранения | Ожидаемый результат |
| 1 | Груминг проводит аналитик. | Груминг проводит продакт | Продакт вместе с командой вовлечен в груминг задач и понимает, что там нужно сделать. Не сидит, не занимается в фоне другими задачами. |
| 2 | Работу оцениваем в человеко-часах, но не всю. | Всю работу оцениваем в человеко-часах или сторипоинтах | На основе статистики будем понимать капасити спринтов, не перегружать команду, а также давать бизнесу реальные сроки реализации фичи. |
| 3 | Карту пользовательских историй строит аналитик. | Карту пользовательских историй строит продакт менеджер. | Продакт менеджер понимает последовательность фичей и может построить работу над продуктом итеративно, постепенно внедряя новые фичи. |
| 4 | Отказ от обзоров спринта. | Вернуть обзоры спринта в конце каждого спринта. | Стейкхолдеры понимают, что было сделано, могут задать вопросы по функционалу или дать обратную связь, что хорошо и что улучшить. |
| 5 | Цель спринта ставится не на какой-то функционал, а прописываются задачи для каждого члена команды, которые нужно закрыть за спринт. | Ставить одну цель спринта на конкретный функционал, который нужно сделать за спринт. | Фокус на одном функционале вместо списка задач позволит команде достигать цель за спринт. |
| 6 | Прилетающие баги сразу берутся в спринт, что расширяет его объём. | Сделать классы обслуживания для срочных задач, договориться, что берем в текущий спринт, а что оставляем для следующего. | Меньше переключений внутри спринта, сохранение капасити спринта, исключение рисков не достичь цели спринта. |
| 7 | Задач в спринте раз в 10 больше, чем членов в команде. | Пересекается с п.2. Объём задач в спринте должен соответствовать капасити команды. | Меньше переключений в спринте между задачами, фокус на завершение начатой работы снижение перегруза в команде. |
| 8 | На груминге оценивается и обсуждается одна задача и та — пользовательская история. Таски и баги не оцениваются никак. | Пересекается с п.1 и п.2. Необходимо сделать еженедельные груминге и оценивать все задачи в бэклоге. | Будет проще рассчитать объем спринта, так как все задачи будут оценены, и сопоставить его с капасити комнады. |
| 9 | Нет понимания капасити команды (как следствие не оцененных задач). | Начать измерять капасити команды, начать собирать статистику. | Формировать объем спринта в соответствии с капасити команды. Больше завершенных задач в конце спринта. Выполнение цели спринта. |
| 10 | Нет понимания скорости команды (как следствие не оцененных задач). | Начать измерять пропускную способность команды — сколько взяли в спринт, сколько закрыли. | Снизится нагрузка на команду, снизится количество незавершенных задач, появится понимание скорости команды — будет легче выполнять взятые в спринт задачи. |
| 11 | Я использовал из Канбана подход “no estimate”, но неверно понял его суть. | Переход на подход “No estimate” возможен, когда уже накоплена статистика по классам обслуживания. | Ускорится планирование спринта и сохранится высокая вероятность реализации задач спринта. |
| 12 | Отсутствие согласований документации с бизнес-заказчиками. Если не согласовывать готовую документацию, а сразу передавать ее в разработку — это пипец как сокращает лид тайм. | Согласовывать с заказчиком документацию перед разработкой. | Это сэкономит время на переделку задач по некорректным требованиям. |
| 13 | Отсутствие приемки на стейдже готового функционала заказчиками. Это капец как сокращает лид тайм. | Согласовывать с заказчиком задачи на стейдже перед выкаткой в прод. | Это сэкономит время на переделке задач, которые не соответствуют ожиданиям заказчика. |
| 14 | Я взял на себя ответственность по согласованию документации и приемке функционала перед релизом, как продакт. То есть документацию принимаю я, задачу на стейдже смотрю и принимаю я. | Согласовывать документацию и реализацию с бизнес-заказчиком. | Повысится качество продукта, будет меньше багов и переделок. |
После разбора ошибок мы договорились, что в течение следующего полугодия (квартал — минимум) продакт претворяет в жизнь гипотезы, чтобы устранить выявленные ошибки и фиксирует результат, что изменилось.
После этого мы еще раз встречаемся и смотрим, что и как сработало, что осталось без изменений и что стало хуже.
Продолжение следует…
