Как проверить график разработки ПО на реалистичность и зафиксировать дедлайны в договоре

Почему стандартные графики разработки часто невыполнимы

Классический план-график в виде диаграммы Ганта с блоками «Аналитика — 2 недели», «Разработка — 2 месяца», «Тестирование — 3 недели» почти всегда содержит скрытую погрешность в 40–60% от заявленных сроков. По данным отчёта Standish Group CHAOS Report 2023, только 31% проектов в сфере разработки ПО завершаются в срок и в рамках бюджета, а 53% проектов превышают изначальные сроки в среднем на 187%.

Основные причины такого расхождения между планом и фактом:

1. Оценка «сверху вниз» без декомпозиции. Менеджер проекта берёт общую трудоёмкость в человеко-часах и делит на количество разработчиков, не разбивая задачи до уровня конкретных технических шагов. В результате в графике отсутствуют задачи по настройке CI/CD, написанию миграций, ревью кода, code freeze, UAT-тестированию со стороны заказчика.

2. Игнорирование зависимостей между командами. График строится так, будто frontend, backend, DevOps и QA работают параллельно. На практике backend-эндпоинты часто блокируют работу frontend-разработчиков, а инфраструктурные изменения требуют согласования с отделом безопасности.

3. Отсутствие буфера на риски. Согласно методологии Critical Chain Project Management, при планировании необходимо закладывать буфер 20–30% от трудоёмкости критической цепи. В коммерческих договорах этот буфер часто «съедается» при согласовании бюджета.

4. Усреднение оценок команды. Когда подрядчик оценивает задачу коллективно по принципу «средний разработчик сделает за 5 дней», он не учитывает разницу в скорости между senior, middle и junior, а также время на онбординг новых участников.

5. Пренебрежение soft-нагрузкой. Митинги, code review, документация, баг-фиксы по старому функционалу занимают 30–40% рабочего времени разработчика, но в график не закладываются.

Дополнительный фактор — конфликт интересов. Подрядчик заинтересован в коротком графике, чтобы выиграть тендер, а заказчик — в длинном, чтобы занизить риски. В результате согласование сроков превращается в торг, где побеждает не объективная оценка, а переговорная позиция.

Методы проверки реалистичности оценки задач

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

Метод PERT (трёх точек)

Каждая задача оценивается трижды: оптимистичный срок (O), наиболее вероятный (M) и пессимистичный (P). Расчётная длительность вычисляется по формуле:

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

Пример: для задачи «интеграция с платёжным шлюзом» подрядчик назвал «7 дней». При PERT-оценке получается: O = 4 дня, M = 7 дней, P = 18 дней (с учётом возможных проблем с API и сертификатами). E = (4 + 28 + 18) / 6 = 8,3 дня. Разница с «голой» оценкой составляет 18%, и эта разница — ваш скрытый риск.

Planning Poker (Scrum-оценка)

Команда из 4–7 разработчиков оценивает задачу картами из набора Фибоначчи (1, 2, 3, 5, 8, 13, 21). Если оценки расходятся больше чем на 2 порядка, проводится обсуждение и повторная оценка. Метод снижает эффект якоря и вынуждает команду договариваться о границах задачи. По данным исследования VersionOne State of Agile Report 2023, Planning Poker используют 58% Agile-команд и снижают погрешность оценки на 30–40%.

Декомпозиция Work Breakdown Structure (WBS)

Попросите подрядчика предоставить иерархическую структуру работ с уровнем декомпозиции не крупнее 8–16 часов. Если минимальная задача в графике занимает «2 недели» — это признак недостаточной проработки. В качественном графике для проекта длительностью 6 месяцев должно быть минимум 200–300 задач.

Анализ velocity по предыдущим проектам

Запросите у подрядчика статистику velocity (количество story points за спринт) за последние 3–5 проектов аналогичной сложности. Если velocity составляет, например, 35 SP за 2-недельный спринт, а в новом проекте запланировано 600 SP, минимальный срок составит 600 / 35 × 2 = 34 недели, или около 8 месяцев. Любое существенное отклонение в меньшую сторону — повод задать вопросы.

Метод широкополосного дельфи (Wideband Delphi)

Экспертная оценка несколькими специалистами анонимно с последующей статистической обработкой. Используется для высокорисковых задач, где исторические данные отсутствуют. Даёт более точную оценку, чем индивидуальная, при условии участия минимум 3 экспертов.

Критерии проверки плана-графика на скрытые риски

Готовый график нужно анализировать по контрольному списку, который ловит 80% типичных просчётов. Ниже — параметры, которые проверяются до подписания договора.

Таблица проверки

Дополнительные критерии

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

Верификация эстимейтов через референсы. Свяжитесь с 2–3 бывшими заказчиками подрядчика и уточните три вопроса: уложились ли они в сроки, какое превышение было по факту, менялся ли состав команды в ходе проекта. По данным PM Solutions 2023, 67% заказчиков не проводят reference check, хотя это самый надёжный способ выявить системные проблемы подрядчика.

