Секретные техники проработки требований. Часть 1

Привет, меня зовут Артур Селецкий. Я Co-Founder/Partner в It Network. Мы с коллегами занимаемся развитием комьюнити бизнес-аналитиков и руководителей проектов в Украине.

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

Меня часто спрашивают: «Как понять, все ли требования учтены? Как проверить, ничего ли мы не упустили?» В этой статье поделюсь своим опытом о том, как я проверяю требования на полноту и какой путь по проработке требований прохожу.

Техники

Привожу перечень техник, которые помогают мне проверить требования на полноту:

1. Stakeholder analysis.
2. User story mapping.
3. Ролевая модель и сценарии использования.
4. Прототипирование.
5. Объектно ориентированная модель.
6. Диаграмма состояний.
7. CRUD.
8. Навигация.
9. Администрирование.
10. Отчетность.
11. Нефункциональные требования.

Теперь рассмотрим каждую из техник детально и с примерами.

Stakeholder analysis

Стейкхолдеры (stakeholder) — физические лица или организации, которые оказывают влияние на проект.

Стейкхолдерами выступают:

• Команда проекта, спонсор проекта, привлеченные сторонние организации и компании, которые непосредственно вовлечены в проект.
• Руководители подразделений, сотрудники и наши клиенты — те, кто будет пользоваться результатами проекта.
• Акционеры, топ-менеджеры, владельцы бизнеса и регулирующие государственные органы — те, кто в проект не вовлечен, но может на него влиять.

Вспоминаю забавную историю, которая произошла со мной на старте карьеры. В то время я работал в банке на должности инженера ИТ-поддержки. Основной моей задачей было сопровождение АБС (автоматизированной банковской системы) Б2.

В один чудесный день от разработчиков Б2 мы получили очередной релиз. В релиз вошел функционал по автоматизации начисления абонентных плат и комиссий по клиентским счетам. Ознакомившись с перечнем и возможностями нового модуля, я был поражен: все, что наши менеджеры делают руками, можно настроить и автоматизировать. Распечатал и побежал к главному бухгалтеру с отличнейшей новостью: «Ура-а-а! Все можно сделать автоматически!»

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

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

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

На утро следующего дня я пришел на работу к 10 часам. Подхожу к своему руководителю ИТ-отдела и докладываю: «Все сделано, вот смотри». Открываем АБС, а там... ничего нет. Все комиссии, которые рассчитала система, успешно удалены менеджерами. Подхожу к менеджерам и спрашиваю: «А почему удалили, что-то неправильно начислила система?»

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

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

Зачем же выполнять анализ стейкхолдеров? Анализ стейкхолдеров проводится в первую очередь для того, чтобы убедиться, что все интересы были учтены. Чтобы определить, кто может помочь, а кто может помешать работать над проектом.

Классифицируют стейкхолдеров по влиянию на проект и их заинтересованности.

Влияние — это степень воздействия стейкхолдера на проект (бюджет и влияние на людей).

Заинтересованность — это степень поддержки проекта или противодействия ему.

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

Матрица влияния и заинтересованности стейкхолдеров

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

Квадрант 2 (поддержка, слабое влияние) — стейкхолдеры, которые также есть союзниками проекта, но не имеют на него большого влияния.

Квадрант 3 (противодействие, слабое влияние). В этом квадранте находятся слабые противники проекта. Они противодействуют нашему проекту и при этом не имеют большого влияния на сам проект.

Квадрант 4 (противодействие, сильное влияние). Это самые влиятельные противники проекта. Для подавления их противодействия и влияния следует привлекать обитателей первого квадранта, чтобы с их помощью оказывать влияние на оппонентов.

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

При выявлении стейкхолдеров я задаю следующие вопросы:

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

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

User story mapping

В XVI веке Козимо I заказал фрески для капеллы собора Сан-Лоренсо во Флоренции у Якопо де Понтормо. Понтормо более 11 лет расписывал потолок капеллы сценами из Библии: сотворение мира, Ноев ковчег, Адам и Ева, Христос... Художник работал, практически не покидая капеллу и никому не показывая результаты своего творения.

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

Технику user story mapping использую как технику визуального представления последовательности действий, которые должны быть реализованы. User story mapping — один из методов декомпозиции требований, который обеспечивает понимание продукта, начиная с полного охвата всех потребностей и завершая погружением до детальных историй пользователя.

