Оценка сроков и стоимости разработки по ТЗ: как делается по‑взрослому (и где вас обычно “обманывают”)
Запросы вида “оценка сроков разработки”, “оценка стоимости разработки”, “стоимость разработки по ТЗ” — это не про одну цифру. Это про управление риском: вы покупаете не код, а предсказуемый результат.
Ниже — как выглядит нормальная оценка, какие вопросы должны быть закрыты в ТЗ (или в брифе), и как отличить оценку от гадания.
1) Почему “одна цифра” почти всегда вредит
Если вам говорят: “сделаем за 2 недели, стоит N” — без:
- списка модулей,
- допущений,
- рисков,
- критериев готовности,
то это не estimate. Это “чтобы согласились”.
Реальность догонит позже: “это не входило”, “оказалось сложнее”, “нужны роли/права”, “интеграция нестабильная”, “дизайн не готов”.
2) Что нужно для оценки (минимум)
2.1. Scope: что делаем в первой версии (MVP)
Без этого оценка расплывается. В нормальном ТЗ всегда есть:
- “что входит”
- “что не входит”
2.2. Сценарии (user stories) и acceptance criteria
Оценка считается по сценариям, а не по “фичам из головы”.
Пример:
- “Пользователь оформляет подписку” — это не одна кнопка, а сценарий с оплатой, вебхуками, статусами, ошибками, доступами.
2.3. Интеграции
Любое “подключить CRM/платежи/доставку” может быть:
- 2 часа, если есть готовый SDK и ясные события
- 2 недели, если API нестабильный, лимиты, ретраи, идемпотентность, очереди
3) Из чего складываются сроки разработки (карта работ)
Нормальная оценка разложена по блокам:
- Discovery/уточнение требований (иногда 0.5–3 дня)
- Архитектура и модель данных (особенно для web app/бота с админкой)
- Backend/API (эндпоинты, авторизация, интеграции)
- Frontend (экраны, состояния, формы, валидация)
- Админка (часто “вдруг” 30–50% проекта)
- Тестирование (минимум smoke + критические сценарии)
- Деплой/инфраструктура (Docker, окружения, секреты)
- Мониторинг/логи (чтобы не ловить проблемы вслепую)
- Приёмка по критериям (acceptance criteria)
Даже если часть пунктов “упрощается”, они должны быть явно отмечены.
4) Как выглядит “хорошая” оценка (формат результата)
4.1. Таблица модулей
Например:
- Авторизация/роли — X–Y дней
- Платежи — X–Y дней
- Telegram‑интерфейс — X–Y дней
- Админка — X–Y дней
Почему диапазон? Потому что честный оценщик показывает неопределённость и объясняет её.
4.2. Список допущений (assumptions)
Примеры:
- “Дизайн готов и не меняется”
- “Платёжный провайдер — YooKassa/Stripe, есть доступы”
- “Нагрузка на старте до 10k пользователей/мес”
4.3. Список рисков
Примеры:
- “Внешний API может падать → нужны ретраи/очередь”
- “Нужны роли/права сложнее → увеличится объём админки”
4.4. План релизов
Хорошая практика: 2–4 коротких релиза вместо “большого взрыва”.
5) Типовые “скрытые” части, которые ломают сроки
- Админка (управление контентом/тарифами/пользователями)
- Права доступа (RBAC, аудит действий)
- Ошибки и крайние случаи (отмена платежа, двойной клик, потеря сети)
- Миграции данных (если переносите из Excel/старой системы)
- Наблюдаемость (логи, метрики, алерты)
Если в оценке этого нет — потом появится как “допработы”.
6) “Чек‑лист” вопросов перед оценкой
Если у вас пока нет полного ТЗ, я обычно задаю 12 вопросов:
- Кто пользователь и какие роли?
- Как выглядит ключевой сценарий “успеха”?
- Какие интеграции и кто даёт доступы?
- Нужна ли админка? Что в ней управляется?
- Есть ли дизайн? В каком виде?
- Какие платформы (web/iOS/Android/Telegram)?
- Нужна ли авторизация? Какая?
- Какие уведомления (email/sms/push/Telegram)?
- Какие отчёты/выгрузки?
- Какие требования по скорости/нагрузке?
- Что обязательно в MVP, что позже?
- Как принимаем работу (acceptance criteria)?
7) Чем я могу помочь
- Оценка сроков/стоимости по вашему ТЗ (с рисками и допущениями)
- ТЗ под оценку: превращаю “идею” в проверяемые требования
- Roadmap: релизы, приоритеты, риски
Если хотите — помогу оценить сроки и бюджет диапазоном (с допущениями и рисками) и собрать план релизов, который реально выполняется. Напишите 3 вещи: MVP‑цель; критические сценарии/интеграции; что уже есть (макеты/ТЗ/код).