Проверка методологии управления. Уточните, какие инструменты используются для трекинга задач (Jira, Asana, YouTrack), как часто проводятся демо, есть ли доступ заказчика к дашборду проекта в реальном времени. Отсутствие доступа к трекеру — повод отказаться от сотрудничества.

Юридические формулировки для защиты дедлайнов в договоре

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

1. Детальное приложение с этапами и сроками

График выносится в Приложение №1 к договору с указанием:

• Номера и названия этапа (например, «Этап 3. Разработка модуля авторизации»).

• Даты начала и завершения этапа.

• Перечня deliverables (результатов): исходный код, развёрнутая тестовая среда, протоколы тестирования, документация.

• Критериев приёмки (acceptance criteria) в измеримой форме.

Формулировка: *«Срок выполнения Этапа 3 — не позднее 30.11.2024. Результатом этапа является развёрнутый на тестовом стенде модуль авторизации, прошедший smoke-тестирование по чек-листу из Приложения №3. Приёмка оформляется Актом сдачи-приёмки в течение 5 рабочих дней с момента получения уведомления о готовности»*.

2. Право на удержание оплаты

В договоре фиксируется, что оплата каждого этапа происходит после подписания акта приёмки. Размер удержания на период гарантийного срока — 10–20% от стоимости этапа.

Формулировка: *«Заказчик удерживает 15% от стоимости Этапа 3 на срок гарантийного обслуживания (90 календарных дней с даты подписания Акта). Удержанная сумма выплачивается в течение 10 рабочих дней после истечения гарантийного срока при отсутствии критических дефектов»*.

3. Неустойка за нарушение сроков

Пеня за каждый день просрочки — 0,1–0,5% от стоимости этапа, но не более 10–15% от общей стоимости. Верхний предел важен, иначе суд может снизить неустойку по ст. 333 ГК РФ.

Формулировка: *«В случае нарушения Подрядчиком сроков выполнения Этапа 3 более чем на 5 рабочих дней Заказчик вправе начислить пеню в размере 0,2% от стоимости Этапа 3 за каждый день просрочки, но не более 10% от стоимости Этапа»*.

4. Право на расторжение и возврат средств

Если просрочка этапа превышает 20–30 дней или совокупная задержка проекта превышает 30%, заказчик получает право расторгнуть договор с возвратом оплаты за невыполненные работы.

Формулировка: *«При задержке выполнения любого из этапов более чем на 30 календарных дней Заказчик вправе отказаться от исполнения договора в одностороннем порядке и потребовать возврата оплаты за фактически не выполненные работы в течение 15 рабочих дней»*.

5. Соглашение об изменении сроков (Change Request)

Любое изменение сроков оформляется дополнительным соглашением, подписанным обеими сторонами. Устные договорённости юридической силы не имеют.

Формулировка: *«Изменение сроков выполнения этапов допускается только по соглашению сторон, оформленному в письменной форме. Основанием является Change Request, согласованный уполномоченными представителями сторон»*.

6. SLA на исправление дефектов

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

Формулировка: *«Критические дефекты (блокирующие работу системы) устраняются в течение 4 часов с момента уведомления. Дефекты средней значимости — в течение 3 рабочих дней. Некритические дефекты — в течение 10 рабочих дней»*.

7. Право на привлечение третьих лиц для завершения работ

Если подрядчик систематически срывает сроки и не предпринимает мер по ускорению, заказчик должен иметь право привлечь другого подрядчика за счёт первоначального.

Формулировка: *«В случае нарушения Подрядчиком сроков более чем на 20 календарных дней Заказчик вправе привлечь третьих лиц для завершения работ, а расходы на их привлечение отнести на счёт Подрядчика в пределах стоимости невыполненных работ»*.

Когда стоит отказаться от предложенного графика

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

Сценарий 1: Подрядчик отказывается от этапной приёмки

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

Сценарий 2: В графике отсутствует аналитика и проектирование

Часто подрядчики пропускают этап discovery или сокращают его до 1 недели на проекте длительностью 6–12 месяцев. По оценке McKinsey 2022, недостаточное время на аналитику увеличивает срок проекта в среднем на 25% из-за переделок. Минимальная длительность discovery-фазы — 3–6 недель для проекта средней сложности.

Сценарий 3: Не учтено время на интеграции

Если проект предполагает интеграцию с 3+ внешними системами (CRM, ERP, платёжные системы, государственные реестры), на каждую интеграцию нужно закладывать 2–4 недели с учётом получения API-ключей, тестовых сред, согласования форматов данных. Если в графике эти задачи отсутствуют — график нереалистичен.

Сценарий 4: Подрядчик не предоставляет информацию о команде

