Сроки разработки цифрового сервиса: как проверить оценку подрядчика

Почти как демо low-code платформы на конференции: три клика, один график, аплодисменты.

В боевой разработке эта картинка обычно разбивается о первый же интеграционный эндпоинт, который «почти REST», но почему-то возвращает XML, живёт за VPN и падает по вторникам. Поэтому оценка сроков разработки цифрового сервиса — это не гадание на Jira, а проверяемая инженерная процедура. Не идеальная. Но намного честнее, чем «ну, месяца за три управимся».

Математика против интуиции: почему эстимейты расходятся с продакшеном

Самая дорогая ошибка заказчика — воспринимать оценку подрядчика как обещание. Эстимейт не обещание. Это модель. Иногда нормальная, иногда на соплях, иногда вообще декоративная: чтобы менеджер мог поставить красивую дату в коммерческое предложение и не спугнуть клиента.

Разработка цифрового сервиса почти никогда не состоит из чистого написания кода. Внутри сидит много скучных, но прожорливых работ:

• уточнение требований, потому что «личный кабинет» у пяти стейкхолдеров означает пять разных продуктов;
• проектирование архитектуры, схем данных, API-контрактов и сценариев отказа;
• настройка окружений, CI/CD, секретов, мониторинга, логирования;
• интеграции с внешними системами, где документация часто старше половины команды;
• тестирование, исправление регрессий, приемка, релизные процедуры;
• миграции данных, если проект не с нуля, а из мира легаси-боли;
• коммуникации, созвоны, ревью, согласования, ожидание доступов.

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

Заниженный эстимейт обычно пахнет одинаково. В нём мало детализации, нет рисков, нет буферов, тестирование записано одной строкой, DevOps отсутствует как класс, а интеграции выглядят так, будто все внешние системы дружелюбны, документированы и счастливы работать 24/7. Милый фэнтези-жанр. В проде не встречал.

Завышенный эстимейт тоже бывает. Там обратная патология: подрядчик закладывает страх за каждый чих, умножает неизвестность на два, добавляет «архитектурный запас» и продаёт обычный CRUD как запуск космического аппарата. Заказчику от этого не легче. Переплачивать за чужую тревожность — так себе инвестиция.

Проверка оценки начинается не с торга по цене часа. Она начинается с вопроса: из чего собрана эта цифра.

Если подрядчик не может объяснить срок на уровне задач, зависимостей и рисков, перед вами не оценка. Перед вами настроение.

Декомпозиция: где честный эстимейт отличается от красивой таблички

Нормальная оценка разработки приложения или веб-сервиса всегда упирается в декомпозицию. Большая задача «сделать авторизацию» звучит безобидно. Внутри может быть регистрация, подтверждение почты, восстановление пароля, OAuth, роли, refresh-токены, блокировка аккаунта, аудит действий, сессии на нескольких устройствах и ещё пара милых сюрпризов от службы безопасности.

Практическое правило простое: крупные задачи нужно дробить до подзадач длительностью примерно от 4 до 12 часов. Это не священная заповедь, но хороший инженерный ориентир. Если задача оценена в 40 часов и не разбита, её оценка почти бесполезна. Там может быть всё что угодно: от нормальной работы на неделю до технического болота на месяц.

Как читать декомпозицию подрядчика:

1. Смотрите на размер задач.

Если большинство пунктов по 1–2 часа, команда, вероятно, занимается бухгалтерией ради бухгалтерии. Оверхед на управление съест смысл. Если большинство задач по 24–80 часов, это не декомпозиция, а крупная нарезка тумана.

2. Ищите технические работы, а не только пользовательские фичи.

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

3. Проверяйте наличие интеграционных задач.

Для цифрового сервиса интеграции часто становятся главным пожирателем сроков. CRM, ERP, платежи, склад, уведомления, аналитика, push-сервисы. На бумаге это «подключить API». В жизни — сертификаты, лимиты, странные форматы ошибок и sandbox, который отличается от production как аквариум от океана.

4. Отдельно смотрите тестирование и исправления.

Если QA записан как «тестирование — 16 часов» на проект в несколько месяцев, это не оптимизм. Это красный флаг. Регрессии, тест-кейсы, проверка ролей, мобильных разрешений, браузеров и интеграционных сценариев не исчезают от того, что их не внесли в таблицу.

5. Проверяйте DevOps и релизный контур.

Окружения, сборки, деплой, переменные окружения, мониторинг, алерты, бэкапы, миграции. Всё это скучно. Поэтому часто забывают. Потом релиз превращается в ночной шаманизм с доступами и нервным Slack.

Для быстрой диагностики полезно смотреть не только на итоговые недели, но и на структуру оценки.

Чем подробнее декомпозиция, тем меньше магии. Но есть граница: если подрядчик на пресейле расписывает каждую кнопку до пикселя без нормального исследования, это тоже театр. Детальность должна соответствовать зрелости требований.

PERT: формула, которая охлаждает горячие головы

