Введение: почему «80% готовности» — это не ответ

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

Определение процента выполнения работ по IT-договору — это не просто формальность. От этого зависит, когда заказчик заплатит, когда подрядчик получит аванс, а арбитражный суд — повод для иска. Давайте разберёмся, как сделать этот процесс прозрачным, честным и юридически состоятельным.

Почему стандартные методы не работают?

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

По фактическим затратам? Разработчик потратил 500 часов из запланированных 1000 — значит, готовность 50%? Нет. Можно убить месяц на архитектуру, которая в итоге окажется тупиковой, или написать 10 000 строк кода, которые придётся выбросить. Затраты ≠ результат.

По объёму выполненных работ? Сколько написано строк кода? В современной разработке меньше кода часто означает лучшее решение. Да и как взвесить рефакторинг, который убрал 2 000 строк, но сделал систему стабильной?

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

Вывод очевиден: нужен специфический подход, учитывающий природу программирования.

Метод 1: Поэтапная приёмка (Waterfall)

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

Как это работает:

Договор прописывает этапы и их стоимость в процентах от общей суммы:

| Этап                                       | Результат                                             | % от суммы |
| Техническое задание            | Утверждённое ТЗ                               | 10% |
| Проектирование                    | Архитектура и макеты                       | 15% |
| Разработка ядра                    | Рабочий бэкенд                                 | 30% |
| Интеграция и тестирование  | Протоколы испытаний                      | 25% |
| Внедрение и обучение          | Принятая система в эксплуатацию | 20% |

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

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

Когда применять: Когда заказчик точно знает, что ему нужно; в проектах с жёстким регуляторным надзором; при работе с государственными контрактами, где гибкость — не добродетель.

Метод 2: Функциональные точки (Function Point Analysis)

Этот метод пришёл из 1970-х, но до сих пор используется в банках и телекоме. Идея: измерять не строки кода, а функциональность — то, что видит пользователь.

Суть метода:

Аналитик разбивает систему на элементы:
- Внешние входы (формы, кнопки «сохранить»)
- Внешние выходы (отчёты, уведомления)
- Внешние запросы (поиск, фильтры)
- Внутренние логические файлы (таблицы базы данных)
- Внешние интерфейсные файлы (интеграции со сторонними системами)

Каждому элементу присваивается сложность (простой, средний, сложный) и весовой коэффициент. Сумма даёт общее количество функциональных точек.

Пример: Система состоит из 100 функциональных точек. Разработано и протестировано 75. Значит, готовность — 75%.

Преимущества: Независимость от технологии, понятность бизнесу, международный стандарт (ISO/IEC 20926).

Минусы: Требует сертифицированного специалиста для оценки. Не учитывает качество кода, производительность, безопасность. Для микросервисов и AI-решений метод требует адаптации.

Метод 3: User Story Points (Agile/Scrum)

Если ваш договор построен по гибкой методологии — welcome to the world of story points.

Как это работает на практике:

Перед началом спринта команда оценивает каждую пользовательскую историю (user story) в условных единицах — story points. Обычно по шкале Фибоначчи: 1, 2, 3, 5, 8, 13, 21…

«Как пользователь, я хочу авторизоваться через Google, чтобы не запоминать пароль» — 5 story points.
«Как администратор, я хочу видеть дашборд с аналитикой в реальном времени» — 13 story points.

Весь бэклог проекта — скажем, 500 story points. За спринт команда выполняет 50 points. Значит, за 10 спринтов проект будет готов. Выполнено 150 из 500 — готовность 30%.

Почему это честно: Story points отражают сложность + объём + неопределённость, а не просто «часы работы». Команда сама калибрует свою скорость (velocity) — и прогнозы со временем становятся точнее.

Юридическая уловка: В договоре нельзя просто написать «оплата по story points». Нужно привязать к деньгам либо спринты (оплата за итерацию), либо этапы приёмки функционала. Иначе бухгалтерия впадёт в ступор.

Критический момент: Заказчик должен участвовать в приёмке каждого спринта. Иначе получится «готовность по story points» без реально работающего продукта.

Метод 4: Критерии приёмки по чек-листам (Acceptance Criteria)

Самый надёжный способ для юристов и самый трудоёмкий для разработчиков.

Технология:

Каждая фича описывается не абстрактно («сделать личный кабинет»), а через конкретные, проверяемые критерии:

