---
title: "Почему софт делается дольше, чем обещали"
url: "https://kzsaleshub.com/marshrut-pochemu-soft-dolshe/"
type: "knowledge_article"
category: "Библиотека"
language: "ru"
source: "KZSalesHub"
published: "2026-08-15"
last_updated: "2026-09-30"
---

# Почему софт делается дольше, чем обещали

**Коротко.** Оценка «три месяца» превращается в девять не потому, что разработчики ленивы, а потому, что стоимость изменения растёт вместе с возрастом системы. Это свойство, а не халатность. Понимание его механики меняет то, как заказчик читает смету и как ведёт переговоры о сроках.

## Зачем это бизнесу

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

## Маршрут

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

## Семь выводов — своими словами

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

## Как читать смету подрядчика

| Признак | Что это значит |
| --- | --- |
| Точная дата на срок больше квартала | Либо огромный запас внутри, либо оценка не сделана |
| Нет строки на интеграции | Самая недооценённая часть: чужие системы всегда ведут себя не по документации |
| Нет приёмки и стабилизации | Срок сдвинется ровно на этот невключённый этап |
| Один большой этап вместо нескольких | Вы узнаете о проблемах в конце, когда менять что-либо дорого |
| Нет ответственного за решения с вашей стороны | Основная причина простоев — ожидание ответа заказчика |

## Красные флаги

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

## Частые вопросы

**Можно ли ускорить проект, добавив разработчиков**

На поздних этапах — почти никогда: новые люди сначала отнимают время у действующих. Ускоряет сокращение объёма и уменьшение числа согласований.

**Как понять, что долг стал критическим**

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

**Стоит ли требовать фиксированную цену**

На типовой работе — да. На разработке с большим числом неизвестных фиксированная цена оплачивается запасом в смете и спорами об объёме.

## Связанное

- [Модель C4](https://kzsaleshub.com/framework/c4-model/) — как описывать архитектуру
- [Метрики DORA](https://kzsaleshub.com/framework/dora-metrics/)
- [Разработка в основной ветке](https://kzsaleshub.com/framework/trunk-based/)
- [Флаги функций](https://kzsaleshub.com/framework/feature-flags/)
- [Постепенная поставка](https://kzsaleshub.com/framework/progressive-delivery/)
- [Смещение тестирования влево](https://kzsaleshub.com/framework/shift-left-testing/)

*Книги названы как источники. KZSalesHub не распространяет файлы изданий.*

Стоимость изменения растёт вместе с возрастом системы — это свойство, а не халатность команды. Объяснив механику заказчику, вы переводите спор о сроках в разговор о приоритетах.

---
Источник: https://kzsaleshub.com/marshrut-pochemu-soft-dolshe/