Интуитивная оценка разработчика часто звучит так: «Если всё нормально, сделаю за два дня». Проблема в словах «если всё нормально». В продакшене всё нормально бывает реже, чем хотелось бы. Поэтому для оценки неопределённых задач полезен PERT — метод, появившийся ещё в 1958 году в инженерных проектах, задолго до наших бесконечных спринтов и стендапов.

Суть проста. По каждой задаче берутся три оценки:

• O, optimistic — оптимистичный срок, если всё идёт гладко;
• M, most likely — наиболее вероятный срок;
• P, pessimistic — пессимистичный срок, если всплывают проблемы.

Ожидаемое время считается по формуле:

Te = (O + 4M + P) / 6

Формула не делает из хаоса швейцарские часы. Она просто не даёт команде жить в мире одного оптимистичного сценария. Наиболее вероятная оценка получает больший вес, но пессимистичный хвост тоже учитывается.

Допустим, нужно реализовать интеграцию с платежным провайдером:

• оптимистично: 16 часов, если документация точная, доступы выданы, sandbox работает;
• наиболее вероятно: 28 часов, потому что будут уточнения, моки, ошибки статусов;
• пессимистично: 56 часов, если всплывут проблемы с webhook, идемпотентностью и боевыми сертификатами.

Расчёт: (16 + 4 × 28 + 56) / 6 = 30,7 часа.

Это уже не бодрые «два дня», но и не панические «неделя с хвостом». Это более трезвая база для графика.

PERT особенно полезен там, где много неопределённости:

• интеграции с внешними API;
• миграции данных из старых систем;
• разработка сложных бизнес-правил;
• производительность под нагрузкой;
• mobile-specific сценарии: offline mode, push, разрешения ОС, фоновые процессы;
• задачи, завязанные на команды клиента или третьих поставщиков.

При проверке подрядчика можно попросить показать не только итоговую оценку, но и диапазоны. Не обязательно для каждой кнопки. Для рискованных блоков — обязательно. Если подрядчик даёт одну точку без диапазона на сложную интеграцию, он либо очень уверен, либо не в теме. Первое встречается редко.

При этом разница между нижней и верхней границами оценки обычно должна держаться в разумных пределах. Практический ориентир — около 20%. Если разрыв больше, значит требования туманные или задача рискованная. Это не повод сразу ругаться. Это повод не подписывать фиксированный график с лицом человека, который верит в сказки.

Большой диапазон в оценке — не слабость подрядчика. Слабость — делать вид, что неопределённости нет.

Буферы и риски: где живут «неизвестные неизвестности»

Есть два типа неприятностей. Первые известны заранее: нет доступа к тестовой CRM, API нестабилен, у клиента три согласующих департамента, релизы только по четвергам, безопасность проверяет всё вручную. Их можно оценить и включить в план.

Вторые — «неизвестные неизвестности». Та самая мина, на которую наступают в середине проекта: старая база содержит неожиданные дубликаты, мобильный SDK конфликтует с версией ОС, внешний сервис меняет лимиты, в проде нагрузка ведёт себя иначе, чем на стенде. Эти вещи нельзя расписать по задачам заранее. Но игнорировать их нельзя.

В классической практике на риски часто закладывают дополнительно 15–20% поверх базовой оценки. Для более широкой неопределённости по проекту разумный буфер может быть около 30%. Не как способ раздуть смету. Как страховка от реальности, которая не читала ваше ТЗ.

Заказчику важно понять, где этот буфер находится:

• Явно отдельной строкой.

Самый честный вариант. Видно базовую оценку, видно риск-буфер, можно обсуждать причины.

• Размазан по задачам.

Тоже рабочий подход, если подрядчик может объяснить логику. Например, каждая интеграционная задача оценена не по оптимистичному сценарию, а с запасом.

• Спрятан в завышенных ролях или непонятных коэффициентах.

Здесь начинается мутная вода. «Архитектурная сложность × 1,8» без пояснений — удобная ширма.

• Отсутствует полностью.

Самый опасный вариант. Такой эстимейт часто выигрывает тендер. Потом проигрывает проект.

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

Особенно аккуратно надо смотреть на оценки, где подрядчик обещает «всё включено» за срок заметно ниже остальных участников. Дешёвое предложение не всегда экономия. Иногда это просто неполная оценка. В ней не посчитаны риски, проектирование, QA, DevOps или сопровождение приемки. Потом всё это всплывёт change request’ами. Формально честно. По ощущениям — как наступить на грабли с логотипом vendor management.

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

Удобный миф: сроки срываются, потому что команда плохо работает. Иногда так и есть. Но чаще проект буксует на стыках. Там, где никто не владеет процессом полностью.

Самые частые причины затяжки:

1. Требования меняются быстрее, чем код попадает в main.

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

2. Нет владельца продукта со стороны заказчика.

Команда задаёт вопросы, но ответы идут неделю. Потом приходят от трёх людей и противоречат друг другу. Разработчики в это время не медитируют. Они либо стоят, либо делают предположения. Оба варианта дорогие.

3. Интеграции проверяются слишком поздно.

Если внешний API впервые трогают за неделю до релиза, проект сам попросился в пожар. Контракты, доступы, тестовые данные и сценарии ошибок надо поднимать рано.

