Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 21)
Метод получения информации – опрос потенциальных пользователей (если до них трудно добраться, то экспертов).
Каждому опрашиваемому предлагается оценить каждый из элементов матрицы ожиданий по двум осям:
положительной – насколько понравится наличие этого элемента в продукте;
отрицательной – насколько понравится отсутствие этого элемента.
Оценка выставляется по пяти уровням (1..5 = нравится, ожидаю, нейтрально, терпимо, не нравится).
Они делятся на пять групп:
1) линейные: + (нравится), − (не нравится);
2) обязательные: + (ожидаю, нейтрально, могу терпеть), − (не нравится);
3) восхищающие («вау»): + (нравится), − (ожидаю, нейтрально, могу терпеть);
4) нежелательные: + (не нравится) или – (нравится);
5) нейтральные – все остальные.
3.
4.
Элементы, оставшиеся в описании продукта, ранжированы уже по нескольким осям:
1) ЦДС (для функции и для каждого из персонажей);
2) SWOT (для функции, соответствующей элементу);
3) конкурентность;
4) ранг Кано.
Для каждого персонажа также определен ранг его важности. Требуется сформировать единую оценку важности элемента в составе продукта.
Интегральная оценка элемента рассчитывается по следующей формуле:
Ценность (элемент) = max (k1 × ЦДС × персонаж) × k2 × SWOT × k3 × конкурентность × k4 × Кано.
Коэффициенты k1..k4 определяются экспертной оценкой следующих метрик: k1, k2, k4 – точности определения соответствующих показателей, k3 – важности (объема и перспективности) отрасли, в которой измерялась конкурентность.
Результат. Интегральная ценность – наиболее объективная оценка сравнительной важности элементов опыта.
1. Обязательные атрибуты.
2. Одномерные атрибуты (уровень функциональности продукта).
3. Привлекательные атрибуты.
4. Атрибуты, не имеющие большого значения для пользователя.
5. Нежелательные (избыточные) атрибуты.
Рассчитав ценность элементов для внешнего мира, следует оценить их себестоимость – затраты ресурсов (времени, денег и т. д.) на реализацию в ходе создания продукта. Затраты будут возникать не в среднем по мировой экономике, а в конкретных условиях: с оборудованием, разработчиками и стейкхолдерами проекта. Лучше всего оценить такие затраты могут те люди, которые непосредственно участвуют в проекте – то есть сами разработчики.
Оцениваются трудозатраты на разработку. В качестве экспертов выступают все разработчики проекта. Каждый элемент оценивается отдельно, в единицах трудозатрат (как правило, человеко-часах). Каждый элемент обсуждается в течение фиксированного времени, затем каждый разработчик пишет свою оценку на бумажке и выкладывает ее на стол картинкой вниз. Когда все бумажки выложены, они раскрываются. Участники с самой высокой и самой низкой оценками обосновывают свой выбор в течение следующего раунда обсуждения. Процедура повторяется до достижения консенсуса – одинаковых оценок у всех участников.
Перевод трудозатрат в денежные единицы производится по формуле:
Результат. Оценка затрат на разработку элементов своими силами.
Реализовать некоторые элементы опыта можно, и не создавая самостоятельно соответствующую функциональность продукта, а закупив ее на стороне или отдав разработку на аутсорс. Поэтому следует оценить и затраты на такое приобретение функций «на рынке».
1. Оцениваются затраты на аутсорсинг разработки и приобретение готовых компонентов. Источники информации – «Погружение в тему», коммерческие предложения по запросу, опыт аналогичных проектов. В случае приобретения части элементов на стороне к их оценке прибавляются трудозатраты на интеграцию элемента (оцениваемые по методу покер-планирования), оценка всех элементов переводится в денежную форму.
2. Помимо оценок в трудозатратах и деньгах (необходимых для сопоставления с бюджетом проекта), элементы методом «Взвешенного ранжирования» ранжируются по рынку и в диапазоне (0..1).
Результат. Оценка затрат на приобретение элементов на рынке; «рыночный ранг» стоимости элементов.
На этапе разработки основной риск любого проекта – не уложиться в бюджет/сроки, пытаясь реализовать слишком большую функциональность, и в результате не выпустить вообще никакого продукта. Поэтому в бэклог следует отбирать элементы, обеспечивающие максимальную потребительскую ценность при заданной планке затрат. Поскольку элементы ценны не сами по себе, а только в составе реально функционирующего продукта, отобранные в бэклог элементы должны собираться в продукт, который можно использовать.
Эта задача решается с помощью выделения MVP – минимально жизнеспособного продукта. Критерием жизнеспособности продукта является заполненность его элементами CJM хотя бы одного персонажа. Для отбрасывания лишних элементов и формирования действительно минимального продукта используется следующий метод.
1. Матрица ожиданий снова разбивается на CJM отдельных персонажей. При этом этапы, относившиеся в матрице к другим персонажам, и соответствующие им элементы отбрасываются.
2. CJM каждого персонажа, полученная из матрицы ожиданий, оценивается по минимальным затратам на реализацию. Для этого: 1) из каждой CJM отбрасываются все необязательные элементы; 2) оставляется хотя бы один «вау-элемент»; 3) суммируются затраты оставшихся элементов. Выбирается CJM с минимальными затратами.
3. Если суммарные затраты на CJM меньше, чем бюджет проекта, – не экономим! В CJM добавляются отброшенные ранее элементы и элементы из других CJM матрицы с максимальным соотношением «ценность/затраты» (начиная с «вау»), пока бюджет проекта не будет достигнут.
4. На основе карточек стейкхолдеров и выявленных ранее (см. п. 1.3) ограничений каждый элемент проверяется на соответствие ожиданиям стейкхолдеров. Выявленные потенциальные конфликты добавляются к описанию элемента в виде ограничений с их стороны. Поскольку ограничения могут исходить только от отдельных стейкхолдеров, они не являются основанием для отбрасывания элемента, а лишь уточняют требования к его реализации.
Результат. Получившийся ранжированный список элементов, соответствующий по крайней мере одной полной CJM, и есть бэклог. Он представляет собой жизнеспособный продукт (поскольку полностью соответствует CJM) и является оптимальным с точки зрения ценности/ затрат.
Бэклог можно (и нужно) оформить не только в виде списка элементов, но и в виде визуального макета продукта (
3. Разработка
Методы двух предыдущих разделов обеспечили подбор ресурсов и создание описания продукта (бэклога). Теперь предстоит решить следующую задачу: организовать использование ресурсов таким образом, чтобы в результате появился реальный продукт.
Под продуктом здесь понимается материальная и отчуждаемая вещь, которую (в отличие от бэклога) может использовать любой человек. В состав продукта могут входить: образец (например, работающий, но еще не масштабированный сайт), документация, описание применения (в том числе инструкция по эксплуатации), методы расширения системы (API, модульность, неймспейсы). В случае тиражного продукта сюда добавляется и технология производства (оборудование, технологические карты, логистика). Все это предстоит не просто придумать, а еще и воплотить в материале.
Хотя разработка может быть представлена в виде некой последовательности действий, сами эти действия уже полностью зависят от конкретного содержания проекта. Общепринятая некогда «водопадная» схема разработки (сбор требований, эскизный проект, рабочий проект, образец, испытания, производство, поддержка) ныне признана неэффективной – и прежде всего потому, что не предусматривает исправления ошибок, допущенных на ранних этапах. Поэтому современные проекты так или иначе строятся по гибким методологиям, предусматривающим коррекцию решений каждого уровня в любой момент. А это означает, что управлять в ходе разработки приходится всеми видами деятельности одновременно.
Поэтому третий раздел DaShe использует классификацию методов не по последовательности этапов, а по компонентам проектной деятельности, то есть по тем сущностям, на которые ПМ должен обращать внимание, чтобы не допустить возникновения критических проблем. В DaShe мы выделяем восемь компонентов: