Декомпозиция проекта, распределение ролей и создание юзкейсов
6 Августа 2019
следующая статья
Насколько хорошо Вы понимаете тот проект, над которым работаете? Скорее всего Вы ответите, что знаете его от А до Я. И это отлично! Но на сколько хорошо при этом в проекте ориентируется Ваша команда и сам клиент? Немного подумав каждый ответит, что у всех есть достаточное понимание происходящего. Но почему же тогда возникают ситуации, когда программисты сделали что-то не то; появляются трудности во взаимодействии с клиентом; у клиента не оправдываются ожидания и вообще оценка не совпала с действительностью! А еще и в конце оказывается, что какой-то архиважный вопрос вылетел из головы и начинается суматоха…
Так что же делать, чтобы понимание логики проекта было идеальным, а оценки были максимально точными и прозрачными?
Декомпозиция проектов
Первое и главное правило — декомпозиция. На первый взгляд это покажется сложным и непонятным словом. Давайте попробуем разобраться, что же это такое.
Для этого перенесемся на мгновение в школьные годы, когда было много веселья, забав и всеми любимой… геометрии! Представьте, что Вам дали задание измерить площадь фигуры: ничего сложного, не так ли? Но фигура эта не простой прямоугольник или квадрат; она — амебоподобной формы, площадь которой просто нереально измерить доступными геометрии методами. Так бывает и с проектами — легкая на первый взгляд задача может оказаться по факту похожей фигурой понятных форм. Но Вы же еще ученик в школе (не забыли еще об этом?), которому 2-ка никак не нужна. И как же облегчить себе участь, есть предположения?
Сейчас открою Вам эту тайну. Вам нужно всего лишь разбить фигуру на N мелких фигур понятной формы (квадраты, круги, прямоугольники), далее посчитать площадь каждой из фигур простыми и доступными математическими формулами и прибавить их. После разбития сложной фигуры остаются мелкие “обрезки” (как, например, во время кроя большого полотна), и в проекте такие детали тоже существуют. Как менеджеры, мы покрываем их так называемыми рисками и наша оценка становится, опять же, весьма точной. Все, готово, у вас оценка 5(12 для Украины)!
Разработка проектов довольно сложный и непредсказуемый процесс. Вполне возможно, что в ходе реализации какие-то задачи заберут намного больше времени, чем планировалось изначально. Простыми словами декомпозиция, как вы уже поняли — это разбиение всей работы на маленькие части.
Существуют следующие виды разбиения проектов. По функциональности:
-
горизонтальный (задачи разбиваются по типу работы);
-
вертикальный (выделение задач происходит так, чтобы каждый такой блок функций мог быть выпущен отдельно от остальных).
По способу отображения:
-
визуальный ( задачи разбиваются по экранам или страницам дизайн интерфейса) — она визуально более понятна клиенту
-
функциональный (обычно используется на беке и кроме визуального вида также включает в себя блоки и задачи, которые не имеют отношения к фронту, но важны — архитектура проекта, работа с БД, интеграции со сторонними сервисами и тд)
Чаще всего используется вертикальный вид, поскольку он имеет следующие преимущества:
-
во-первых, каждый такой блок задач может быть реализован и сразу же продемонстрирован заказчику. У этот блок будет для него абсолютно понятным. Сразу же отпадает проблема с не понимаем заказчика что происходит и происходит ли вообще;
-
во-вторых, каждый такой блок несет в себе ценность для бизнеса, такие задачи намного проще будет приоритезировать;
-
в-третьих, при таком виде работ могут участвовать разные специалисты. Поскольку вовлечены разные роли - можно на начальных этапах выявить сложности, которые, при использовании горизонтального вида, могли бы возникнуть на этапе уже реализации проекта.
Давайте посмотрим, что же являет собой декомпозиция на практике. Представьте, что к вам пришел клиент, у которого уже есть интернет-магазин и он хочет в нем сделать в нем функционал покупки товара. То-есть у вас в бэклоге есть огромная задача “Реализовать покупку товара”. Декомпозиция этой задачи будет, к примеру:
-
добавление товара в корзину
-
просмотр товаров в корзине
-
удаление товара из корзины
-
оформление покупки (ввод личных данных, выбор способа доставки и способа оплаты)
В итоге мы разбили большую задачу на несколько маленьких, что упрощает восприятие. Такая разбивка помогает определить приоритеты, а также понять какие задачи есть критичными, какие опциональными, а какие и вовсе не нужны.
Каждый такой этап нужно описывать в виде пользовательских историй по каждой из ролей.
Распределение ролей в проекте
Прежде чем после декомпозиции приступать к написанию пользовательских историй, важно изначально выделить роли (User roles), поскольку именно для каждой из них будем писать сценарии. Для каждого проекта они индивидуальные, сказать что есть какой-то стандартный перечень — нельзя. Проанализируйте, кто именно пользуется системой, какие у них права, делают ли они одинаковые действия и получают на эти действия одинаковые результаты. Для нашего примера с интернет-магазином, можно выделить роль “пользователь системы” и “администратор”, может быть “оператор” и еще несколько ролей (зависит от специфики проекта).
После того, как выделили всех User roles, можно приступать к написанию пользовательских сценариев.
Что такое User Story?
User Story — это краткая формулировка, описывающая действия, которые должна делать система для конкретной роли (взаимодействие пользователя и системы). Есть 2 варианта описания: текстовый и диаграмма. Какой из них выбрать — решение исключительно вашей команды. Как по мне, написание текстовых сценариев удобнее поскольку:
-
User Story в таком формате будет всегда понятно заказчику и команде. Так, как заказчики любят менять какие-то нюансы проекта, то в написании именно текстовых историй есть огромный плюс - клиент может все еще раз перечитать и на начальном этапе проекта поправить то, что он хочет видеть иначе;
-
текст всегда можно легче отредактировать, чем диаграммы.
Однако многие коллеги склоняются в пользу текста и визуального материала вместе.
Что же должно быть в User Story? Изначально должна идти Роль (кто?), за ней Цель (какое намерение?), далее Действие (что нужно сделать?) и Результат (что пользователь получил от системы?).
К примеру с покупкой товара в интернет-магазине, один из сценариев может быть:
Роль | Цель | Действие | Результат |
Пользователь | Оформление покупки | Я, как пользователь, указываю свои личные данные, выбираю способ доставки и оплаты и нажимаю кнопку “Оформить заказ” | Пользователь переводится на страницу “Спасибо за заказ” |
Выше представлен обобщенный вариант, который можно дополнить столбцом с комментарием, где указать какие именно поля будет заполнять пользователь. Всегда надо смотреть на то, будет ли что-то меняться, если пользователь выберет доставку курьером, к примеру, или если он выберет тот или иной способ оплаты. Если да, то нужно расписывать отдельные сценарии: “Выбор доставки курьером”, “Выбор доставки на отделение”, “Выбор способа оплаты наложенным платежом / картой” и т.д.
Разбивать User Story нужно по: видам операций (создание, просмотр, редактирование, удаление); ролям и правам доступа; отдельным блокам системы; негативным и позитивным сценариям.
Вознаграждение за мастерство
Когда проект декомпозирован, все роли выделены и описаны пользовательские сценарии — можете быть уверены, что у всех есть четкое понимание логики проекта. И не сомневайтесь: это не зря потраченное время, которое можно было пустить на разработку. Это залог успеха проекта, минимизация рисков, а также хорошие взаимоотношения команды и клиента!
И, конечно же — это противодействие появлению у Вас, как проджект-менеджера, “головной боли”!
Похожие статьи
Записаться на консультацию
Мы свяжемся с вами в течении 10 минут