Чертёж до стройки: почему мы не начинаем без письменного объёма работ

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

По данным опроса Project Management Institute 2018 года, в 52% проектов, завершённых за предыдущие 12 месяцев, объём расползался или менялся бесконтрольно (PMI, 2018). Именно поэтому строгий этап исследования в разработке приложения — не задержка в графике, а самый важный компонент самого продукта.

Сколько стоит начать без объёма работ

Принцип программной инженерии, который Boehm и Basili опубликовали в IEEE Computer: найти и исправить проблему в ПО после сдачи часто обходится в 100 раз дороже, чем на этапе требований и проектирования (Boehm & Basili, 2001).

Список функций — это не объём работ. Выбор между заказным веб-приложением и сайтом — бизнес-решение, но его исполнение требует технической конкретики. Функциональная спецификация описывает, как именно ведёт себя система. Архитектурный бриф определяет схему базы данных, маршрутизацию API и инфраструктуру, необходимую для этого поведения. Без всех трёх документов невозможно ни точно оценить стоимость, ни составить график.

Что производит этап исследования

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

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

   Письменный документ, описывающий каждый пользовательский сценарий и каждое действие системы.

2. 02
   Архитектурный бриф

   Схема инфраструктуры: развёртывание серверов, очереди, внешние интеграции.

3. 03
   Модель данных

   Точная схема базы данных и связей.

4. 04
   Карта API

   Описание всех необходимых эндпоинтов и передаваемых данных.

5. 05
   Реестр технических рисков

   Перечень возможных узких мест и способов их снятия.

6. 06
   График оплат по этапам

   График, привязывающий оплату напрямую к проверенным, готовым к развёртыванию результатам.

Три вопроса до подписания договора

Перед заключением договора на разработку спросите подрядчика:

• Предоставите ли вы модель данных и архитектурный бриф до начала разработки?
• Как вы поступаете при изменении требований в середине спринта?
• Оплата привязана к затраченному времени или к работающему ПО?

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

Почему «начать с малого» дорого

Установка «просто начните писать MVP» приводит к одноразовой архитектуре. Разработка без чертежа гарантирует, что первый код будет выброшен, когда приложению понадобится первая серьёзная итерация. Вы платите за разработку дважды.

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

Требуйте письменный объём работ. Проверьте архитектуру на бумаге, прежде чем платить за неё кодом.