Жизненный цикл любого проекта включает в себя этапы инициации, планирования, исполнения, контроля и завершения. Гибкие методологии и итерационный подход используют в проектах по разработке программного обеспечения всё чаще. С ними этапы проекта повторяются несколько раз для каждой итерации, а перечень инструментов аналитика максимально упрощается и сводится до написания user story. 

Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта.  Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик». 

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

Я попробую развеять эти сомнения на примере учебного проекта, в рамках которого:

• мы рассмотрим уровни детализации требований, на пяти фазах жизненного цикла проекта,

• подберем инструменты анализа требований разных типов,

• попробуем заменить тяжеловесную документацию (ТЗ, SRS) на сочетание Wiki и таск-трекера. 

Разбираться будем на учебном примере вымышленного банка DBT, с использованием бесплатных инструментов: Yandex Tracker, Yandex Wiki. 

Стартуем: исходные данные проекта

Deep town bank — высокотехнологичный банк, я буду использовать сокращённое название DTB. Для поддержания работы DTB выстроили внушительную IT-архитектуру,  в которой есть клиентские мобильные и web-приложения, несколько сотен серверных приложений. 

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

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

Инициация

Фаза инициации — первая фаза цикла, на которой прорабатывают концепцию проекта и продукта, определяют ресурсы и примерные сроки реализации.
Этой фазе характерен высокий уровень неопределённости. 

• Заказчик приблизительно понимает, что ему нужно, пока требования только формулируются. 

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

Задачи аналитика на этом этапе нацелены на определение границ проекта. Возможная выгода от проекта ещё не определена, её может и не быть, а на первичный анализ нужно потратить время (как минимум аналитика и заказчика). Чтобы минимизировать возможные убытки, нужно тратить на первичный анализ минимально возможное количество времени.

Задачи аналитика на фазе инициации:

1. Определить бизнес-проблемы и бизнес-цели.

2. Сформировать список заинтересованных сторон.

3. Сформулировать верхнеуровневые пользовательские и функциональные требования.

4. Сформулировать варианты реализации.

1. Определяем бизнес-проблемы и цели 

Бизнес-требования — это верхний уровень абстракции требований к системе. Они не относятся напрямую к реализации системы, а отражают цели бизнеса, абстрагированные от реализации системы. 

• Бизнес-требования помогают определить смысл и цель разработки, а также обосновать их необходимость, определяют круг проблем и предлагают способы их решения.

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

Представим, что мы выступаем в роли full stack (совмещаем роли бизнес- и системного) аналитика DTB-банка, которому пришло сообщение от руководителя отдела развития клиентского сервиса.

«Нам нужно, чтобы несколько клиентов могли пользоваться одним счётом. Нужно прикинуть, сколько времени займёт разработка. Там не сложно, можно просто привязывать разные карты к одному счёту».

Это пример плохого описания запроса на оценку доработки системы. В нём написано, что и как нужно сделать, но не сказано, зачем и кому это нужно. 

Если воспринять этот запрос как требования, которые нужно реализовать в любом случае, есть риск потратить время команды разработки и при этом раскрыть банковскую тайну клиентов, нарушить требования ПОД/ФТ и внести ненужные изменения в архитектуру системы. А потом ещё поддерживать работу никому не нужного функционала. Мы не получим выгоды и понесём убытки из-за потраченных ресурсов. Описание плохое, но, к сожалению, именно этот формат часто используют на практике.

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

Как выявить бизнес-требования, или «Пять почему»

Чаще всего бизнес-требования выявляют с помощью интервью заказчика и применения метода «Пять почему». Аналитик общается с заказчиком и задаёт ему вопросы: «Почему?», «Зачем?», «С какой целью?», «Кому это нужно?»,  пока не сформулирует измеримые цели доработки. 

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

В нашем примере нужна доработка системы, у которой сотни заинтересованных сторон — клиенты банка, сотрудники подразделений DTB (команды сопровождения и разработки DTB). У заинтересованных сторон есть представление, как улучшить приложения DTB, но не будет  ресурсов, чтобы реализовать все их потребности. 

Чтобы оценить, чьи бизнес-проблемы нужно решать сначала, собираем запросы в одном месте — реестре запросов на изменение. В нём фиксируем:

• Название запроса

• Описание

• Инициатор (заказчик)

• Приоритет (важность, срочность) реализации 

• Статус (открыт, первичный анализ, оценка, отклонён, в работе, завершён)

• Оценка. Плановые трудозатраты на внесение изменений или оценка стоимости изменений

Важно понимать отличие реестра запросов на изменение от плана проекта, бэклога (baclog) или дорожной карты продукта (road map). Реестр содержит список пожеланий на изменения, детализированных до уровня бизнес-целей. Достигнуть бизнес-цели можно разными способами: доработкой одного или нескольких продуктов, запуском нового проекта или изменением плана существующего проекта. А может, вообще не потребуется участие разработчиков.

