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

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

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

По данным опроса 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 и документируем архитектуру до того, как будет инициализирован первый репозиторий.

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

Часто задаваемые вопросы

Чем список функций отличается от объёма работ?

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

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

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

О чём спросить подрядчика до подписания договора?

Спросите, предоставят ли они модель данных и описание архитектуры до старта разработки. Уточните, как они обрабатывают изменения требований в середине спринта. Выясните, к чему привязана оплата: к затраченным часам или к сданному рабочему продукту.

Почему просто начать писать код для небольшого продукта — плохая идея?

Разработка без чертежа приводит к одноразовой архитектуре. При первой же серьёзной доработке приложения исходную кодовую базу приходится выбрасывать, и вы платите за разработку дважды. В Webiland схема базы данных, карта API и архитектура документируются ещё до создания репозитория.