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

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

Классический план-график в виде диаграммы Ганта с блоками «Аналитика — 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% кода.
• Конфликт при приёмке: подрядчик считает работу выполненной, заказчик — нет, и формальные критерии приёмки отсутствуют.

Чек-лист перед подписанием договора

Перед тем как поставить подпись под контрактом, пройдите по этому списку. Каждый пункт должен быть закрыт — иначе риск срыва проекта вырастает кратно.

• График разбит на этапы длительностью не более 4 недель каждый
• У каждого этапа есть измеримые deliverables и acceptance criteria
• Минимальная задача в графике — не более 3 рабочих дней
• Буфер на риски составляет 20–30% от критической цепи
• Параллельных задач у одного исполнителя — не более 2
• В графике есть задачи на code review, документацию, деплой
• QA-этап занимает 30–40% от срока разработки
• Указаны ФИО, роли и опыт ключевых участников команды
• Подрядчик предоставил velocity по 3+ предыдущим проектам
• Проведены референс-интервью с 2–3 бывшими заказчиками
• В договоре есть право на удержание 10–20% оплаты этапа
• В договоре есть неустойка за просрочку (0,1–0,5% в день, лимит 10–15%)
• В договоре есть право на расторжение при задержке 20–30 дней
• Все изменения сроков оформляются дополнительным соглашением
• Есть SLA на исправление дефектов с конкретными сроками
• У заказчика есть доступ к трекеру задач (Jira, Asana и т.п.)
• Проводятся еженедельные демо результатов
• В договоре есть пункт о праве привлечения третьих лиц при срыве
• Гарантийный срок на результаты — не менее 90 дней
• Детально описана процедура приёмки и сроки подписания актов