Колонки

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

Колонки
Дмитрий Теслев
Дмитрий Теслев

Ведущий системный аналитик AGIMA

Анастасия Фролова

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

Дмитрий Теслев, ведущий системный аналитик в компании AGIMA, рассказывает, что такое предпроектное обследование, зачем оно нужно, и какой профит может получить бизнес от этого этапа. Колонка будет полезна тем, кто разрабатывает и развивает цифровые продукты, продакт овнерам, предпринимателям и аутсорс-компаниям.

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

Содержание


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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

Фича Функция
Новостная лента П. Просмотр ленты новостей
Новостная лента БП (контент-менеджер). Управление содержимым новостей и параметрами новостной ленты
Новостная лента А. Управление шаблонами новостей
Новостная лента С. Интеграция с хранилищем фотографий по существующему API.

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

  • Архитектура — описание комплекса программно-аппаратных компонентов будущей системы и преимущества его использования. Мы выделяем следующие уровни при описании архитектуры:
  1. архитектурный; 
  2. концептуальный; 
  3. технологический;
  4. программный; 
  5. аппаратно-сетевой. 
  • План-график — распределение работ над функциями во времени. 
  • Смета — оценка составляющих проекта по времени и стоимости. 

 

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

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

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

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

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

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

 

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

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

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

Проблема Что делать
Нет четкого представления о внутренних процессах, они нигде не зафиксированы и имеют много разных вариантов, зависящих от разных факторов.
  • Провести встречи по снятию требований со всеми участниками процесса. 
  • Выявить все варианты процесса.
  • Построить основной процесс с выделением автоматизируемых шагов.
  • Проработать альтернативные ветки процесса, систематизируя разные варианты и сводя их к нескольким вариантам. 
  • Отрисовать процесс на схемах и снабдить понятным описанием.
Отсутствует представление о том, какие части процесса нуждаются в автоматизации, какие из уже автоматизированных — в замене.
  • Выделить шаги, которые нужно автоматизировать. 
  • Проанализировать существующую автоматизацию на предмет полноты предъявляемых требований, в том числе в перспективе развития системы. 
  • Предложить соответствующее решение, обладающее недостающими функциями.
Фрагментированное и неполное представление о готовых программных продуктах, способных решить проблемы заказчика.
  • Предоставить перечень систем под требуемый функционал с описанием плюсов и минусов использования, стоимости покупки, поддержки, развития.
Отсутствие понимания необходимости в системе контура настроек и управления, а также рабочих мест для бизнес-пользователей. Или недостаточная степень детализации такого понимания.
  • Включить в состав требований к системе и в use case описание возможностей АРМ внутренних пользователей  и действий администраторов.
Неупорядоченные данные об интеграции с внешними системами
  • Дополнить описание процессов to be схемой интеграций с описанием потоков данных из внешних систем. 

 

Ценность для заказчика 

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

В итоге он получает структурированные требования к продукту, знания об оценочной стоимости работ, их этапах и сроках.

 

Ценность для исполнителя 

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

Декомпозиция дает понимание, какая функция приоритетнее и должна быть сделана раньше, а какая — в следующем релизе.

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

 

Ценность для продукта и проекта 

По итогам ППО снижаются риски неисполнения, так как проект делится на понятные всем сторонам этапы с соответствующим наполнением.

Подробная оценка длительности работ на основе декомпозиции избавляет участников от «излишнего оптимизма» — недооценки времени на реализацию. 

Исполнитель и заказчик становятся понятнее друг для друга, что в дальнейшем облегчает коммуникации, а это в конечном итоге наполняет продукт большей пользой для конечного потребителя.

Фото на обложке: Freer/shutterstock.com

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Метапоисковик авиабилетов Aviasales привлек $43 млн на фоне рекордного падения авиаперевозок
  2. 2 Два способа быстро оценить качество кейсов digital-агентств
  3. 3 Как финтех-стартап с российскими корнями помогает американцам оплачивать свадьбы
  4. 4 «Ак Барс Дом» и МТС открыли треки в акселераторе «Startup-Сабантуй. Цифровизация»
  5. 5 «Искренне верю, Xsolla не для вас»: компания уволила часть сотрудников после «анализа их активности»
Какие инструменты и сервисы работают для предпринимателей, а какие нет?
Подробный разбор в выпусках нового подкаста от МТС
Узнать больше

ВОЗМОЖНОСТИ

05 августа 2021

08 августа 2021