Об идеальных требованиях

Вам когда-нибудь встречались идеальные требования? Мне нет. Будь это водопад или Agile с ними всегда что-то не так.

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

В Agile не легче. Вроде бы есть user story: легкий и понятный формат, главное правило которого уложить все в мантру "Я как <роль пользователя> хочу получить <что-то>, для того чтобы <что-то>" (так я думал до прочтения книги, о которой пойдет речь ниже - не переключайтесь). Но вопросов все равно много: как обсуждать, как формулировать, и как потом понимать, какие решения были приняты и почему.

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

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

И вот недавно мне попалась в руки книжка Джеффа Паттона "Пользовательские истории. Искусство гибкой разработки ПО".

Изображение с сайта https://ozon-st.cdn.ngenix.net/multimedia/1017899842.jpg

Сразу скажу, эта книга значительно изменила мое представление о user story. И хотя у меня за спиной были другие книги, статьи, курсы по Agile и так далее -  эта книга стала настоящим откровением. Примерно таким: "эээ, а что же консультанты продают под видом user story?".

Одна из идей, которую я вынес из книги: user strory - это просто не красивый формат, не просто стикер на доске. User story - это в первую очередь общее понимание проблемы и ее решения. Это история о вашем продукте, которую вы рассказываете друг другу и которую одинаково понимаете. Карточка - это всего лишь фиксация основных моментов этого понимания, поэтому она вторична.

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

С другой стороны - если сформировать общее понимание, формат требований может быть любой - хоть ТЗ, хоть любовная записка на салфетке. Если с вашими друзьями вы смотрели один и тот же сериал, достаточно назвать имя героя, чтобы вы одинаково представили его внешность.

Получается, что проблема с требованиями зачастую глубже, чем просто формат текста. Если мы обмениваемся письменными артефактами вместо выработки общего понимания - мы сами создаем себе проблему разных контекстов.

И что с этим делать? Решение звучит гораздо проще, чем реализуется - создавать общее информационное поле для всех участников команды. Что мы для этого делали в разных командах:

• садились рядом (кросс-функционально);
• проводили встречи, где всей командой обсуждали цели, видение результата и совместно прорабатывали решение;
• визуализировали решение с помощью схем, мокапов, интерактивных прототипов;
• если сроки поджимали, делали выбор в пользу совместной работы с фиксацией основных моментов вместо формального заполнения шаблонов. 

А в завершение приведу выдержку из книги "Пользовательские истории. Искусство гибкой разработки ПО", Глава 7, Шаблонные зомби и снегоочиститель:

Термин «шаблонные зомби» впервые появился в книге Тома Де-Марко и его соавторов «Адреналиновые наркоманы и шаблонные зомби: понимание паттернов поведения проектов». Название говорит само за себя, но я приведу и авторское определение.

«Шаблонный зомби: проектная команда допускает, чтобы работа управлялась шаблонами, а не направляет процесс осознанно, чтобы обеспечить выпуск продукта наилучшим образом».

Мы, в принципе, склонны злоупотреблять простотой использования таких вещей, как шаблон. Я неоднократно наблюдал, как люди мучаются, изо всех сил пытаясь впихнуть в шаблон идеи, которые в него не помещаются. Истории работы серверной части или функций, обеспечивающих безопасность данных, не так-то легко составить. Я также видел, как люди пишут и думают, ориентируясь на собственное представление о чем-то, а не на точку зрения людей, которые должны получить выгоду: «Как владелец продукта, я хочу, чтобы вы сделали кнопку для загрузки файла, таким образом мы удовлетворим требования заказчика». Просто ужас. 

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