На практике в рамках этапа анализа требований я использую следующий процесс построения user story mapping:

1. Определить ключевые шаги (каждый шаг описать на отдельной карточке).
2. Расположить их в порядке использования слева направо.
3. Определить отдельные задачи, которые составляют каждую активность.
4. Расположить задачи в одной строке в логическом, последовательном порядке.
5. С помощью стейкхолдеров проверить на полноту картины активности и задачи и обновить при необходимости.

User story mapping процесса согласования отпусков

Ролевая модель и сценарии использования

Недаром в шаблоне (я как роль) самого распространенного метода фиксации требований (user story) используется роль. С целью достижения максимальной ценности от проекта мы должны четко понимать, для кого и с какой целью мы будем реализовывать тот или иной функционал.

При построении ролевой модели использую три подхода:

1. Должностная — выделение ролей на базе должностных обязанностей.
2. Функциональная — выделение ролей на базе функциональных задач.
3. Гибридная — совмещение подходов должностной и функциональной ролевой модели.

В ходе построения должностной ролевой модели часто сталкиваюсь со следующими трудностями:

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

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

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

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

Таблица отображает пример гибридной ролевой модели и сценарии использования в разрезе ролей.

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

Прототипирование

Как показывает практика, большинство людей воспринимают все происходящее на глаз, что необходимо учитывать и при выявлении требований. Один из самых мощных методов выявления требований — это прототипирование. В чем я убедился в одном из проектов, куда меня подключили на роль лидера команды бизнес-аналитиков, когда проект заходил в тупик. Ситуация была следующая: уже 3-я команда не могла справиться с выявлением требований и согласованием их с одним из клиентов. Шел 5-й месяц проекта, а команда аналитиков не могла сдвинуться с места. Команда предоставила уже 4 варианта технического задания, а заказчик все не хотел подписывать. Команда говорила, что заказчик невменяем и согласовать требования нереально. Я пытался ознакомиться со всеми документами, которые готовила команда. В них было очень много тяжелого текста, с техническими терминами. В итоге я для себя определил несколько модулей системы и приблизительно понял функционал. Времени на подготовку было немного: один день и одна ночь.

И вот моя первая встреча с заказчиком, руководитель проекта представляет ему меня и цели встречи — согласование требований. На что получаем много недовольства со словами: «О ужас! Еще один аналитик».

Я начал со слов: «Правильно ли я понимаю...», а задавая вопрос, сразу взялся рисовать на листе А4. Через полтора часа у нас было изрисовано порядка 20 экранных форм. Я поблагодарил заказчика и побежал в офис разрабатывать кликабельные прототипы.

Ближе к полуночи работы по созданию прототипов были завершены. На следующее утро я позвонил заказчику и попросил назначить встречу по согласованию требований. На что сразу получил ответ: «Ничего и читать не буду». Я парировал, что сейчас ничего читать и не нужно. Она была удивлена и все же согласилась через час встретиться. Еще больше ее удивило, что мы начали не читать документы, а дальше работать с прототипами, только уже разработанными в специализированной программе. Сразу на месте мы начали добавлять и удалять элементы, и в течение часа требования были согласованы. А дальше дело техники: описать их в документе и дать на подпись. Через неделю документ с требованиями был подписан.

Как видно из приведенной истории, прототипирование пользовательского интерфейса помогло сформулировать требования, уменьшить время на согласование, а также снизить риск неверного трактования.

Рекомендую использовать следующие инструменты:

• Axure;
• Balsamiq;
• Visio;
• карандаш и бумага;
• любой другой инструмент.

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

Что еще важно помнить: прототип не дизайн! Не увлекайтесь, иначе вам придется разрабатывать и согласовывать дизайн раньше времени.

Жизненный цикл прототипа: от создания на доске до разработки дизайна

И самое главное, прототип не должен быть красивее, чем сама реализация. Да, и такое бывало...

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

Вместо итога

В первой части мы рассмотрели 4 техники: stakeholder analysis, user story mapping, ролевая модель и сценарии использования, а также прототипирование. Мне они помогают в ежедневной и далеко не самой простой проектной роли — бизнес-аналитика.

Часть 2

Часть 3

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU