Кому нужно ППО и в чем его ценность

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

С их помощью мы должны ответить на ряд вопросов: каковы будут скоуп, структура и функционал продукта? В чем состоят ожидания заказчика? Каковы сроки и стоимость выполнения работ? Какие функции войдут в MVP?

Инструментом, который дает нам ответы на все вопросы, является предпроектное обследование. Для краткости будем дальше использовать стандартное сокращение — ППО.

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

Первые — это представители заказчика: руководители бизнес-юнитов, стейкхолдеры, технические специалисты, специалисты обеспечивающих подразделений, которые в ходе своей работы сталкиваются с заказами на создание или принятием первоначальных этапов работ по созданию ПО.

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

Что такое ППО и как оно выполняется

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

Мы изучаем требования к продукту, которые предъявляет бизнес, исследуем предметную область и ограничения внешней среды. После этого мы подготавливаем ряд артефактов (документов), в которых под разными углами структурируем информацию о будущем проекте.

Из чего состоят результаты ППО

Разберем более детально типичные артефакты ППО.

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

Полезно использовать следующую структуру документа:

2. цели и задачи проекта;
3. схемы бизнес-процессов и их описание (as is, to be);
4. реестр функциональных требований;
5. описание ролей пользователей системы;
6. описание ограничений системы;
7. описание use-case (UML-диаграммы вариантов использования);
8. описание предметной области;
9. требования к UI;
10. описание взаимодействия между компонентами системы и внешними системами.

Помимо оценки, декомпозированные таким образом функции позволяют легче собрать use-case конечного пользователя продукта и АРМ внутренних пользователей для размещения их в соответствующем разделе Vision.

• Архитектура — описание комплекса программно-аппаратных компонентов будущей системы и преимущества его использования. Мы выделяем следующие уровни при описании архитектуры:

4. архитектурный;
5. концептуальный;
6. технологический;
7. программный;
8. аппаратно-сетевой.

• План-график — распределение работ над функциями во времени.
• Смета — оценка составляющих проекта по времени и стоимости.

Типовые ситуации «входа» в ППО

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

Наш опыт позволяет сгруппировать проекты по степени их готовности к выполнению ППО:

• Проектная команда, которой нужно ППО для получения документа, описывающего концепцию и детали проекта, чтобы защитить бюджет этого проекта или запустить тендер.
• Руководители проектов, которым не нужно ППО, но они понимают его необходимость для продукта и команды, которая его делает.
• Заказчики проектов, которым не нужно ППО, и они не понимают его необходимость, но при этом согласны платить за него, раз уж так надо. Такая ситуация встречается, когда есть доверие к исполнителям и процесс создания продукта строится с опорой на их компетенции.
• Заказчики проектов, которые не понимают, зачем нужно ППО, и платить за него не согласны.

Зачастую, в зависимости от описанных выше позиций заказчиков, дальнейшие взаимоотношения после выполнения ППО складываются по следующим сценариям:

• Для первого типа — после проведения ППО и утверждения бюджета идет переход к реализации проекта по смете. Иногда взаимоотношения заканчиваются в связи с тем, что заказчик выбрал другого исполнителя или решил, что проект не нужен.
• Для второго и третьего типа важным является оценочная стоимость проекта. Если первоначальный расчет в разы не отличается от финального, то происходит переход к реализации проекта, иначе — выбор другого исполнителя.
• Так как переубедить заказчика, который решил, что из него вытягивают деньги, очень сложно, чаще всего происходит прекращение взаимоотношений после окончания ППО для четвертого типа.

Как улучшить скоуп проекта

Мы считаем, что самым важным результатом ППО является корректное определение скоупа проекта. Редко когда можно сходу его определить, так как полным пониманием не владеет ни одна из сторон.

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