Невозможно оценить выполнимость графика, если неизвестно, кто именно будет работать над проектом. Если подрядчик скрывает состав команды или указывает «5 разработчиков» без имён, опыта и ролей, есть риск замены ключевых специалистов в первые месяцы работы. Это прямой путь к потере velocity на 40–50%.

Сценарий 5: Фиксированная цена без детальной сметы

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

Что может пойти не так после подписания

• Scope creep: заказчик добавляет требования, команда перегружается, сроки сдвигаются.

• Замена senior на junior: после 2–3 месяцев выясняется, что ключевые разработчики переведены на другой проект.

• Технический долг: ради соблюдения сроков подрядчик пишет код низкого качества, и через 3–4 месяца команда тонет в багах.

• Скрытые дефекты в архитектуре: без code review и архитектурного надзора выявляются проблемы, требующие переписывания 30–50% кода.

• Конфликт при приёмке: подрядчик считает работу выполненной, заказчик — нет, и формальные критерии приёмки отсутствуют.

Какой процент буфера на риски считается нормальным?

Оптимальный буфер — 20–30% от трудоёмкости критической цепи проекта. Для высокорисковых проектов (интеграции с государственными системами, fintech, новые технологии без отработанной практики) буфер увеличивается до 40–50%. Буфер менее 15% — признак того, что подрядчик экономит на рисках и переложит их заказчику через scope creep.

Что делать, если подрядчик называет сроки в 2–3 раза меньше рыночных?

Это классический признак демпинга для выигрыша тендера. Запросите детальную смету с декомпозицией задач и сравните с оценками 2–3 других подрядчиков. Если расхождение больше 30%, попросите референс-контакты и уточните, какие именно компромиссы были сделаны по scope. Часто «короткий срок» означает отказ от тестирования, документации, code review — и это выяснится уже в процессе.

Можно ли зафиксировать в договоре сроки по каждой задаче, а не по этапам?

Юридически — да, но это создаёт избыточную нагрузку на управление договором. Любое изменение в плане потребует дополнительного соглашения. Оптимальный подход — фиксировать в договоре сроки этапов и ключевых milestone, а детальный трекинг задач вести в Jira/Asana с еженедельной отчётностью.

Как считать неустойку, если подрядчик задерживает и приёмку, и устранение дефектов?

В договоре прописываются два отдельных потока: пеня за просрочку этапа (начисляется до подписания акта) и SLA-штрафы за нарушение сроков исправления дефектов (начисляются после приёмки). Совокупный лимит штрафов обычно ограничивается 10–20% от стоимости договора, чтобы не превращать проект в источник споров.

Что такое velocity и как его проверить у подрядчика?

Velocity — это среднее количество story points, которое команда выполняет за спринт. Запросите у подрядчика статистику за последние 3–5 проектов: сколько спринтов длился проект, какой был средний velocity, как менялся от спринта к спринту. Если velocity в новом проекте заложен выше исторического среднего без объективных причин (например, выделенная команда без параллельных проектов), график нереалистичен.

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

Каждое такое изменение требует оформления Change Request с указанием причин, влияния на сроки и стоимость, и подписания дополнительного соглашения. Если сдвиги происходят регулярно (чаще 1 раза в 2 месяца), проведите ретроспективу: выявите корневые проблемы, пересмотрите план и при необходимости активируйте пункт договора о привлечении третьих лиц.

Нужен ли независимый технический эксперт для проверки графика?

Для проектов стоимостью от 3–5 млн рублей и длительностью от 6 месяцев — да, это окупается. Стоимость независимого аудита графика и оценки рисков — 50–150 тыс. рублей, что составляет 1–3% от бюджета проекта. Эксперт проведёт декомпозицию, проверит оценки и выявит нереалистичные допущения до старта работ.

Можно ли доверять графику от внутренней команды заказчика?

Нет, если только у заказчика нет выделенного PMO (Project Management Office) с накопленной статистикой по проектам. Внутренние оценки часто делаются с теми же ошибками, что и внешние: усреднение, отсутствие декомпозиции, занижение рисков. Применяйте те же критерии проверки и к внутренним графикам.

Что важнее — T&M (time and materials) или фиксированная цена?

Для проектов с высокой неопределённостью (новые продукты, R&D, сложные интеграции) — T&M с cap (потолком стоимости) и прозрачной отчётностью по затраченному времени. Для проектов с чётко описанным scope — фиксированная цена с детальной сметой. Смешанная модель (fixed price на этапы, T&M на исследования) — компромисс для гибридных проектов. Ключевой фактор — наличие детальной сметы, а не формат ценообразования.

Как минимизировать риск внезапной замены команды подрядчиком?

Включите в договор пункт: «Замена ключевых специалистов (Senior Backend, Tech Lead, PM) допускается только с письменного согласия Заказчика. Заказчик вправе отклонить кандидатуру при её квалификации ниже заменяемого специалиста». Также фиксируйте в приложении к договору состав команды с указанием ФИО, роли, опыта — это создаёт юридическое обязательство.