Меня зовут Наталья Кобякова, я Product owner и техлид клана аналитиков в Ak Bars Digital. В этой статье я расскажу, почему для проектирования функциональности наших продуктов вместо стандартных ТЗ мы используем методологию User Story Mapping и как это помогает нам вести разработку быстро и качественно.
Дисклеймер: в статье я не призываю окончательно и бесповоротно отказаться от ТЗ, но хочу сказать, что классическое ТЗ подходит не во всех ситуациях, и не для всех команд разработки.
Мифы о ТЗ
Главный миф о ТЗ — техническое задание жизненно необходимо, чтобы разработка любого цифрового продукта была выполнена качественно, а без него все будет как на картинке.
В таком подходе написание ТЗ — это отдельный этап разработки, на выходе из которого появляется подробный, максимально детальный документ, в идеале, написанный по ГОСТ. И без такого документа к команде разработчиков даже подходить нельзя. Даже среди команд, работающих по Scrum, нередко встречаются такие, где задачи на разработку приходят только после подготовки аналитиком ЧТЗ — частного технического задания.
При этом, как правило, все участники процесса забывают, что ГОСТы были придуманы на заре цифровизации. Получается, что они практически не менялись с тех времен, когда ЭВМ были размером с хороший шкаф-купе, память этих монструозных вычислительных машин была как у рыбки, а подходы к разработке были совсем другими.
До сих пор, в межгосударственном стандарте ГОСТ 19.101-77 есть требование прикладывать листинг программ «Текст программы» (физическая распечатка программного кода) наравне с другими обязательными документами, входящими в проектную и рабочую документацию.
Но, зачем?!
Вспомним, что в те давние времена еще не было не только «облаков», AirDrop, GitHub и прочих классных вещей, но даже элементарных дискет. Просто не существовало никакой физической возможности переноса программы с одной ЭВМ на другую. И операторы ЭВМ каждый раз вводили программу вручную, перепечатывая текст из того самого обязательного документа «Текст программы».
Собственно, как наследие тех времен, до сих пор широко распространены каскадная разработка (Waterfall) и подход к документированию по ГОСТ, ставшие актуальными именно в то время. Например, так пишут в Википедии:
«Без рывка в сфере вычислительной техники, сделанного в 1940-е гг. и чётко сформулированного технического задания к разработчикам такого рода, вычислительная техника не развилась бы до современных компьютеров…»
В 1970-х были разработаны стандарты оформления проектной и рабочей документации на разработку ПО, а четко сформулированное ТЗ было не только жизненной необходимостью, но и залогом успеха всего процесса разработки и ввода ПО в промышленную эксплуатацию.
Госзаказчики (и не только они!) и сейчас очень любят писать задания на разработку по ГОСТ — кажется, что это гарантирует качество. Почему? Потому что создает иллюзию того, что ход всего проекта будет под контролем, если все детально задокументировано. А если вдруг в процессе обнаруживаются отклонения, нужно вернуться на шаг назад и начать все заново — с переработки ТЗ.
В условиях отсутствия конкуренции этот подход был вполне оправдан: не сжигаются ресурсы на разработку, не тратится напрасно ценное время работы ЭВМ, все регламентировано и документировано.
Проблемы ТЗ для продуктовой разработки
Применим ли такой подход к разработке в современных реалиях? Применим, но для проектной, а не продуктовой разработки.
В чем же отличия?
Проект — всегда конечен, как по бюджету, так и по срокам запуска. Упрощенно: выиграть тендер, написать строгое и четкое ТЗ по требованиям заказчика, выполнить по нему разработку и запуск проекта к заданной дате, и после этого о существовании проекта забыть — это проектный подход. Под проект, как правило, собирается команда, которая будет расформирована или переведена на другие задачи сразу после успешного (или не очень, тут уж как повезет) запуска проекта. И в этом случае разработка с ТЗ оправдана.
Продукт — это постоянное развитие. Продуктовая разработка — это непрерывный бесконечный процесс, ставящий перед постоянной командой вызовы: разрабатывать новый продукт, выводить его на рынок, развивать и улучшать, формулировать гипотезы, обновлять интерфейсы, добавлять новые фичи, собирать метрики и на их основе строить новые планы, не имея определенного срока завершения работы. Успешность и готовность продукта измеряются прибыльностью, востребованностью, пониманием потребностей клиентов и готовностью к быстрым изменениям, а потому проектный подход тут практически не применим.
У нас в компании ведется продуктовая разработка кросс-функциональными командами, и наша основная цель — быстрое и успешное развитие продуктов. Поэтому в наших условиях длительное проектирование и написание ТЗ привели бы к существенным потерям: ценности, времени, качества и ресурсов.
Потеря ценности
В проектной разработке, как правило, ТЗ прорабатывает один человек: системный аналитик или технический писатель. Иногда, если компания серьезно ограничена в ресурсах, то даже менеджер проекта.
Этот человек сначала общается с бизнес-заказчиком, собирает набор требований к системе и описывает их в огромном, по объему, документе. При этом, в большинстве случаев, описываемая функциональность системы — это либо личные хотелки заказчика, либо прямое копирование у конкурентов, не подтвержденное исследованиями, гипотезами, опросами, метриками и данными.
По сути, на входе системный аналитик получает набор «галлюцинаций» (отличный термин от ФРИИ), на основе которых проектирует решение, формирует требования и оформляет это всё в ТЗ. Дальше этот документ отправляется на реализацию в команду разработки, вынужденную слепо и максимально точно следовать написанному.
И на деле, аналитик часто не знает, что действительно нужно конечному пользователю, потому что не всегда хорошо погружен в контекст, если вообще погружен.
Потеря времени
В проектной разработке техническое задание — фундамент всего проекта. Ему должно уделяться достаточно времени и внимания, чтобы все заинтересованные стороны убедились: проект будет таким, как планировалось на начальном этапе.
Однако, обычно ТЗ пишется «на конвейере» и в условиях постоянной нехватки времени. Заказчики не считают нужным прочитать его, хотя бы поверхностно, говоря «Ой, я все равно в этом ничего не понимаю», а разработчики не вникают в детали, делая то, что они привыкли делать ранее. В итоге на выходе появляются расхождения между картинкой, придуманной заказчиком, требованиями, описанными аналитиком, и результатом, разработанным командой. И проект уходит на следующий виток с теми же самыми шагами: новое ТЗ, новые согласования, сдвиг сроков запуска.
Потеря качества
Аналитик:
не может в одиночестве на этапе проектирования учесть все возможные аспекты разработки;
не способен проектировать решения на уровне системного архитектора (и не должен);
не отслеживает новые инструменты, фреймворки и тренды разработки, потому что у него времени на это нет;
и даже не всегда достаточно технически подкован, чтобы разбираться в сложных программных нюансах.
Увы, мне не так давно еще встречались ТЗ, где интеграция с внешней системой описывалась одной фразой: «ресурс А будет интегрирован с ресурсом Б». То есть, все, начиная с модели данных, заканчивая схемой взаимодействия, оставалось тайной, покрытой мраком.
Конечно, здесь могли бы помочь разработчики, но проектный подход не подразумевает их подключения на стадии ТЗ и ведет к удорожанию проекта, на которое заказчики идти не готовы. В итоге, качество проектирования страдает, качество разработки, как следствие, падает, качество выпущенного проекта оставляет желать лучшего.
Ресурсы разработки ограничены
Если одна женщина способна родить ребенка за 9 месяцев, это не значит, что 9 женщин способны родить ребенка за месяц. С командой разработки работает точно такой же принцип: на качественную разработку сложного комплексного программного решения требуются сильные, опытные разработчики, временной ресурс которых ограничен. И когда разработка ведется строго по ТЗ, далеко не факт, что мы используем этот ресурс оптимально, потому что запуск проекта состоится только после того, как будет выполнена реализация всех задач по ТЗ.
В моем опыте был кейс, когда разработка велась 2 года, и выпущенный «в мир» проект успел за это время морально устареть, хотя задумывался как инновационный.
User Story Mapping: что это такое и в чем польза такого подхода
В нашем рабочем процессе мы активно используем методологию User Story Mapping. USM или карта пользовательских историй — это инструмент проектирования продукта, в основе которого лежит путь клиента. На картинке приведен пример шаблона User Story Map, уже в итоговом, полностью завершенном виде, а ниже рассмотрим, как такая карта составляется.
Как составляется USM?
Работа над картой пользовательских историй состоит из шести основных шагов:
Формулируем проблему: что, для кого и зачем мы собираемся делать.
Обрисовываем общую картину: смотрим на верхнеуровневые процессы и действия пользователя, проходим по его шагам, двигаясь «на километр вперед, на сантиметр вглубь». Каждое действие фиксируем как отдельный эпик.
Исследуем и детализируем истории: изучаем возможные типы пользователей, рассматриваем разные варианты выполнения действий, прорабатываем негативные сценарии — так у нас появляются пользовательские истории, которые можно дополнительно декомпозировать на отдельные задачи.
Выделяем релизную стратегию: концентрируемся на том, что в первую очередь нужно бизнесу и людям, для которых создаем продукт. Определяем длительность спринтов, емкость команд, график релизов.
Выделяем исследовательскую стратегию: что войдет в MVP, какие гипотезы у нас есть, как мы сможем их проверить. Выделяем те истории, без которых продукт не сможет существовать, и откладываем все, что можно исключить на первом этапе без потери ключевых возможностей.
Выделяем стратегию разработки. Делим MVP на части, с точки зрения последовательности разработки так, чтобы как можно раньше все запустить. В итоге мы получаем четкую последовательность задач, разбитых на спринты, и видим, в какие сроки сможем поставлять обновления продукта для наших клиентов.
Как шаги выглядят на практике?
Мы работаем в распределенных командах, где все работают удаленно, а карта пользовательских историй — это инструмент для постоянной работы, поэтому для USM мы используем Miro. Все примеры, которые я приведу ниже, взяты из реальной жизни, с доски одной из наших команд. Итак, пройдемся по шагам нашего процесса.
Формулируем проблему
Недавно в нашем мобильном приложении Ак Барс Онлайн мы решили запустить кросс-продажи кредитных продуктов клиентам банка. Если для банка это дополнительная прибыль, то для клиента — предодобренный кредит без необходимости заполнять длинную заявку, посещать офис и приносить документы менеджеру.
Обрисовываем общую картину
При составлении общей картины мы привлекаем стейкхолдеров, на этом этапе происходит активное взаимодействие владельцев продукта и аналитиков, чтобы совместными усилиями понять, как пользователь взаимодействует с продуктом.
Так, в случае с кросс-продажами, мы прошли по всем шагам оформления кредита, обычно выполняемым клиентами, и составили общую последовательность действий. Наша доска после этого выглядела примерно так:
Исследуем и детализируем истории
После того, как определены шаги, каждый зафиксированный эпик и пользовательскую историю можно и нужно дополнительно декомпозировать, не забывая о ценности для клиента.
Формат пользовательской истории изначально подразумевает формулировку «Я, как пользователь, хочу X, чтобы получить Y». Но для доски в Miro такая фраза слишком длинная, поэтому:
в заголовок мы выносим ключевое действие, например «Загрузить документы, подтверждающие доход»;
а в описании истории фиксируем «Я, как пользователь, хочу сфотографировать и прикрепить к заявке документы, подтверждающие доход, чтобы сэкономить время и получить одобрение большой суммы без посещения офиса».
Декомпозиция историй выполняется до тех пор, пока каждая из историй не будет отвечать критериям INVEST (независимость, обсуждаемость, ценность, возможность оценки сроков реализации, компактность, тестируемость).
И скелет USM в Miro начинает обрастать деталями:
При декомпозиции историй мы дополнительно ищем ответы на вопросы:
кому еще функциональность может быть интересна;
какие у нас есть ограничения и какие из них действительно критичны;
какие исключительные ситуации могут возникнуть;
можем ли мы решить эту же задачу другими способами?
Этот этап — самый важный. Именно здесь можно найти моменты, которые будут вызывать у пользователя wow-эффект при работе с продуктом, и устранить препятствия, кажущиеся уже привычными. Так, например, мы обнаружили, что для зарплатных клиентов банка вовсе не обязательно требовать документы, подтверждающие доход, и клиентский путь для таких клиентов можно сократить втрое, сделав простое определение типа клиента на входе в заявку!
На этом же этапе у нас выполняется оценка трудозатрат на реализацию каждой истории в сторипойнтах (SP). Но тут есть важная деталь: в SP мы оцениваем не столько время, которое будет затрачено на разработку, сколько усилия на решение задач: объемность, сложность, понятность для разработчиков, возможные риски.
Задача по передаче документов на проверку сама по себе не сложная для нашей команды. Но она требует выполнить интеграционное тестирование со смежной системой, в которую должны быть переданы документы, и тестирование всего процесса, от прикрепления документов до получения результатов их рассмотрения, – а это уже существенное усложнение всей истории.
Выделяем релизную стратегию
У нас стандартная длина спринта — две недели, и в каждом спринте емкость команды, занимающейся кредитами (velocity) — 21 SP. Однако, реальная вместимость задач в спринте будет зависеть от количества праздников и выходных дней, а также возможных отпусков разработчиков. Поэтому для определения релизной стратегии важно рассчитать не только емкость команды, но и вместимость (capacity). Например, при средней емкости в 21 SP, в одном из спринтов сразу трое коллег из команды собираются уйти в отпуск, и вместимость составит только 7 SP. В релизной стратегии важно это учесть, потому что это напрямую повлияет на тот объем задач, который команда успеет выполнить в конкретный спринт.
Выделяем стратегию исследований
Определив релизную стратегию и имея набор оцененных задач, мы можем переходить к приоритезации и формировать последовательность, в которой будем реализовывать задачи с учетом их важности для клиентов и прибыльности для бизнеса.
При работе на доске это выглядит как раскладывание историй по спринтам с учетом их оценки и вместимости команды в конкретном спринте. На выходе из этого этапа мы получаем цельную картину, понятную не только разработчикам и аналитикам, но и стейкхолдерам, без необходимости вчитываться в детальную документацию. На такой доске сразу видно, что делаем, когда и какой результат получим.
А дальше идет разработка и реализация с командой, но это уже другая история…
Как USM закрывает проблемы?
Когда мы составляем карту пользовательских историй, мы разбираем каждый шаг клиента, и не просто понимаем, чего он хочет, но и с какой целью. А уже на основе проработанных пользовательских целей и потребностей разрабатываем и формализуем требования к системе. При разработке функциональности по этим требованиям мы планируем работы так, чтобы ресурсы разработки использовались максимально эффективно. Давайте сверим, как же USM закрывает проблемы, которые были описаны выше?
Постоянно помним о ценности
Мы разрабатываем USM на основе ценности для клиента, и весь бэклог основан на пользовательских сценариях. Для разработки всегда выбираем только то, что действительно важно для пользователя и несет ценность для бизнеса.
Экономим время
Очевидно, что при таком подходе нет лишней работы ни в каждом спринте, ни в целом. Мы делаем только то, что действительно необходимо для достижения наших целей, не тратим время на описание лишних фич в ТЗ. А благодаря гибким методологиям, мы можем оперативно пересмотреть наши планы, если поймем, что сформулированные гипотезы не подтвердились метриками и мы идем куда-то не туда.
Сохраняем высокое качество разработки
Пользовательские истории прорабатываются всей командой в ходе совместных обсуждений. История считается готовой к разработке только после того, как каждый член команды подтверждает, что ему все понятно, договоренности о реализации достигнуты, критерии приемки определены, и вся команда с ними согласна. Такой подход позволяет сохранять высокий уровень вовлеченности команды и заинтересованности в конечном результате.
Почему мы выбрали User Story Mapping?
Важно! Такой подход не отменяет документацию.
Все описанное не означает, что у нас вся документация ограничивается доской в Miro или строится на устных договоренностях в команде. Просто мы идем от обратного: не пишем ТЗ и не ставим по нему задачи.
Сначала мы формулируем истории и описываем пользовательские сценарии, затем обсуждаем вместе с командой критерии приемки, технические заметки, описание обработки ошибок и способы решения, детали реализации, и уже потом подтверждаем все договоренности и формализуем их в Confluence.
Как итог получаем и готовую документацию, и список задач. При этом каждый член команды знает, что он делает и зачем, и у каждого члена команды есть единое понимание бизнес-контекста.
Главное в USM для нас — это гибкость и адаптивность, формирование особой культуры разработки, когда каждый участник команды понимает свою роль, предлагать оптимальные варианты реализации, может влиять на результат, а не просто пишет код по ТЗ.
Статья подготовлена на основе моего выступления «User story map — карта поиска сокровищ при создании MVP» на митапе Three Amigos Talk. Переходите по ссылке, смотрите мой доклад и другие, возможно, будет интересно.