4. Приемка устроена как археология.

На демо все кивают. На финальной приемке внезапно вспоминают требования из старой переписки, макетов и устных договорённостей. Поэтому acceptance criteria нужны не для бюрократии, а чтобы не спорить с призраками.

5. Нефункциональные требования забыты.

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

6. Фиксированная дата подписана до проверки неопределённостей.

Любимая корпоративная акробатика. Сначала обещаем релиз совету директоров, потом начинаем выяснять, что именно надо сделать. Потом виноваты все, кроме календаря.

Проверяя оценку разработчиков, надо смотреть не только на часы команды. Надо смотреть на зависимости. Кто выдаёт доступы. Кто согласует макеты. Кто принимает API-контракты. Кто готовит тестовые данные. Кто отвечает на вопросы в течение суток, а не «после внутреннего комитета».

Срок разработки цифрового сервиса — это не только производительность подрядчика. Это пропускная способность всей цепочки решений.

Когда нужен Discovery, а не бодрый старт разработки

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

В таких случаях нужен этап Discovery. Не как модная наклейка на пресейле, а как инженерная разведка. Его задача — определить концепцию продукта, ключевые пользовательские сценарии, архитектурные варианты, интеграционные зависимости и основные риски до полноценной разработки.

Discovery нужен, если:

• сервис создаётся с нуля, а бизнес-модель или сценарии ещё спорные;
• есть несколько внешних систем, но их API, доступы и ограничения не изучены;
• заказчик хочет фиксированный бюджет, но требования описаны на уровне «как у конкурента, только удобнее»;
• требуется мобильное приложение с offline-режимом, push-уведомлениями, геолокацией или сложной синхронизацией;
• в проекте есть миграция данных из легаси;
• непонятны нагрузки, SLA, требования безопасности и хранение чувствительных данных;
• несколько департаментов заказчика имеют разные ожидания от одного продукта.

Хороший результат Discovery — не презентация на 80 слайдов ради красоты. Нужны рабочие артефакты: карта сценариев, список функций первой версии, архитектурная схема на понятном уровне, перечень интеграций, риски, прототипы критичных экранов, backlog с предварительной оценкой, варианты релизного плана.

После Discovery оценка не становится стопроцентно точной. Такой магии нет. Но она перестаёт быть фантазией. Разница принципиальная.

Иногда заказчик отказывается от Discovery, потому что «надо быстрее кодить». Понимаю желание. Код выглядит как прогресс. Исследование выглядит как разговоры. Но если команда не понимает границы продукта, она будет исследовать их во время разработки. Только дороже. И с большим количеством переделок.

Как проверить оценку подрядчика до договора

Практическая проверка занимает меньше времени, чем потом разбирать заваленный релиз. Я бы смотрел на семь вещей.

1. Есть ли связь между требованиями и задачами.

Каждая значимая функция должна находиться в эстимейте. Если в ТЗ есть уведомления, роли, платежи, отчёты и админка, а в оценке видны только «frontend» и «backend», разговаривать рано.

2. Декомпозированы ли крупные блоки.

Задачи на 4–12 часов дают нормальную точность. Большие куски должны быть разбиты. Особенно интеграции и бизнес-логика.

3. Показаны ли роли команды.

Backend, frontend, mobile, QA, DevOps, аналитик, архитектор, тимлид — не все нужны всегда. Но если сложный сервис оценивают только разработчики без аналитики и тестирования, это экономия на тормозах.

4. Учтены ли риски и буферы.

15–20% на риски поверх базовой оценки — нормальная инженерная практика. Около 30% на неизвестности в более туманных проектах — тоже не криминал. Криминал — делать вид, что всё предсказуемо.

5. Есть ли диапазоны для неопределённых задач.

Для сложных блоков полезны оценки через PERT или хотя бы optimistic / likely / pessimistic. Одна точка на рискованную задачу — слабая опора.

6. Разделены ли разработка и календарный срок.

800 часов команды не равны 10 календарным неделям автоматически. Есть параллельность, зависимости, отпуска, ожидание ответов, ревью, приемка. Календарный план должен учитывать последовательность работ.

7. Понятно ли, что не входит в оценку.

Самая честная строка в коммерческом предложении — exclusions. Например: не входит наполнение контентом, покупка лицензий, аудит безопасности третьей стороной, публикация в сторах под аккаунтом клиента, поддержка после релиза. Если исключений нет, они всё равно есть. Просто пока безымянные.

На этом этапе не надо пытаться выбить из подрядчика «гарантию без отклонений». В разработке ПО такой гарантии нет. Лучше добиться прозрачности: что известно, что неизвестно, где запас, где зависимость от клиента, какие решения могут изменить срок.

Жёсткий, но честный вердикт

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

Нормальный подрядчик не обещает чудес. Он показывает неприятные места до договора. Объясняет, почему интеграция рискованна. Дробит задачи до вменяемого размера. Использует диапазоны там, где есть неопределённость. Закладывает буфер и не стесняется слова «риск».

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

Вывод простой. Проверяйте не итоговую дату, а механику её появления. Дата без механики — это не срок. Это надежда, оформленная в таблицу.