Коротко. Оценка «три месяца» превращается в девять не потому, что разработчики ленивы, а потому, что стоимость изменения растёт вместе с возрастом системы. Это свойство, а не халатность. Понимание его механики меняет то, как заказчик читает смету и как ведёт переговоры о сроках.
Зачем это бизнесу
Срок разработки — это не оценка объёма работы, а ставка на количество неизвестного. Заказчик, который умеет отличить одно от другого, перестаёт торговаться за недели и начинает торговаться за объём и порядок выпуска — а это единственный разговор, который реально сокращает срок.
Маршрут
| Ступень | Что читаем | Что забираем | Срок |
|---|---|---|---|
| 1. Как устроен код | Книги по чистому коду и рефакторингу | Почему «просто добавить поле» стоит две недели | 3 недели |
| 2. Структура системы | Литература по архитектуре приложений и паттернам проектирования | Границы модулей, связанность, цена неверного разделения | 4 недели |
| 3. Интерфейсы | «Непрерывное развитие API», «API как искусство» | Почему изменение интерфейса стоит дороже изменения логики | 2 недели |
| 4. Распределённость | «Облачные микросервисы», «Архитектура бэкенда» | Какие отказы появляются, когда система разделена по сети | 4 недели |
| 5. Проверка | «Основы тестирования и верификации» | Что даёт автоматическая проверка и во что она обходится | 2 недели |
| 6. Выпуск | Материалы по непрерывной поставке и флагам функций | Как выпускать чаще и мельче, снижая риск каждого выпуска | 3 недели |
Семь выводов — своими словами
- Сложность не исчезает, она перемещается. Упростили код — усложнилась инфраструктура; упростили инфраструктуру — вырос монолит. Выбор всегда о том, где вы готовы держать сложность.
- Технический долг — это не грязный код, а отложенное решение. Часть долга берётся осознанно ради скорости, и это нормально; ненормально — не вести его учёт.
- Оценка врёт пропорционально неизвестному. Задача с двумя неизвестными зависимостями оценивается точно; с десятью — не оценивается вовсе, и честный ответ звучит как вилка, а не как дата.
- Изменение интерфейса дороже изменения реализации. Как только к вашему API кто-то подключился, вы платите за совместимость каждым релизом.
- Мелкие частые выпуски безопаснее редких крупных. Риск релиза растёт быстрее его размера, поэтому «накопим и выкатим разом» — самая дорогая стратегия.
- Тесты покупают не качество, а скорость изменений. Они окупаются в системах, которые живут дольше года и меняются чаще раза в месяц.
- Переписать с нуля почти всегда дороже, чем кажется. Старая система содержит годы неочевидных исключений, которые нигде не описаны.
Как читать смету подрядчика
| Признак | Что это значит |
|---|---|
| Точная дата на срок больше квартала | Либо огромный запас внутри, либо оценка не сделана |
| Нет строки на интеграции | Самая недооценённая часть: чужие системы всегда ведут себя не по документации |
| Нет приёмки и стабилизации | Срок сдвинется ровно на этот невключённый этап |
| Один большой этап вместо нескольких | Вы узнаете о проблемах в конце, когда менять что-либо дорого |
| Нет ответственного за решения с вашей стороны | Основная причина простоев — ожидание ответа заказчика |
Красные флаги
- Подрядчик соглашается на срок без обсуждения объёма — значит, объём будет резаться молча.
- Архитектура выбрана до понимания нагрузки и требований к доступности.
- Микросервисы в проекте на трёх разработчиков.
- Обещание «сделаем гибко, потом поменяем» без описания, что именно останется неизменным.
- Отсутствие демонстраций работающего результата раз в две-три недели.
Частые вопросы
Связанное
- Модель C4 — как описывать архитектуру
- Метрики DORA
- Разработка в основной ветке
- Флаги функций
- Постепенная поставка
- Смещение тестирования влево
Книги названы как источники. KZSalesHub не распространяет файлы изданий.
Стоимость изменения растёт вместе с возрастом системы — это свойство, а не халатность команды. Объяснив механику заказчику, вы переводите спор о сроках в разговор о приоритетах.
