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

Проблема

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

Три распространенных ответа на эту проблему

  • Ничего не делать. Владельцы продуктов будут собирать подробные требования для каждого запроса функции по мере поступления. Затем, когда функция будет окончательно приоритизирована, они вернутся к клиенту и обнаружат, что передумали, вынуждая Владельца продукта переписывать требования и переделывать макеты, что привело к двойной работе.
  • Приостановить требования: владелец продукта сообщит покупателю, что ему не разрешено менять свое мнение. Они по-прежнему собирают требования на раннем этапе, но когда функция, наконец, получает приоритет и обнаруживается, что заказчик передумал, владелец продукта говорит: «Извините, эти требования заблокированы». Этот метод почти гарантирует разочарование со всех сторон, а также снижает ценность для клиента.
  • Своевременный сбор требований. Требования к продукту доставляются разработчикам как раз вовремя для разработки, и с достаточной детализацией для разработки. Запросы функций содержат минимум деталей до тех пор, пока они не появятся в графике разработки на одну-две итерации в будущем. До этого момента сохраняемых деталей достаточно для оценки и расстановки приоритетов. После определения приоритетов и планирования одной-двух итераций в будущем владелец продукта создает макеты и собирает требования, необходимые для разработки.

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

Риск точно в срок

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

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

Источники

Гибкое моделирование требований

Скотт В. Эмблер

Новичок в Agile? Помните одно: достаточно, как раз вовремя

Боб Хартман

СОВРЕМЕННАЯ ДОСТАВКА: ИСТОРИЯ AGILE

Автор: Аби Йоханнан

Как вы справляетесь с требованиями точно в срок?

Алан О’Каллаган