Оценка разработки. Участники и основные артефакты

Ранее: Оценка разработки. Декомпозиция, Оценка разработки. Неопределенности и «вилка»

Описанное применимо для оценки сложных и долгих проектов по разработке цифровых продуктов.

Участники

1. Руководитель проектного офиса. Тот, кому «больше всех надо». Локальный проджект-раннер, который собирает всех и менеджерит процесс подготовки сметы

2. Проджект-менеджер. Генерирует ресурсный и календарный плана на основании артефактов от других участников

3. Архитектор. Супер-компетентный чувак, который способен понять бизнес-задачу и уже на старте задать правильные вопросы, рационально определить подходящие технологии, сформировать предварительную архитектуру будущего решения, подсветить основные риски, провести верхнеуровневую оценку трудоемкости скоупа

4. Аналитик. Делает бОльшую часть работы по подготовке сметы: детально изучает входящие материалы, старается сократить неопределенность в требованиях (или, как минимум, подсветить места, где она есть), готовит подробную функциональную декомпозицию, помогает осознать детали требований другим участникам процесса

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


Артефакты

1. Функциональная декомпозиция с оценкой. В одном из постов про оценку уже писал, что мы делаем функциональную декомпозицию, где каждый пункт подразумевает комплексную экспертизу (фронт, бэк, QA, UI/UX etc). Каждый пункт имеет оценку по всем компетенциям, текущий уровень неопределенности и, собственно, вилочную стоимости. Это — основа для всех остальных артефактов

2. Календарный план. На основе декомпозиции, оценок и предварительного разбиения разработки на релизы формируется примерный календарный план. Обычно планирование идет на уровне недель, иногда на уровне месяцев

3. Ресурсный план. Про это многие забывают и/или пренебрегают, но мы его делаем для любой оценки. Указываем, какие именно люди будут задействованы и моделируем график их аллокации в FTE прямо по месяцам. Очень важно, чтобы функциональная оценка не противоречила ресурсной оценке проекта (!)

4. Архитектурные решения. Базовые схемы того, как мы видим будущую архитектуру и как разрабатываемый продукт вписывается в текущий ландшафт

5. UI для ключевых интерфейсов. Да, мы часто рисуем ключевые интерфейсы еще до заключения контракта — это помогает и нам и клиенту убедиться, что мы друг друга слышим и смотрим в одном направлении

6. Презентация. Она же «КП». Приводятся основные данные по бюджету, основные риски, архитектурное решение, UI, календарный и ресурсный план, ссылки на все остальные артефакты

В следующий раз напишу про процесс оценки (хотел тут, но ТГ не дает из-за ограничений)