Реестр запросов на изменение можно вести в документе Exсel, в Google Sheets, Miro и даже на физической доске с помощью стикеров. Выбор зависит от:

• количества запросов, 

• количества заинтересованных лиц,

• количества сотрудников на удалённой работе,

• списка инструментов, уже используемых в компании.

Для стартапа с командой до 10 человек, которые находятся в одном помещении, оптимальный способ — физическая доска. Можно не тратить время на настройку сложной системы работы с реестром, а лично обсуждать сами изменения. 

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

Работа с внешними инструментами вроде Google Sheets и Miro не всегда возможна из-за ограничений хранения данных на серверах третьих лиц. Но если в компании уже используют таск-трекер, его можно донастроить для работы с запросами на изменения.

Настройка работы Яндекс Трекера: запросы на изменение

Чтобы создать запросы на изменение в Yandex Tracker, нужны следующие шаги:

1. Создаем очередь — список задач, сгруппированных по определённому признаку. 

2. Открываем настройки очереди. 

3. Проверяем, что у очереди есть нужный тип задачи. По умолчанию в очереди стоит тип задачи «Change request». Можно использовать его или добавить новый тип задачи — «Запрос на изменение», например.

4. Настраиваем статусы и переходы между ними в рамках рабочего процесса.

Узнать о нюансах настройки очередей и рабочих процессов можно на бесплатном курсе Основы работы с Yandex Tracker.

После настройки очереди в Яндекс Трекере у нас появился инструмент, где можно создавать и изменять запросы, отслеживать историю правок, приоритизировать запросы и распределять их между аналитиками. История изменения задачи доступна всем участникам команды. Если аналитик, который проводил анализ запроса, уйдёт в отпуск или на больничный, нам не нужно переживать, что мы потеряем доступ к части требований. Можно переназначить задачу на другого аналитика.

Если у заказчика есть доступ к таск-трекеру, то можно создавать запросы на изменения самостоятельно. Так получается не всегда. У представителей бизнеса нет необходимости работать в едином пространстве с командой разработки. Даже если у них есть доступы, они не знакомы с интерфейсом таск-трекера, у них нет времени и желания его изучать. Тогда можно дать пользователям создавать запросы в Yandex Forms, на основе которых появятся задачи в таск-трекере.

2. Формируем список стейкхолдеров

Заинтересованные лица, стейкхолдеры (stakeholder), или лица, принимающие решения, — это люди, на которых влияют результаты проекта. Они инициируют проект, согласовывают детали, бюджет, принимают и оценивают результаты. Стейкхолдеры могут влиять на проект, например, вносить коррективы или отказаться его принимать. 

Стейкхолдеры бывают внутренние и внешние. 

• Внутренние — сотрудники компании, которые задействованы в проекте, в нашем примере это: заказчик, спонсор проекта, команды разработки и сопровождения.

• Внешние — все, кто может повлиять на проект за пределами компании. В нашем примере это: государственные органы, которые регулируют деятельность DTB, клиенты DTB, которые формируют мнение о продукте, СМИ и конкуренты, которые наблюдают за проектом. 

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

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

Хотя функционал таск-трекера позволяет создавать таблицы в описании задачи, таблицу со списком заинтересованных лиц лучше разместить в Wiki. С формирования списка стейкхолдеров начинается процесс анализа. Описывать и хранить все артефакты анализа в описании задачи таск-трекера будет неудобно. 

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

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

3. Формулируем верхнеуровневые пользовательские требования

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

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

Способ выявления требований зависит от продукта, который нужно создать.

• Если продукт новый и аналогов на рынке нет, то выявить требования можно опросами потенциальных пользователей, анализом непрямых конкурентов, мозговым штурмом. Идеи можно фиксировать в виде майндмепа или карты пользовательских историй (user story map).

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

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

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

Учитывая особенности задачи, можно составить следующий план выявления требований:

1. Анализ документации на смежные сервисы, которые участвуют в процессе работы со счетами клиентов банка.

2. Мозговой штурм со стейкхолдерами поможет выявить пользовательские требования, характерные для работы с «Общим счетом».

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

Выделяем классы эквивалентности на основании имеющихся данных, получаем следующие классы:

1. Точка входа: мобильное приложение iOS (для физ. лиц и для юр. лиц), мобильное приложение Android (для физ. лиц и для юр. лиц), web-приложение (для физ. лиц и для юр. лиц).

2. Владелец счёта: физическое лицо, юридическое лицо, резидент, нерезидент.

3. Тип счёта: текущий, расчётный, кредитный, вклад, овердрафт, номинальный.

4. Валюта счёта: национальная валюта, иностранная валюта.

5. Пользователи счёта: физическое лицо, юридическое лицо, резидент, нерезидент.

