Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.
Все мы с вами так или иначе сталкиваемся с требованиями, когда мы что-то от кого-то хотим, когда кому-то что-то объясняем. И так или иначе, когда мы с вами доносим определенные требования, наша цель — передать полную картину, чтобы наш запрос был выполнен.
В разработке программного обеспечения или продуктов существует разные типы требований:
функциональные
нефункциональные
пользовательские
бизнес-требования
и много других.
Фокус требований в Agile
В Agile все требования рассматриваются через призму ценности для конечного пользователя. И поэтому большинство требований должны в первую очередь идти от потребностей пользователей.
Почему? Потому что наши продукты в итоге будут покупать пользователи.
(!) Но это не значит, что мы должны слепо спрашивать их, что им нужно. Вместо этого мы должны изучать их потребности и поведение.
Для того, чтобы разобраться, как изменить подход к управлению требованиями, давайте разберемся, какие основные ошибки мы допускаем в этом процессе?
Первая ошибка — идти от конкретных решений, а не от потребностей пользователей
То есть закладывать в требование сразу сформулированное решение.
Например, часто заказчики приносят требования в следующем виде:
Я хочу, чтобы вы сделали кнопку.
Я хочу, чтобы вы сделали вот этот модуль.
и многие команды просто принимают эти требования как данность, перекладывая ответственность за требования на заказчика, со словами «он лучше знает, что ему нужно».
На самом деле — нет. Как говорил Генри Форд «Если бы я спросил пользователей напрямую, что им нужно, они бы ответили — более быстрая лошадь». Так и в жизни — пользователи и заказчики часто формулируют требования в контексте решений и ошибка команды — слепо их принимать. Но заказчик чаще всего вообще не специалист в разработке продуктов, которые вы делаете. Он хочет решить свою проблему. А ваша задача — узнать, а какую проблему он хочет решить.
Какие вопросы стоит задавать заказчику, чтобы понять его истинные потребности?
К примеру, к вам приходит заказчик с просьбой сделать для него коробку для вещей. Заказчик — холостой мужчина лет 40 со стабильным заработком.
Какие вопросы бы вы ему задали?
Можно начать задавать ему сразу вопросы про критерии, размеры, прочность коробки, цвета и прочие фичи и плюшки. И побежать ее скорее делать, взяв предоплату с вашего заказчика. Что получиться в итоге? Скорее всего, разочарованный заказчик и потраченные деньги. Коробка, может, и классной получится, но решит ли она его проблему?)
Заказчик, как правило, не знает, какое решение ему нужно. Точнее, он может думать, что ему нужна коробка, а по факту он просто хочет, чтобы решилась его проблема. А к вам он обращается, чтобы вы помогли ему эту проблему решить.
Поэтому откажитесь от вопросов про характеристики, а задавайте вопросы про ценность.
Главный вопрос, который стоит задать вашему заказчику: «Зачем тебе нужна эта коробка?»
Ведь в ответе кроется суть: коробка может быть для разных целей:
Для того, чтобы убирать вещи в не сезон, например, летом убираются в коробку зимние вещи;
Для удобства сортировки вещей в шкафу;
Для того, чтобы перевезти вещи в новую квартиру.
и еще 100500 вариантов.
От этого зависит, какое решение вы будете создавать.
Например, вашему заказчику нужно убирать зимние вещи летом, чтобы освобождать место в шкафу, так как места у него не так много. Таким образом, вы знаете, какая у него задача и проблема: Задача — Иметь место для актуальных вещей в шкафу, проблема — мало места в шкафу, вещи мнутся.
Выявляйте пользовательские потребности и формулируйте Пользовательские истории
После выявления главной задачи и проблемы вы формулируете пользовательские истории, которые отражают потребности заказчика и не содержат решения и характеристик.
Например, это может быть: «Я, как холостой мужчина 40 лет, хочу убирать зимние вещи из шкафа, и тогда у меня будет место, чтобы повесить летние вещи».
И на этом этапе, когда вы узнали потребность вашего пользователя, вы можете задать ему вопросы:
А какие это вещи?
Насколько их много?
и так далее.
Далее несете это требование команде и вместе придумываете решение, которое наиболее полно решит проблему заказчика, будет дешевле для заказчика и проще для вас в реализации. И это может быть вовсе не коробка ;)
А, например, дополнительные вешалки или вообще сервис по хранению вещей вне дома с доставкой, а может, это будет и простая картонная коробка.
Спрашивайте больше «зачем», разбирайтесь в проблеме заказчика, и только потом предлагайте более простое и наилучшее решение
Вторая ошибка — писать требования в письменном виде и молча передавать в разработку, ставя задачи
В таком контексте теряется смысл, который вы закладываете в требования. Когда аналитик разбирается в том, что нужно сделать, он может в процессе анализа хорошо разобраться, что действительно нужно, но в тексте этот смысл потеряется, так как невозможно его досконально передать.
Это как с фотографиями с отпуска — одно дело, вы молча отправите их своим друзьям, а другое дело — вместе соберетесь и вы расскажете, как на самом деле все было. Для вас это не просто фотографии, в них заложен большой смысл, который остается за кадром — это атмосфера, ваши чувства, эмоции, запахи и так далее. То же самое с требованиями в разработке продукта. Когда вы передаете сухой документ — разработчики теряют смысл того, что действительно нужно сделать, и качество решений получается сильно ниже.
Итого: Уходите от детальных описаний решений, а вместо этого эти требования создавайте вместе с командой, вовлекайте команду в разработку требований и придумывания решения все вместе. Это могут быть встречи, воркшопы, мозговые штурмы или непрерывный процесс, в котором все участвуют.
Третья ошибка — описывать большой объем требований наперед
В Agile процесс разработки требования идет итеративно, в зависимости от фокуса команды в данный момент итерации. Не стоит писать детальные требования дальше чем на 1-2 итерации, так как все, скорее всего, поменяется. Не тратьте на это время. Формулируйте требования в пользовательских историях в легком формате и храните их в беклоге. А при решении о скором создании — собирайтесь и обсуждайте детали с командой, фиксируя критерии приемки.
Что такое критерии приемки?
Это детали, которые вы выясняете в процессе проработки пользовательской истории. И также это список, по которому вы будете проверять — выполнена ли пользовательская история или нет.
Например: «Я, как холостой мужчина 40 лет, хочу убирать зимние вещи из шкафа, и тогда у меня будет место, чтобы повесить летние вещи».
Критерии приемки:
Вещи сложены в специальный отсек и не мнутся
Объем вещей — 100 литров
Отсек должен быть в высоту не более 55 см
В отсеке должно быть разделение для верхней одежды
Если резюмировать, рецепт Agile-требований такой:
Не тратьте месяцы на то, чтобы описать досконально все в начале проекта, идите последовательно, формируйте более детальные требования на 1-2 итерации вперед и описывайте их в легковесном формате в виде критериев приемки.
Вместо фокуса на решении, сформулируйте основные пользовательские истории и далее в ходе разработке уточняйте их. Задавайте вопросы «Зачем», когда вам приносят готовое решение на вход, чтобы разобраться в проблеме пользователя и заказчика.
Придумывайте решение пользовательским историям вместе всей командой в ходе мозговых штурмов, встреч. Используйте доски, чтобы рисовать. Такие встречи сэкономят время и улучшат понимание контекста командой. А качество решений будет выше.
А если вам понравилась статья, жду в своем телеграмм-канале и на сайте.
Приглашаем всех желающих на открытое занятие «Бизнес для ИТ или ИТ для бизнеса?», на котором обсудим:
- Зачем компании нужен БА?
- Как БА взаимодействует с другими участниками процесса?
- Почему БА важен для успешной трансформации компании?
Регистрация доступна по ссылке.
