Декомпозиция проекта, распределение ролей и создание юзкейсов

Насколько хорошо Вы понимаете тот проект, над которым работаете? Скорее всего Вы ответите, что знаете его от А до Я. И это отлично! Но на сколько хорошо при этом в проекте ориентируется Ваша команда и сам клиент? Немного подумав каждый ответит, что у всех есть достаточное понимание происходящего. Но почему же тогда возникают ситуации, когда программисты сделали что-то не то; появляются трудности во взаимодействии с клиентом; у клиента не оправдываются ожидания и вообще оценка не совпала с действительностью! А еще и в конце оказывается, что какой-то архиважный вопрос вылетел из головы и начинается суматоха… 

Так что же делать, чтобы понимание логики проекта было идеальным, а оценки были максимально точными и прозрачными?

Декомпозиция проектов

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

Для этого перенесемся на мгновение в школьные годы, когда было много веселья, забав и всеми любимой… геометрии! Представьте, что Вам дали задание измерить площадь фигуры: ничего сложного, не так ли? Но фигура эта не простой прямоугольник или квадрат; она — амебоподобной формы, площадь которой просто нереально измерить доступными геометрии методами. Так бывает и с проектами — легкая на первый взгляд задача может оказаться по факту похожей фигурой понятных форм. Но Вы же еще ученик в школе (не забыли еще об этом?), которому 2-ка никак не нужна. И как же облегчить себе участь, есть предположения? 

Сейчас открою Вам эту тайну. Вам нужно всего лишь разбить фигуру на N мелких фигур понятной формы (квадраты, круги, прямоугольники), далее посчитать площадь каждой из фигур простыми и доступными математическими формулами и прибавить их. После разбития сложной фигуры остаются мелкие “обрезки” (как, например, во время кроя большого полотна), и в проекте такие детали тоже существуют. Как менеджеры, мы покрываем их так называемыми рисками и наша оценка становится, опять же, весьма точной. Все, готово, у вас оценка 5(12 для Украины)!

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

Существуют следующие виды разбиения проектов. По функциональности: 

• горизонтальный (задачи разбиваются по типу работы);

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

По способу отображения:

• визуальный ( задачи разбиваются по экранам или страницам дизайн интерфейса) — она визуально более понятна клиенту 

• функциональный (обычно используется на беке и кроме визуального вида также включает в себя блоки и задачи, которые не имеют отношения к фронту, но важны — архитектура проекта, работа с БД, интеграции со сторонними сервисами и тд)

Чаще всего используется вертикальный вид, поскольку он имеет следующие преимущества:

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

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

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

Давайте посмотрим, что же являет собой декомпозиция на практике. Представьте, что к вам пришел клиент, у которого уже есть интернет-магазин и он хочет в нем сделать в нем функционал покупки товара. То-есть у вас в бэклоге есть огромная задача “Реализовать покупку товара”. Декомпозиция этой задачи будет, к примеру:

• добавление товара в корзину

• просмотр товаров в корзине

• удаление товара из корзины

• оформление покупки (ввод личных данных, выбор способа доставки и способа оплаты)

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

Каждый такой этап нужно описывать в виде пользовательских историй по каждой из ролей. 

Распределение ролей в проекте 

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

После того, как выделили всех User roles, можно приступать к написанию пользовательских сценариев. 

Что такое User Story? 

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

• User Story в таком формате будет всегда понятно заказчику и команде. Так, как заказчики любят менять какие-то нюансы проекта, то в написании именно текстовых историй есть огромный плюс - клиент может все еще раз перечитать и на начальном этапе проекта поправить то, что он хочет видеть иначе;

• текст всегда можно легче отредактировать, чем диаграммы.

Однако многие коллеги склоняются в пользу текста и визуального материала вместе. 

Что же должно быть в User Story? Изначально должна идти Роль (кто?), за ней Цель (какое намерение?), далее  Действие (что нужно сделать?) и Результат (что пользователь получил от системы?). 

К примеру с покупкой товара в интернет-магазине, один из сценариев может быть:

Выше представлен обобщенный вариант, который можно дополнить столбцом с комментарием, где указать какие именно поля будет заполнять пользователь. Всегда надо смотреть на то, будет ли что-то меняться, если пользователь выберет доставку курьером, к примеру, или если он выберет тот или иной способ оплаты. Если да, то нужно расписывать отдельные сценарии: “Выбор доставки курьером”, “Выбор доставки на отделение”, “Выбор способа оплаты наложенным платежом / картой” и т.д. 

Разбивать User Story нужно по: видам операций (создание, просмотр, редактирование, удаление); ролям и правам доступа; отдельным блокам системы; негативным и позитивным сценариям. 

Вознаграждение за мастерство

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

И, конечно же — это противодействие появлению у Вас, как проджект-менеджера, “головной боли”!