6. Операция со счётом: открытие, закрытие, пополнение (наличные, безналичные), списание (наличные, безналичные), установка лимитов, просмотр выписки, подключение уведомлений об операциях, отключение уведомлений об операциях, закрытие счёта, добавление пользователя счёта, удаление пользователя, настройка ограничений для пользователей.

Уже на этой стадии понятно: анализ всех возможных комбинаций займёт много времени, а реализация — ещё больше. Вспоминаем, что заказчик хотел проверить востребованность функционала на ограниченной группе клиентов. Теперь у нас есть тема для обсуждения. Идём к заказчику со списком выявленных классов и спрашиваем, что ему нужно в первой версии. 

Получаем следующий список: 

1. Точка входа: мобильное приложение iOS (для физ. лиц и для юр. лиц), мобильное приложение Аndroid (для физ. лиц и для юр. лиц), web-приложение (для физ. лиц и для юр. лиц).

2. Владелец счёта: физическое лицо, юридическое лицо, резидент, не резидент.

3. Тип счёта: текущий, расчетный, кредитный, вклад, овердрафт, номинальный.

4. Валюта счёта: национальная валюта, иностранная валюта.

5. Пользователи счёта: физическое лицо, юридическое лицо, резидент, не резидент.

6. Операция со счётом: открытие, закрытие, пополнение (наличные, безналичные), списание (наличные, безналичные), установка лимитов, просмотр выписки, подключение уведомлений об операциях, отключение уведомлений об операциях, закрытие счёта, добавление пользователя, удаление пользователя.

Акцентируем внимание заказчика: разработкой мобильных и веб-приложений занимаются разные команды, для каждого приложения нужно отдельно прорабатывать дизайн и согласовывать выделение ресурсов. Заказчик решает, что для первой версии ему будет достаточно только веб-приложения — «Личный кабинет ФЛ». 

Фиксируем договорённости в разделе «Резюме встреч». Можно фиксировать результаты сразу после встречи письмом на почту, но доступ к нему будет не у всех. Поэтому лучше фиксировать договоренности в Wiki, а в письме направлять ссылку на страницу.

У нас появились первые границы проекта, и теперь можно приступить к детальному изучению сценариев работы с текущим счётом физического лица. Самый быстрый способ — провести интервью с аналитиком, ответственным за сервис «Текущий счёт ФЛ». 

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

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

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

Когда есть общее представление о вариантах использования общего счёта, мы можем провести мозговой штурм. Аналитик выступает в роли организатора и фасилитатора этой встречи. 

Проведённый ранее анализ позволит аналитику:

1. Составить список участников мозгового штурма на основании списка стейкхолдеров.

2. Следить за тем, чтобы участники встречи не сильно отклонялись от повестки на основании списка вариантов использования.

3. Оперативно проверять, что предлагаемые пользовательские требования не противоречат бизнес-правилам и уже реализованным пользовательским и функциональным требованиям.

4. Составить шаблон для документирования выявленных в процессе мозгового штурма требований. 

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

Подготовка каркаса карты пользовательских историй до начала обсуждения сэкономит время и поможет наметить план обсуждения. Мы сможем проговорить и согласовать со стейкхолдерами ранее выявленные требования и внести в них корректировки, если требования были выявлены неверно.

Результаты мозгового штурма также нужно зафиксировать в Wiki  

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

3. Формулируем варианты реализации

Теперь нужно разобраться, какие части системы нужно доработать, — необходимо описать функциональные и системные требования. Мы помним, что время на анализ на стадии инициации ограничено, нет необходимости детально расписывать все требования. 

Вариант реализации — это краткое описание необходимых доработок с детализацией до названия подсистемы и краткой формулировки необходимых доработок.

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

В нашем случае можно описать следующий вариант реализации:

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

Мы не будем детально углубляться в методы оценки стоимости доработки — это зона ответственности менеджера. Хотя аналитик часто выполняет и эту часть работы, потому что он детально погрузился нюансы проекта.

Представим, что у нас есть оценка стоимости реализации проекта в человеко-часах.

Подводим итоги

После первичного анализа запроса на изменения у нас есть следующие данные:

• Название запроса

• Описание (цели, бизнес-задача/проблема)

• Инициатор (заказчик) и список стейкхолдеров

• Приоритет (важность, срочность) реализации

• Статус (открыт, первичный анализ, оценка, отклонён, в работе, завершён)

• Краткий вариант реализации

• Оценка. Плановые трудозатраты на внесение изменений или оценка стоимости изменений

• Общее представление о необходимых ресурсах

Исходя из этих данных, менеджеры могут принять решение о целесообразности реализации проекта:

• Если потенциальная выгода от решения бизнес-задачи/проблемы превышает затраты на его реализацию, то проект имеет смысл.

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

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

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

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

На стадии инициации артефакты от аналитика — это скорее инструменты для выявления и анализа требований, чем их документирования. А если проект перейдёт на стадию планирования, составленные аналитиком артефакты станут отправной точкой для детального анализа требований и помогут составить план проекта.