Прежде чем создавать новый цифровой продукт, улучшать или перерабатывать уже готовый, важно зафиксировать, в каком виде он находится, и каковы требования к его будущему состоянию. Исходя из этих требований, формируются границы проекта по созданию и развитию продукта.
Дмитрий Теслев, ведущий системный аналитик в компании AGIMA, рассказывает, что такое предпроектное обследование, зачем оно нужно, и какой профит может получить бизнес от этого этапа. Колонка будет полезна тем, кто разрабатывает и развивает цифровые продукты, продакт овнерам, предпринимателям и аутсорс-компаниям.
Содержание
- Что такое ППО и как оно выполняется
- Из чего состоят результаты ППО
- Типовые ситуации «входа» в ППО
- Как улучшить скоуп проекта
- Ценность для заказчика
- Ценность для исполнителя
- Ценность для продукта и проекта
Мы занимаемся разработкой сложных продуктов на заказ. Для нас крайне важно до начала основных работ по проекту иметь о нем как можно больше структурированных знаний.
С их помощью мы должны ответить на ряд вопросов: каковы будут скоуп, структура и функционал продукта? В чем состоят ожидания заказчика? Каковы сроки и стоимость выполнения работ? Какие функции войдут в MVP?
Инструментом, который дает нам ответы на все вопросы, является предпроектное обследование. Для краткости будем дальше использовать стандартное сокращение — ППО.
Нам бы хотелось, чтобы эта статья была полезна тем участникам процесса разработки цифровых продуктов, которые работают с ним на начальных этапах.
Первые — это представители заказчика: руководители бизнес-юнитов, стейкхолдеры, технические специалисты, специалисты обеспечивающих подразделений, которые в ходе своей работы сталкиваются с заказами на создание или принятием первоначальных этапов работ по созданию ПО.
Также это наши коллеги — представители других студий, которые могут сравнить свои процессы с нашими. Третья группа — это менеджеры проектов. Для них мы постараемся донести представление о ценности этапа предпроектного обследования с точки зрения всего производственного цикла.
Что такое ППО и как оно выполняется
Предпроектное обследование — это та часть проекта, которая выполняется между точкой инициации и началом основных работ. Задача этого этапа — получить значимое представление о проекте за разумный срок, чтобы дать максимально точную и обоснованную оценку состава, сроков и стоимости дальнейших работ.
Мы изучаем требования к продукту, которые предъявляет бизнес, исследуем предметную область и ограничения внешней среды. После этого мы подготавливаем ряд артефактов (документов), в которых под разными углами структурируем информацию о будущем проекте.
Из чего состоят результаты ППО
Разберем более детально типичные артефакты ППО.
Полезно использовать следующую структуру документа:
- цели и задачи проекта;
- схемы бизнес-процессов и их описание (as is, to be);
- реестр функциональных требований;
- описание ролей пользователей системы;
- описание ограничений системы;
- описание use-case (UML-диаграммы вариантов использования);
- описание предметной области;
- требования к UI;
- описание взаимодействия между компонентами системы и внешними системами.
Такой перечень нужен для подробной оценки каждой функции всеми участниками производственного процесса: аналитиками, UX/UI-дизайнерами, разработчиками разных специализаций, тестировщикам, менеджерами. На наш взгляд, для составления и дальнейшей работы лучше всего подходит табличная форма, где в первой колонке будет раздел или фича, а во второй — функция. Обычно мы делим функции по следующим ролям: пользователь (П), бизнес-пользователь (БП), администратор (А), система (С).
| Фича | Функция |
|---|---|
| Новостная лента | П. Просмотр ленты новостей |
| Новостная лента |
БП (контент-менеджер). Управление содержимым новостей и параметрами новостной ленты |
| Новостная лента | А. Управление шаблонами новостей |
| Новостная лента | С. Интеграция хранилищем фотографий по существующему API. |
Помимо оценки, декомпозированные таким образом функции позволяют легче собрать use-case конечного пользователя продукта и АРМ внутренних пользователей для размещения их в соответствующем разделе Vision.
- Архитектура — описание комплекса программно-аппаратных компонентов будущей системы и преимущества его использования. Мы выделяем следующие уровни при описании архитектуры:
- архитектурный;
- концептуальный;
- технологический;
- программный;
- аппаратно-сетевой.
- План-график — распределение работ над функциями во времени.
- Смета — оценка составляющих проекта по времени и стоимости.
Типовые ситуации «входа» в ППО
Так как ППО не является первым этапом проекта, то вход в него для сторонней организации может быть достаточно разным.
Наш опыт позволяет сгруппировать проекты по степени их готовности к выполнению ППО:
- Проектная команда, которой нужно ППО для получения документа, описывающего концепцию и детали проекта, чтобы защитить бюджет этого проекта или запустить тендер..
- Руководители проектов, которым не нужно ППО, но они понимают его необходимость для продукта и команды, которая его делает.
- Заказчики проектов, которым не нужно ППО, и они не понимают его необходимость, но при этом согласны платить за него, раз уж так надо. Такая ситуация встречается, когда есть доверие к исполнителям и процесс создания продукта строится с опорой на их компетенции.
- Заказчики проектов, которые не понимают, зачем нужно ППО, и платить за него не согласны.
Зачастую, в зависимости от описанных выше позиций заказчиков, дальнейшие взаимоотношения после выполнения ППО складываются по следующим сценанариям:
- Для первого типа — после проведения ППО и утверждения бюджета идет переход к реализации проекта по смете. Иногда взаимоотношения заканчиваются в связи с тем, что заказчик выбрал другого исполнителя или решил, что проект не нужен.
- Для второго и третьего типа важным является оценочная стоимость проекта. Если первоначальный расчет в разы не отличается от финального, то происходит переход к реализации проекта, иначе — выбор другого исполнителя.
- Так как переубедить заказчика, который решил, что из него вытягивают деньги, очень сложно, чаще всего происходит прекращение взаимоотношений после окончания ППО для четвертого типа.
Как улучшить скоуп проекта
Мы считаем, что самым важным результатом ППО является корректное определение скоупа проекта. Редко когда можно сходу его определить, так как полным пониманием не владеет ни одна из сторон.
Приведем несколько типичных проблем и способов их решения для приведения скоупа к нормальному виду, который позволит на его основе выполнить функциональную декомпозицию и оценку проекта.
- Нет четкого представления о внутренних процессах, они нигде не зафиксированы и имеют много разных вариантов, зависящих от разных факторов.
Что делать:
- Отсутствует представление о том, какие части процесса нуждаются в автоматизации, какие из уже автоматизированных — в замене.
Что делать:
- Фрагментированное и неполное представление о готовых программных продуктах, способных решить проблемы заказчика.
Что делать:
- Отсутствие понимания необходимости в системе контура настроек и управления, а также рабочих мест для бизнес-пользователей. Или недостаточная степень детализации такого понимания.
Что делать:
- Неупорядоченные данные об интеграции с внешними системами.
Что делать:
Ценность для заказчика
Заказчик, получив артефакты ППО, находится в принципиально иной позиции, чем до его начала. Он понимает границы проекта, внутреннюю структуру будущего продукта, стоимость, очередность выполняемых работ, состав MVP и перспективы его развития. После этого он может принять обоснованные решения о продолжении работ, об отказе от проекта, о выставлении работ на тендер.
В итоге он получает структурированные требования к продукту, знания об оценочной стоимости работ, их этапах и сроках.
Ценность для исполнителя
Основная ценность для исполнителя — лучшее понимание проекта. Структурированное понимание состава, сроков и очередности реализации функций позволяет улучшить планирование ресурсов: когда требуется подключать ресурсы заказчика или других исполнителей, и как выстроить взаимодействие с другими командами, если на смежных задачах работают несколько команд одновременно.
Декомпозиция дает понимание, какая функция приоритетнее и должна быть сделана раньше, а какая — в следующем релизе.
Стоимость проекта детально обоснована до уровня функции определенной роли. Это помогает на последующих этапах, связанных с защитой финансирования и оценкой эффективности реализации.
Ценность для продукта и проекта
По итогам ППО снижаются риски неисполнения, так как проект делится на понятные всем сторонам этапы с соответствующим наполнением.
Подробная оценка длительности работ на основе декомпозиции избавляет участников от «излишнего оптимизма» — недооценки времени на реализацию.
Исполнитель и заказчик становятся понятнее друг для друга, что в дальнейшем облегчает коммуникации, а это в конечном итоге наполняет продукт большей пользой для конечного потребителя.
Комментарии и обсуждения статьи в нашем блоге на RUSBASE