- [ ] Пользователь может зарегистрироваться с email и паролем
- [ ] Пароль должен содержать минимум 8 символов, 1 цифру, 1 заглавную букву
- [ ] После регистрации приходит письмо с подтверждением
- [ ] Ссылка в письме активна 24 часа
- [ ] При повторной регистрации на тот же email выдаётся ошибка «Пользователь уже существует»
- [ ] ...

Процент выполнения = количество пройденных проверок / общее количество проверок × 100.

Почему это работает: Нет места для «я понял по-своему». Критерии однозначны, проверяемы, документируются.

Проблема: Для сложной системы чек-лист может содержать тысячи пунктов. Требует постоянной синхронизации: если меняется требование — меняется и критерий.

Метод 5: Earned Value Management (EVM) для IT

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

Три ключевых показателя:

1. PV (Planned Value) — сколько должны были сделать к этому моменту по плану
2. EV (Earned Value) — сколько фактически «заработали» по выполненным работам
3. AC (Actual Cost) — сколько реально потратили

Формулы:
- Процент выполнения = EV / PV × 100
- Отклонение по стоимости = EV − AC
- Индекс выполнения = EV / AC

Пример: К концу месяца должны были завершить этап на 500 000 ₽ (PV). По факту выполнили работы, оценённые в 400 000 ₽ (EV), но потратили 600 000 ₽ (AC). Процент выполнения — 80%, но проект убыточен.

Для чего нужен EVM показывает не просто «сколько сделано», а «насколько мы вписываемся в бюджет и сроки». Особенно полезен для долгосрочных контрактов с фиксированной ценой.

Что прописать в договоре: практические рекомендации

Неважно, какой метод вы выберете — если он не зафиксирован в договоре, он не работает. Вот чек-лист для юриста:

1. Определите метод оценки прямо в договоре
«Степень готовности работ определяется по методу функциональных точек (FPA) в соответствии с ISO/IEC 20926» — или — «Прогресс оценивается по выполненным user story points, принятым Заказчиком по итогам каждого спринта».

2. Закрепите порядок приёмки
Кто подписывает акт? В течение какого срока? Что считается молчаливым согласием? Как оспорить результаты?

3. Опишите инструменты контроля
Доступ к таск-трекеру (Jira, Trello), репозиторию (GitHub, GitLab), системе мониторинга. Заказчик должен видеть прогресс в реальном времени, а не получать «отчёт на бумажке» раз в квартал.

4. Предусмотрите изменения
IT-проект изменчив по определению. Как пересчитывать проценты при добавлении новых требований? Формула: новый объём / старый объём = корректировка прогресса.

5. Регламентируйте споры
Что делать, если стороны не согласны с процентом готовности? Экспертиза? Арбитраж? Медиация? Лучше договориться заранее, чем судиться потом.

Реальные кейсы: когда проценты стали проблемой

Кейс 1: «Государственный контракт на 50 млн»

Подрядчик отчитался о 90% выполнения по методу фактических затрат. Заказчик провёл аудит и обнаружил: 40% кода — технический долг, который придётся переписывать. Суд признал, что «затраты ≠ результат», и пересчитал готовность по фактически работающим функциям. Итог: 55% вместо 90%, неустойка, уголовное дело о мошенничестве.

Кейс 2: «Стартап и аутсорсер»

Договор на Agile без чётких критериев приёмки. Разработчики отчитывались о «завершённых спринтах», заказчик платил. Через год выяснилось: продукт не масштабируется, архитектура требует полного переписывания. Суд не смог определить процент выполнения — не было объективных критериев. Стороны сошлись на мировой, потеряв время и деньги.

Кейс 3: «Банк и интегратор»

В договоре прописаны функциональные точки, независимый аудитор, чек-листы приёмки. Споры возникали, но решались за 3–5 дней по документам. Проект завершён в срок, хотя и с корректировками бюджета.

Заключение: процент — это не цифра, а договорённость

Определение процента выполнения работ по IT-договору — это не математическая задача, а вопрос доверия и прозрачности. Идеального метода не существует: Waterfall слишком жёсток, Agile слишком гибок, функциональные точки требуют экспертов, а чек-листы — постоянной поддержки.

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

И помните: в IT «почти готово» — это не диагноз, а приговор, если за ним не стоит измеримый результат.