Меня зовут Наталья Кобякова, я 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. Переходите по ссылке, смотрите мой доклад и другие, возможно, будет интересно.
Комментарии (8)
sharmin_av
22.11.2022 10:42Наверное в реалиях конкретной компании данный подход применим, но в целом возникает много вопросов по подходу.
где в этой схеме бизнес-процесс, описанный и визуализированный в общепринятой нотации со всеми его вариантами развития? Как мне кажется, что тестовое описание в Miro не является оптимальным решением для такого типа задачи. Разработка схемы процесса на этапе формирования документации тоже не самая лучшая практика, потому что выявить проблемы на финальном этапе это не очень хорошо.
на этапе "Исследуем и детализируем истории" не описана стратегия работы с рисками и ограничениями, только детализация US. Если доска в Miro является основным способом коммуникации с заказчиком, то риски и ограничения должны фиксироваться в явном виде на этой доске. Как фиксируются в явном виде?
при решении любой задачи первичным, кроме бизнес-процессов, является архитектура этого решения, которая должна ответить на много вопросов, в частности варианты интеграции между системами (расширение существующих интеграций, создание новых и т.п.), участвующие системы и т.п., что в свою очередь имеет большое влияние на оценку трудозатрат. Как в концепции US решается вопрос проработки архитектуры, с учетом того, что ответы на многие вопросы не могут быть получены в режиме групповой проработки и требуют более глубокого и детального изучения и погружения?
Очень часто у бизнеса, у заказчика есть идея, есть ожидаемые доходы от реализации идеи и бизнес хочет получить ответ от IT сколько будет стоить реализация его идеи, чтобы понимать нужно вообще инвестировать в это или идея никогда себя не окупит. Чтобы получить ответ на это вопрос необходимо привлекать всю команду, даже в том случае если это просто получение оценки стоимости разработки? Как в это случае избежать формирования ТЗ?
как сторипоинты трансформируются в деньги, если это некая абстрактная единица оценки? Любой бизнес-заказчик мыслит деньгами, которые от тратит на внедрение и прибылью, которую он получает? Как понимать заказчику, что оценка в сторипоинтах уместится в его бюджет в рублях, долларах или евро?
kanifolinka Автор
23.11.2022 10:02+1Ой, вы-таки хотите, чтобы я раскрыла сразу все секреты наших процессов))
Каждый ваш вопрос вполне справедлив, но выходит за рамки этой статьи и заслуживает рассмотрения в отдельных статьях. В этой статье я описывала именно ту часть процесса, которая относится к работе аналитика с уровнем пользовательских и системных требований.
Попробую ответить кратко:
где в этой схеме бизнес-процесс, описанный и визуализированный в общепринятой нотации со всеми его вариантами развития?
Моделирование бизнес-процесса у нас относится к уровню работы с бизнес-требованиями и там, где это применимо, аналитик выполняет моделирование БП в BPMN, а дальше блоки из БП прорабатываются до уровня пользовательских требований и перекладываются в USM.
на этапе "Исследуем и детализируем истории" не описана стратегия работы с рисками и ограничениями, только детализация US. Если доска в Miro является основным способом коммуникации с заказчиком, то риски и ограничения должны фиксироваться в явном виде на этой доске. Как фиксируются в явном виде?
Да, вы правы, риски и ограничения фиксируются в явном виде. На PI-планировании для этого выделяется отдельная доска в Миро, затем риски переносятся в Jira и работа с ними так же ведется в течение всего квартала. Но эта часть работы лежит вне плоскости работы с требованиями.
при решении любой задачи первичным, кроме бизнес-процессов, является архитектура этого решения, которая должна ответить на много вопросов, в частности варианты интеграции между системами (расширение существующих интеграций, создание новых и т.п.), участвующие системы и т.п., что в свою очередь имеет большое влияние на оценку трудозатрат. Как в концепции US решается вопрос проработки архитектуры, с учетом того, что ответы на многие вопросы не могут быть получены в режиме групповой проработки и требуют более глубокого и детального изучения и погружения?
US — это способ работы с пользовательскими требованиями, и он никак не исключает необходимости привлечения архитектора решений или системного архитектора к проработке отдельных историй/всего эпика в случае сложных интеграционных взаимодействий. У нас существуют четкие критерии привлечения архитектора к проработке, при этом архитектор решений подключается, как правило, заранее, и на PBR с командой приходит уже с готовой архитектурной схемой.
Очень часто у бизнеса, у заказчика есть идея, есть ожидаемые доходы от реализации идеи и бизнес хочет получить ответ от IT сколько будет стоить реализация его идеи, чтобы понимать нужно вообще инвестировать в это или идея никогда себя не окупит. Чтобы получить ответ на это вопрос необходимо привлекать всю команду, даже в том случае если это просто получение оценки стоимости разработки? Как в это случае избежать формирования ТЗ?
Нет, как раз для верхнеуровневой оценки окупаемости идеи достаточно такой же верхнеуровневой декомпозиции и понимания, сопоставима ли сложность реализации с тем ожидаемым результатом, который вкладывается в идею. При этом ожидаемый результат может измеряться не только прямыми доходами — это ключевое отличие от проектной разработки — здесь полноценно включается в рабочий процесс расчет unit-экономики, но это уже вне границ ответственности аналитика.
как сторипоинты трансформируются в деньги, если это некая абстрактная единица оценки? Любой бизнес-заказчик мыслит деньгами, которые от тратит на внедрение и прибылью, которую он получает? Как понимать заказчику, что оценка в сторипоинтах уместится в его бюджет в рублях, долларах или евро?
Понятие "заказчик" — это снова из проектной разработки. В проектной разработке есть проектный треугольник, и полноценное подробное ТЗ необходимо для того, чтобы заранее выполнить оценку сроков и стоимость разработки всего проекта в силу ограниченности бюджетов.
Мы же говорим про продуктовую разработку, где применим подход работы через MVP, применимы гибкие методологии и есть возможность быстро тестировать гипотезы понятными ресурсами, а затем уже развивать, если гипотезы подтвердились. USM как раз и помогает понять, что нам нужно сделать и в каком объеме, чтобы получить первые результаты — глядя на USM, мы можем понять, сколько спринтов будет работать кросс-функциональная команда над MVP, рассчитать затраты на эту команду в этом периоде, выполнить разработку, снять полученные показатели и понять, а есть ли смысл идти в этом направлении дальше или лучше изменить вектор развития продукта.
sharmin_av
23.11.2022 17:00Спасибо за ответы! Это круто, когда в статье идет живое конструктивное обсуждение, позволяющее более детально понять мысли автора.
Но исходя из написанного, хочется отметить, что по факту ТЗ существует, но лишь приобретает несколько иную форму: это схемы бизнес-процессов, проработанные аналитиком и согласованные с бизнесом, и артефакты от архитектора решений / системы, которые готовятся предварительно.
То есть по факту, даже при использовании USM "первичная документация" должна быть, , иначе фактуры, на основании которой формируются US нет. О чем вы и написали.
Наверное, не корректно отождествлять требования от бизнеса (оно же ТЗ, оно же БТ) с техническим заданием, разрабатываемым по ГОСТу.
И ещё, ГОСТ 19.101.77 в части листинга программного кода это не про постановку задачи, поэтому пример не совсем корректный. Наличие программного кода (листинга) сейчас до сих пор обязательно при оформлении авторских прав на программу.
kanifolinka Автор
23.11.2022 17:25хочется отметить, что по факту ТЗ существует, но лишь приобретает несколько иную форму: это схемы бизнес-процессов, проработанные аналитиком и согласованные с бизнесом, и артефакты от архитектора решений / системы, которые готовятся предварительно.
То есть по факту, даже при использовании USM "первичная документация" должна быть, , иначе фактуры, на основании которой формируются US нет. О чем вы и написали
Архитектура и БТ - это все же не ТЗ, даже в классическом подходе, и работа над ними лежит вне скоупа работ аналитика, поэтому их я оставляю за скобками)
И в ГОСТ, например, для этого есть вообще отдельные виды документов.Тем не менее, вы полностью правы, работа аналитика должна на чем-то базироваться, независимо от подхода через ТЗ или через USM, поэтому БТ + архитектура будут первичными в любом случае.
В моей же статье речь идет как раз о другой форме работы с требованиями именно с точки зрения аналитика - не в формате полновесного документа, а в формате командного взаимодействия на стадии проектирования и формализации требований и описания деталей реализации по итогам обсуждения с командой. И этот формат работы включается только после сбора первичной информации, безусловно.Наверное, не корректно отождествлять требования от бизнеса (оно же ТЗ, оно же БТ) с техническим заданием, разрабатываемым по ГОСТу.
А вот тут не соглашусь. БТ != ТЗ. БТ - это постановка задачи, на основе которой далее выполняется проработка реализации.
И ещё, ГОСТ 19.101.77 в части листинга программного кода это не про постановку задачи, поэтому пример не совсем корректный. Наличие программного кода (листинга) сейчас до сих пор обязательно при оформлении авторских прав на программу.
Пример про листинг был скорее для того, чтобы показать, что ГОСТ создан очень давно и местами оторван от существующей современной реальности. Листинг - это отдельный документ из общего набора документов, в статье я как раз об этом писала)
rm-hbr
22.11.2022 10:42В usm как описываются условные переходы, когда все шаги строятся линейно?
kanifolinka Автор
23.11.2022 10:14+1Тут возможно несколько вариантов:
Если речь идет о сложном бизнес-процессе, перед переходом на USM прорабатываются бизнес-требования, включающие в себя моделирование бизнес-процесса в BPMN, и в этом случае BPMN перекладывается в USM в рамках перехода от бизнес-требований к пользовательским требованиям.
Если условные переходы — это самостоятельные и независимые US, они размещаются в USM в одном эпике и их реализация может быть разнесена во времени (например, истории "Я как пользователь хочу оплатить заказ..." и "Я как пользователь хочу получить уведомление о возврате средств, если заказ был отменен..." вполне могут реализовываться независимо друг от друга).
Если условные переходы неотделимы и должны реализоваться в одной US, они описываются в пользовательских сценариях / критериях приемки / деталях реализации.
BA_TW
Мы используем похожий подход, но кто у вас в итоге описывает обработку ошибок, способы решения, детали реализации? Аналитики? Вы в статье сказали, что аналитик "не способен проектировать решения на уровне системного архитектора".
Я за свой опыт пришла к тому, что аналитик таки должен быть способен на это и еще быть "достаточно технически подкован, чтобы разбираться в сложных программных нюансах". По крайне мере, в общих чертах. В идеале - проконсультировавшись с архитектором. Т.е. в нашем случае аналитик предлагает некое архитектурное решение архитектору, а тот в свою очередь, вносит корректировки при необходимости, затем уже аналитик фиксирует все в документации, которая передается разработчикам.
kanifolinka Автор
Обработку ошибок, способы решения и детали реализации описывает аналитик, но есть несколько нюансов:
Интеграционное взаимодействие изначально проектирует архитектор решений - он принимает решение о том, какие системы и какие микросервисы должны взаимодействовать при сложных межсистемных связях. Аналитик эту информацию использует для дальнейшей проработки, но не проектирует сам, т.к. эти вопросы выходят за границы домена, с которым работает аналитик.
Негативные сценарии и то, как они должны обрабатываться - это, безусловно, часть работы аналитика, как и все то, что относится к уровню пользовательских требований. К команде аналитик приходит с готовыми US и пользовательскими сценариями, на основе которых происходит обсуждение деталей реализации.
Способы решения, детали реализации и обработка ошибок сначала прорабатываются совместно всей командой (в сложных случаях с привлечением системного архитектора) на PBR и затем уже описываются аналитиком. Это позволяет, во-первых, донести до команды понимание бизнес-целей и ценности реализации для пользователя, а во-вторых, найти наиболее оптимальные пути решения, которые один аналитик не всегда может увидеть.