Секретные техники проработки требований. Часть 1
Привет, меня зовут Артур Селецкий. Я Co-Founder/Partner в It Network. Мы с коллегами занимаемся развитием комьюнити бизнес-аналитиков и руководителей проектов в Украине.
По мнению ведущих разработчиков, с которыми мне посчастливилось сотрудничать, основная проблема в проектах по разработке программного обеспечения — требования неполные или выявлены не полностью.
Меня часто спрашивают: «Как понять, все ли требования учтены? Как проверить, ничего ли мы не упустили?» В этой статье поделюсь своим опытом о том, как я проверяю требования на полноту и какой путь по проработке требований прохожу.
Техники
Привожу перечень техник, которые помогают мне проверить требования на полноту:
- Stakeholder analysis.
- User story mapping.
- Ролевая модель и сценарии использования.
- Прототипирование.
- Объектно ориентированная модель.
- Диаграмма состояний.
- CRUD.
- Навигация.
- Администрирование.
- Отчетность.
- Нефункциональные требования.
Теперь рассмотрим каждую из техник детально и с примерами.
Stakeholder analysis
Стейкхолдеры (stakeholder) — физические лица или организации, которые оказывают влияние на проект.
Стейкхолдерами выступают:
- Команда проекта, спонсор проекта, привлеченные сторонние организации и компании, которые непосредственно вовлечены в проект.
- Руководители подразделений, сотрудники и наши клиенты — те, кто будет пользоваться результатами проекта.
- Акционеры, топ-менеджеры, владельцы бизнеса и регулирующие государственные органы — те, кто в проект не вовлечен, но может на него влиять.
Вспоминаю забавную историю, которая произошла со мной на старте карьеры. В то время я работал в банке на должности инженера ИТ-поддержки. Основной моей задачей было сопровождение АБС (автоматизированной банковской системы) Б2.
В один чудесный день от разработчиков Б2 мы получили очередной релиз. В релиз вошел функционал по автоматизации начисления абонентных плат и комиссий по клиентским счетам. Ознакомившись с перечнем и возможностями нового модуля, я был поражен: все, что наши менеджеры делают руками, можно настроить и автоматизировать. Распечатал и побежал к главному бухгалтеру с отличнейшей новостью: «Ура-а-а! Все можно сделать автоматически!»
После рассмотрения всех рекомендаций компании-разработчика было принято решение автоматизировать расчет начисления комиссий. Закатав рукава, я начал процессы настройки и проверки, конечно же, в тестовой среде, как же без этого?
Через два дня мы с главным бухгалтером проверяли все возможные варианты. И о чудо! Все работало как часы.
Вот он, момент истины: перенос настроенного функционала в промышленную среду. Настройки перенес. Код выполнен. Комиссия начислена. Ура, все верно! В 2 часа ночи я и главный бухгалтер наслаждались результатами своего труда.
На утро следующего дня я пришел на работу к 10 часам. Подхожу к своему руководителю ИТ-отдела и докладываю: «Все сделано, вот смотри». Открываем АБС, а там... ничего нет. Все комиссии, которые рассчитала система, успешно удалены менеджерами. Подхожу к менеджерам и спрашиваю: «А почему удалили, что-то неправильно начислила система?»
Ответ меня поразил: «Нет, все верно. Вот только что мы будем делать целый день, если система сделает все за нас?»
Для себя тогда я вынес урок: даже незначительное улучшение, не говоря о большом проекте, порождает изменение процессов компании, и не все этим изменениям будут рады. Кто-то будет стараться внедрить новое и улучшить процесс, а кто-то будет этому противодействовать.
Зачем же выполнять анализ стейкхолдеров? Анализ стейкхолдеров проводится в первую очередь для того, чтобы убедиться, что все интересы были учтены. Чтобы определить, кто может помочь, а кто может помешать работать над проектом.
Классифицируют стейкхолдеров по влиянию на проект и их заинтересованности.
Влияние — это степень воздействия стейкхолдера на проект (бюджет и влияние на людей).
Заинтересованность — это степень поддержки проекта или противодействия ему.
Для работы со стейкхолдерами я использую матрицу влияния и заинтересованности.
Матрица влияния и заинтересованности стейкхолдеров
Квадрант 1 (поддержка, сильное влияние). В этот квадрант должны входить спонсор проекта, проектная команда, заказчики и топ-менеджеры. Если кто-то из перечисленных стейкхолдеров не будет входить в данный квадрант, успех проекта будет находиться под большим вопросом. Нельзя допустить перехода стейкхолдеров из этого квадранта в другие квадранты. Это самые важные и влиятельные союзники проекта.
Квадрант 2 (поддержка, слабое влияние) — стейкхолдеры, которые также есть союзниками проекта, но не имеют на него большого влияния.
Квадрант 3 (противодействие, слабое влияние). В этом квадранте находятся слабые противники проекта. Они противодействуют нашему проекту и при этом не имеют большого влияния на сам проект.
Квадрант 4 (противодействие, сильное влияние). Это самые влиятельные противники проекта. Для подавления их противодействия и влияния следует привлекать обитателей первого квадранта, чтобы с их помощью оказывать влияние на оппонентов.
Вернемся к моей истории и распределим задействованных лиц по квадрантам. В первый квадрант попали я и главный бухгалтер, а менеджеры изначально попали в третий квадрант. У менеджеров было явно выраженное противодействие и в то же время у них не было достаточно влияния, чтобы как-то воздействовать на результат. Изменения были внедрены в банке, а менеджеров перевели на другие, более важные участки работы.
При выявлении стейкхолдеров я задаю следующие вопросы:
- Кто может помочь или помешать достижению целей проекта?
- Кто больше всего заинтересован в результатах проекта?
- Кто принимает решения на проекте?
- Кто выступает экспертом в этом проекте?
- Кто будет работать с результатами проекта после его реализации?
Для выявления стейкхолдеров мы с коллегами часто используем технику мозгового штурма. Результаты мозгового штурма заносим в таблицу:
| Ф. И. О. | Телефон | По каким вопросам | Степень влияния | |
| Селецкий Артур Николаевич | Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. | +380 ХХХ-ХХ-ХХ | Выполнение настроек системы | Квадрант 1 |
User story mapping
В XVI веке Козимо I заказал фрески для капеллы собора Сан-Лоренсо во Флоренции у Якопо де Понтормо. Понтормо более 11 лет расписывал потолок капеллы сценами из Библии: сотворение мира, Ноев ковчег, Адам и Ева, Христос... Художник работал, практически не покидая капеллу и никому не показывая результаты своего творения.
Понтормо умер, так и не успев закончить свою работу. Фрески не были представлены на обозрение. Литератор и друг художника Визари оставил нам описание. По его словам, сцены громоздились одна на одной, множество фигур и сцен накладывались одна на другую. Понтормо увлекся отделкой деталей и потерял ощущение общей композиции.
Технику user story mapping использую как технику визуального представления последовательности действий, которые должны быть реализованы. User story mapping — один из методов декомпозиции требований, который обеспечивает понимание продукта, начиная с полного охвата всех потребностей и завершая погружением до детальных историй пользователя.
На практике в рамках этапа анализа требований я использую следующий процесс построения user story mapping:
- Определить ключевые шаги (каждый шаг описать на отдельной карточке).
- Расположить их в порядке использования слева направо.
- Определить отдельные задачи, которые составляют каждую активность.
- Расположить задачи в одной строке в логическом, последовательном порядке.
- С помощью стейкхолдеров проверить на полноту картины активности и задачи и обновить при необходимости.
User story mapping процесса согласования отпусков
Ролевая модель и сценарии использования
Недаром в шаблоне (я как роль) самого распространенного метода фиксации требований (user story) используется роль. С целью достижения максимальной ценности от проекта мы должны четко понимать, для кого и с какой целью мы будем реализовывать тот или иной функционал.
При построении ролевой модели использую три подхода:
- Должностная — выделение ролей на базе должностных обязанностей.
- Функциональная — выделение ролей на базе функциональных задач.
- Гибридная — совмещение подходов должностной и функциональной ролевой модели.
В ходе построения должностной ролевой модели часто сталкиваюсь со следующими трудностями:
- В больших компаниях есть несколько типов бухгалтеров или менеджеров. Более того, несколько из них могут быть в одном подразделении, а задачи выполняют разные.
- Должностные обязанности часто меняются, и, соответственно, ролевую модель нужно переделывать.
При таких нюансах этот подход хорошо подойдет компаниям, где жестко соблюдаются регламенты и правила и ведется строгий контроль предоставленного доступа.
При построении функциональной ролевой модели выделяю основные и наиболее часто встречающиеся группы ролей, затем объединяю их в отдельные группы или бизнес-роли. Примеры таких групп: редактор (управление новостным модулем), модератор (модерация ответов форума), аудитор (построение отчетности и просмотр данных системы) и т. д.
При гибридной модели использую подход для базовых должностей (бухгалтер, кассир и инженер) и добавляю права из функциональной модели (пользователь и модератор).
После того как роли определены, для каждой из них перечисляю сценарии использования.
Таблица отображает пример гибридной ролевой модели и сценарии использования в разрезе ролей.
| Роль | Сценарий использования |
| Администратор | Создание проекта Редактирование карточки проекта Назначение руководителя проекта Построение отчетов в разрезе портфеля проектов |
| Руководитель проекта | Построение проектного плана Работа с задачами Построение отчетов |
| Пользователь | Просмотр проектного плана Выполнение задач Запрос об изменении срока выполнения задач |
В некоторых проектах используем следующий подход: определяем перечень операций, которые должна выполнять система, и только потом определяем роли. Все зависит от заказчика и его восприятия.
Прототипирование
Как показывает практика, большинство людей воспринимают все происходящее на глаз, что необходимо учитывать и при выявлении требований. Один из самых мощных методов выявления требований — это прототипирование. В чем я убедился в одном из проектов, куда меня подключили на роль лидера команды бизнес-аналитиков, когда проект заходил в тупик. Ситуация была следующая: уже
И вот моя первая встреча с заказчиком, руководитель проекта представляет ему меня и цели встречи — согласование требований. На что получаем много недовольства со словами: «О ужас! Еще один аналитик».
Я начал со слов: «Правильно ли я понимаю...», а задавая вопрос, сразу взялся рисовать на листе А4. Через полтора часа у нас было изрисовано порядка 20 экранных форм. Я поблагодарил заказчика и побежал в офис разрабатывать кликабельные прототипы.
Ближе к полуночи работы по созданию прототипов были завершены. На следующее утро я позвонил заказчику и попросил назначить встречу по согласованию требований. На что сразу получил ответ: «Ничего и читать не буду». Я парировал, что сейчас ничего читать и не нужно. Она была удивлена и все же согласилась через час встретиться. Еще больше ее удивило, что мы начали не читать документы, а дальше работать с прототипами, только уже разработанными в специализированной программе. Сразу на месте мы начали добавлять и удалять элементы, и в течение часа требования были согласованы. А дальше дело техники: описать их в документе и дать на подпись. Через неделю документ с требованиями был подписан.
Как видно из приведенной истории, прототипирование пользовательского интерфейса помогло сформулировать требования, уменьшить время на согласование, а также снизить риск неверного трактования.
Рекомендую использовать следующие инструменты:
В комментариях поделитесь, какие инструменты используете вы.
Что еще важно помнить: прототип не дизайн! Не увлекайтесь, иначе вам придется разрабатывать и согласовывать дизайн раньше времени.
Жизненный цикл прототипа: от создания на доске до разработки дизайна
И самое главное, прототип не должен быть красивее, чем сама реализация. Да, и такое бывало...
Ну, и выстраданное годами определение прототипа, которое я добавляю в раздел «Определения» во все документы с требованиями: «Прототип — это схематическое изображение форм и отдельных элементов страницы. Пропорции элементов дизайна, размеры шрифтов и заголовков, расстояния между элементами, дизайн элементов и их размещения являются условными».
Вместо итога
В первой части мы рассмотрели 4 техники: stakeholder analysis, user story mapping, ролевая модель и сценарии использования, а также прототипирование. Мне они помогают в ежедневной и далеко не самой простой проектной роли — бизнес-аналитика.
Ожидайте вскоре следующие части по этой теме на страницах DOU.
