×

Секретные техники проработки требований. Часть 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 (противодействие, сильное влияние). Это самые влиятельные противники проекта. Для подавления их противодействия и влияния следует привлекать обитателей первого квадранта, чтобы с их помощью оказывать влияние на оппонентов.

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

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

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

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

Ф. И. О.E-mailТелефонПо каким вопросамСтепень влияния
Селецкий Артур Николаевич[email protected]+380 ХХХ-ХХ-ХХВыполнение настроек системыКвадрант 1

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

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному22
LinkedIn

Схожі статті




20 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

В якості інструменту для прототипування — ще рекомендую FIGMA.

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

раскажите как в прототипе отразить бизнес процессы

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

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

Я не собираюсь писать комменты о тех вещах, в которых мало понимаю. Вы пишите, а если можете — не пишите. Дискутировать с вами у меня тоже охоты нет. Просто не о чем.

спасибо за статью! очень подробно) от себя хочу добавить, что user story mapping и выявленые сценарии должны отображаться в том самом интерактивном прототипе. И общайтесь с клиентами(пользователями) для выявления перечня функционала: какие они альтернативы используют сейчас, какие хаки и чего не хватает. Жду продолжения)

що саме секретного у цих техніках?

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

никакого секрета здесь нет. ©

те що це все треба робити повинно бути must have для дорослих сеньйорів аналітиків.

Взагалі нічого. Було б секретне, його б тут не викладали. Просто заголовок такий, шоб ви читали :) А якщо чесно — в якомусь абзаці зашифровано секретну витяжку з каналу Діскавері. Хтось перднув у канал в прямому ефірі.... вибачте, в ефір у прямому каналі. Кароч, всі ледь не померли. Читайте, дуже круто.

Блок User story mapping —
2. Расположить их в порядке использования справа налево.
Точно «справа налево» ?

Спасибо за статью.

Із статті не зовсім зрозуміло звідки беруться user stories для user story mapping

да статья вряд ли все отражает. вместо story mapping мне больше нарвится BPMN диаграмы

Хорошая статья, спасибо!

Підписатись на коментарі