Предпроектное обследование (ППО) в разработке цифровых продуктов

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

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

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

Функционально-технические требования (ФТТ) - это:

• Инструмент для быстрой фиксации приоритетов бизнеса и пользователей.
• База для точной оценки сроков и бюджета разработчиками.
• Гарантия, что MVP будет решать ключевые задачи, без перегруза ненужными функциями.

Подробнее о структуре и содержании этого документа мы рассказывали в отдельной статье.

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

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

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

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

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

6. Оценка стоимости и сроков разработки. Формирование предварительной сметы и плана работ позволяет заказчику оперировать стоимостью; понимать финансовые и временные затраты. Это также помогает принимать обоснованные решения о целесообразности проекта.

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

8. Увеличение ROI. Обследование связывает функциональные требования с бизнес-целями: формируется MVP и дорожная карта, оценивается TCO (стоимость владения) и экономический эффект по этапам, фиксируются метрики успеха (KPI/OKR) и источники данных. Отбрасывается «лишний» функционал, уточняются сценарии монетизации/экономии, заранее учитываются ограничения регуляторики и масштабирования. В результате быстрее достигаются измеримые эффекты (выручка, экономия, снижение операционных рисков), а инвестиции в разработку распределяются в пользу фич с наилучшим соотношением ценности и стоимости.

Ключевые этапы ППО, которые обеспечивают успешную реализацию проекта:

02

анализ существующей системы;

03

технический анализ и проектирование;

анализ бизнеса и потребностей;

01

планирование проекта;

04

05

подготовка отчета.

Разберём подробнее, что происходит на каждом из этапов.

Этап 1: Анализ бизнеса и потребностей

•

Интервью с ключевыми стейкхолдерами.

•

Анализ бизнес-процессов.

•

Определение целей и задач проекта.

•

Формулирование требований к функциональности и производительности.

•

Аудит текущего программного обеспечения.

•

Оценка интеграционных возможностей.

•

Выявление проблем и недостатков существующей системы.

•

Выбор технологий и архитектуры.

•

Разработка прототипа или MVP.

•

Оценка масштабируемости и безопасности.

•

Составление плана работ с указанием сроков и ресурсов.

•

Определение бюджета проекта.

•

Разработка стратегии тестирования и развертывания.

•

Документирование результатов обследования. Включает анализ рисков и рекомендации.

•

Представление отчета заказчику и обсуждение результатов.

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

Итоги предпроектного обследования фиксируются в документе функционально-технических требований (ФТТ) и передаются заказчику. Это объемный и подробный документ, но не настолько детализированный, как техническое задание; он говорит о будущем продукте более обобщенно.

Например, авторизация в сервисе будет так описана в ФТТ: «Способ входа (логин/пароль, OAuth, 2FA), роли пользователей (клиент, админ), блокировка при многократных ошибках». А в техническом задании описание авторизации будет выглядеть так: «Алгоритм хеширования паролей, токены сессии, лимиты попыток входа, обработка ошибок (например, „Неверный логин“)».

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

Функционально-технические требования (ФТТ) — главный артефакт предпроектного этапа. Это согласованный документ, который фиксирует, что система должна делать (функционал) и как она должна работать (технические и нефункциональные требования). На его основе формируется архитектура, смета, план работ и критерии приёмки.

• Самостоятельно силами заказчика: 2−3 месяца — из-за ограниченной экспертизы, перегруженности внутренних команд и итераций согласования.
• С привлечением экспертов: ~2 недели, благодаря опыту, отработанным методикам и готовым формулировкам требований.

Экономия времени на старте сокращает риски «ползущего» скоупа и уменьшает запас на непредвиденные работы в смете.
Мы в Uplab предлагаем своим клиентам услугу по разработке ФТТ. В качестве итога нашей работы заказчик получит:

1. Интервью со стейкхолдерами проекта (бизнес-цели, KPI, законодательные ограничения, безопасность, зоны ответственности);
2. Моделирование основных процессов (включая узкие места и риски, триггеры процессов, события и результаты);
3. Проработка пользовательских сценариев (правила доступа и роли, прототипы ключевых экранов);
4. Описание функциональных требований (что должна делать система);
5. Описание технических и нефункциональных требований (как должна работать система: архитектурные ограничения и целевые интеграции, производительность, поддержка и т. д).

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