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

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

Задача показалась мне интересной, поэтому я с радостью принял предложение.

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

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

Почему именно Скрам? Это было исключительно прагматичное решение. Все знают Скрам, потому что Скраму уже 25 лет. Поэтому нет необходимости обучать команду. Иными словами, можно сразу же запускать разработку.

Поэтому я объявил, что следующий четверг — день, когда мы проводим планирование и запускаем первый спринт.

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

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

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

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

Из особенностей стоит выделить процесс грумминга задач. У нас он был не “стандартный”, если так можно выразиться. То есть не раз в неделю, где мы груммили задачи на предстоящий спринт. Грумминг организовывал аналитик после того, как завершал подготовку документации. Да, вы не ослышались. Грумминг проводил аналитик. На нём команда задавала вопросы и оценивала работу.

Работу мы оценивали в человеко-часах. Почему? Чтобы потом переложить оценные задачи в дорожную карту.

Тут стоит сделать отступление и рассказать про наши “особенности”:

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

На чем мы в итоге погорели:

1. Отсутствие согласований документации с бизнес-заказчиками. Если не согласовывать готовую документацию, а сразу передавать ее в разработку — это пипец как сокращает лид тайм.
2. Отсутствие приемки на стейдже готового функционала заказчиками. Это капец как сокращает лид тайм.

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

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

После релиза ЛК в прод и открытия его для пользователей, понеслась обратная связь, к нам вернулись бизнес-заказчики и спросили: “А кто согласовывал эту документацию? Почему вы так сделали? А кто согласовывал этот функционал перед выкаткой в прод?” 

Закономерный ответ: “Я как продакт дал на это добро!” И закономерное замечание со стороны бизнес-заказчика: “Но это работает не так, как надо! Почему вы выкатились в прод по сути с багом и без нашего ведома?”.

В общем из-за моей позиции “Ну у нас же Agile, поэтому давайте больше доверия к команде и быстрее катим в прод” мы собрали в проде несколько критичных багов, которые пришлось фиксить и тормозить разработку. И после пары таких неприятных встреч я принял два следующих решения:

1. Перед разработкой мы согласовываем документацию с бизнес-заказчиком.
2. После тестирования мы катим фичу на стейдж и далее бизнес-заказчик ее принимает.

И только потом катим в прод. На практике это вылилось в то, что наш лид тайм прибавил шесть дней: три на согласование документации и три на приемку функционала на стейдже.

Пока что проводим эксперимент и смотрим, как это скажется на качестве продукта.

Почему я решил, что используя Agile, я налоал дров как продакт? Потому что я думал “Ща мы быстро всё сделаем, катнем в прод и соберем обратную связь”. А по факту мы сильно потеряли в качестве и сейчас это всё надо исправлять.

Также я решил внедрить в процесс разработки еще две практики:

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

Резюме

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

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

На этом история продакта заканчивается. Мы подробно разобрали все ошибки и составили план действий по выруливанию ситуации. Всё это я будет во второй части.