Предпроектное исследование: не задержка, а страховой полис вашего проекта

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

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

На деле исследование работает наоборот. Оно переносит изменения объёма туда, где их дешевле всего вносить: в документ, до того как от них зависит хоть одна строка кода.

Миф: «Исследование — это время, за которое мы платим до того, как что-то построено»

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

По данным Boehm и Basili, проекты разработки ПО тратили около 40–50% трудозатрат на переделки, которых можно было избежать — Boehm & Basili, 2001. Пропуск этапа исследования означает, что разработчики будут делать допущения о вашей бизнес-логике. Когда эти допущения окажутся неверными на пользовательском тестировании, код придётся выбросить и написать заново. Вы платите за исследование в любом случае — либо заранее документацией, либо позже и дороже — переделками в ходе разработки.

Что на самом деле даёт этап исследования

Строгое исследование производит конкретные технические результаты:

1. 01
   Функциональная спецификация

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

2. 02
   Архитектурный чертёж

   Техническая схема со схемой базы данных, фронтенд-фреймворком, серверными технологиями и инфраструктурой.

3. 03
   Реестр интеграций

   Подробная карта всех сторонних API (платёжные шлюзы, CRM, ERP), с которыми должна соединяться система, включая структуры передаваемых данных и лимиты запросов.

4. 04
   Журнал рисков

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

5. 05
   План этапов и итоговая оценка

   Точный график разработки и бюджет, основанные на определённых требованиях, а не на догадках.

Цена пропуска: как именно расползается объём

Как возникает расползание объёма без предпроектного исследования? Возьмём платформу электронной коммерции. Без исследования требование звучит просто: «добавить приём платежей». В ходе разработки клиент понимает, что нужны регулярные подписки, мультивалютность и автоматический расчёт налога для клиентов из ЕС.

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

Сколько это занимает и сколько стоит

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

Как понять, что процесс исследования в студии строгий

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

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

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