Исследования показывают, что Agile-проекты в несколько раз более успешнее, чем "водопадные". Однако, эти же исследования показывают, что неудачи в Agile-проектах тоже случаются. В представляемой статье мы расскажем о своем опыте в неудачах.
Подписывайтесь на наш телеграмм канал https://t.me/bit_erp там вы найдете актуальные новости, анонсы, опыт и истории от команды БИТ:ERP.
Для начала обратимся к результатам исследований компании Standish Group. Она регулярно публикует CHAOS Report, содержащий данные о том, почему одни проекты преуспевают, а другие терпят неудачу.
Интересно, что большие Agile-проекты оказываются в несколько раз успешнее "водопадных". При этом успешность маленьких проектов предсказуемо не имеет такой показательной разницы. Однако мы сейчас обратим внимание на то, что среди 10 000 исследованных проектов, встречаются 9% неудачных Agile-проектов.
Мы считаем проект неудачным, если его продуктом Заказчик не может или не хочет воспользоваться. Другими словами, если в результате проекта не состоялась доставка ценности до Заказчика. С этих позиций и разберем предлагаемый кейс.
К нам обратилась организация, которой нужно было через три месяца запустить WMS-систему на складе класса А+, который, как и система, должен был появиться через те же три месяца. Общая площадь склада более 11 тыс. кв. м., планируемое количество обрабатываемых заявок до 1 тыс. в сутки, планируемые ежедневные отгрузки более 100 тыс. SKU в сутки.
Для склада требовалась автоматизированная система, которая должна была полностью исключить участие человека в принятии решений. В частности, при размещении товара требовалось учитывать температурный режим хранения и рейтинги товаров, а также рейтинги удаленности ячеек. Размещение и отбор состояли из нескольких этапов, которые, в свою очередь, могли комбинироваться. Например, отбор включал в себя - отбор в коробках, отбор в штуках, контроль, агрегацию, подвоз до лифта, спуск лифтом, подвоз в зону отгрузки, контроль, погрузку в машину и так далее. Система должна была раздавать задания разным исполнителям, и оптимизировать движение исполнителей по складу. Например, исключать ситуации, когда два погрузчика оказывались в одном ряду, чтобы те не застряли.
Активность и деловой напор Заказчика нам понравились, задача - тоже, и вызов был принят. Учитывая сжатые сроки, неопределенность процессов и предполагаемое постепенное наращивание количества персонала на новом складе, предложили Заказчику MVP с базовым набором складских операций. Заказчик согласился. Мы составили дорожную карту, подготовили бэклог первого спринта и побежали.
Довольно скоро стало понятно, что склад через три месяца не будет готов и полученный гандикап было решено использовать для наращивания функциональности. В штате Заказчика был очень сильный эксперт по организации складов, который описал сценарии работы будущего склада (более 700 страниц текста). Новый MVP должен был им соответствовать. Для того, чтобы убедиться в работоспособности MVP, в отдельном кабинете подготовили стенд с подключенным оборудованием (так называемое «кабинетное тестирование»). А для автоматического тестирования 700+ страниц сценариев перевели на Gherkin.
Прошло еще 3 месяца, но запуск склада снова откладывался. К этому времени мы имели систему, ни одна из функций которой ни разу не запускалась и не могла быть запущена в продуктиве. Никто не мог сказать сколько скрытых проблем и дефектов она содержит. При этом уже была готова 2-я очередь сценариев, которые в ряде случаев противоречили уже реализованным. В этих условиях мы предложили Заказчику следующее:
- "Заморозить" MVP 1-й очереди сценариев. Т.е., до запуска на реальном складе, не наращивать функциональность до 2-й очереди сценариев.
- Запуститься на реальном складе.
- По результатам запуска скорректировать 2-ю очередь сценариев, определить приоритеты и осуществить последовательный запуск инкрементов по результатам спринтов.
Это предложение Заказчик не принял. Проект был остановлен. Мы передали все наши наработки и документацию и на их основе Заказчик силами своей команды запустил систему вместе с запуском склада через несколько месяцев.
Факторы неудачи
В основе Scrum лежат принципы эмпиризма и бережливого мышления. В случае описываемого проекта мы нарушили первый принцип, но своевременно остановились благодаря второму.
Принцип эмпиризма утверждает, что источником знаний является опыт. В нашем случае опыт отсутствовал - каждый следующий спринт добавлял в продукт функциональность, но не ценность, так как нам ни разу не удалось апробировать его на практике. В результате, в конце проекта наш продукт представлял собой набор незавершенных функций и скрытых проблем, завершение и решение которых никак нельзя было предсказать или оценить.
В этих условиях продолжать наращивать функциональность продукта и, тем более, перерабатывать его, означало производить все 7 видов потерь сразу (частично выполненная работа, избыточные функциональные возможности, повторное приобретение знания, передача работы, переключение между задачами, задержки, дефекты). Заказчик это тоже понимал, и в своем решении придерживался бережливых принципов исключения потерь.
Проект оказался для нас неудачным, потому что нашей команде не удалось доставить ценность продукта до Заказчика - мы разработали базовое решение, а его адаптацию, развитие и запуск выполнила его внутренняя команда.
Чему мы научились на этой неудаче?
Мы еще раз убедились, что Scrum создан для того, чтобы быстро выявлять проблемы и это работает, только если в результате итерации вы получаете инкремент в продуктиве. Примечательно, что Scrum помог нам вовремя остановиться, а Заказчику получить ценность с минимумом потерь. Замечательно также, что мы сохранили с Заказчиком хорошие деловые и человеческие отношения.
Материал подготовил:
Евгений Салов, Product Owner, БИТ:ERP.
Поделитесь в комментариях своим опытом проектных неудач. Как вы с ними справились? Поддержите нас лайками, если материал статьи оказался полезным для вас.
