При обсуждении стоимости проекта по разработке заказного программного обеспечения стороны А и Б чаще всего согласовывают единицу измерения —«Человек-небо»: Сколько инженеров, сколько дней работы, какая единичная цена. Эта модель работает лишь при стабильных требованиях и чётко определённых границах поставки; как только правила на месте начинают часто меняться, инструменты ИИ повышают эффективность кодирования, а заказчик по‑прежнему проводит приёмку по принципу «наращивания штата», возникает конфликт — подрядчик считает, что требования разрастаются, а заказчик полагает: «Сотрудников добавили, а результата — нет».
Политический сигнал: от продажи персонала к продаже результатов
В сентябре 2026 года Министерство промышленности и информатизации КНР опубликовало «План реализации специальной программы „Искусственный интеллект + программное обеспечение“», в котором неоднократно говорится о содействии трансформации моделей производства программного обеспечения, развитии сервисов «Модель как услуга» и «Интеллектуальный агент как услуга», а также обозначено, что к 2028 году в ключевых отраслях должны быть созданы образцовые приложения программного обеспечения на основе интеллектуальных агентов. Документ не отвергает заказную разработку, но чётко указывает направление:Оценивая ценность программного обеспечения, всё чаще обращают внимание на практическую эффективность, а не только на затраченные человеко‑дни.。
Для компаний, внедряющих ERP, MES, CRM и отраслевые системы управления, это означает, что если в договоре по‑прежнему указывается лишь «XX человек × XX дней», после запуска проекта легко возникнет ситуация, когда «код написан, а бизнес им не пользуется». Более устойчивый подход — разбить поставку наПриемлемые бизнес-результаты。
Бизнес‑логика: маркеры выполнения должны быть более конкретными, чем человеко‑дни.
Переведите проект из режима «платежи по этапам» в режим «платежи по ключевым этапам»; каждый ключевой этап должен одновременно соответствовать четырём условиям:
- Бизнес‑сценарий: Кто использует, какие операции решает (например, «сканирование штрих‑кода сотрудником склада для приёма на склад» вместо «завершение модуля приёма на склад»).
- Концепция данных: Какие основные данные, поля состояния и диапазоны прав доступа задействованы, каковы правила выборки.
- Скрипт приёмки: На основе предоставленных тестовых данных — какие процессы будут пройдены и какие документы или отчёты будут сформированы.
- Обработка исключений: Как система сообщает о сбое, кто имеет право вносить изменения и сохраняется ли след в системе.
Метка не должна превышать2–4 неделиОдин; слишком длинный — и снова вернётся к «разработке в чёрном ящике». Типичный пример разделения: основные данные и права доступа → замкнутый цикл ключевых документов → отчёты и сверка → интерфейсы и переход на эксплуатацию.
Логика проектирования: область, изменения и «интеллектуальная помощь» включены в договор
Использование ИИ для помощи в программировании, автоматическое создание тестовых сценариев и интеллектуальное дополнение документации изменят затраты человеко‑дней на выполнение тех же задач, ноНе автоматически изменяет сложность бизнеса. В договоре и спецификации требований предлагается выделить отдельным пунктом:
- Базовый уровень (Baseline): Список функций + перечень задач, не входящих в сферу охвата (Out of Scope); любые изменения должны оформляться посредством заявки на изменение.
- Изменение правил ценообразования: Новые этапы оцениваются по принципу «сценарий + скрипт приемки», а не по временно добавленным человеко‑дням.
- Интеллектуальная вспомогательная граница: На каких этапах можно повысить эффективность с помощью ИИ (генерация кода, черновики документов), а какие требуют ручного подписания (безопасность, соблюдение нормативных требований, внешние обязательства).
- Принадлежность накопленных знаний: Кто владеет процессными документами, конфигурациями и скриптами, чтобы избежать разрыва в эксплуатации после сдачи.
Разработка и внедрение: автоматизация приёмки и наблюдаемость
Чтобы сделать «ориентацию на результат» реализуемой, техническая сторона должна обеспечить три вещи:
- Ввод в базу тестовых случаев приемки: Каждая веха соответствует набору автоматизированных или полуавтоматизированных тестовых сценариев, которые можно повторно запускать при регрессионном тестировании.
- Окружение и изоляция данных: Данные среды UAT можно сбросить, чтобы избежать ситуации, когда «работает только в демонстрационной среде».
- Наблюдаемые журналы: Для ключевых операций ведётся журнал аудита, что позволяет при возникновении споров отследить, кто и что изменил.
Если проект включает интеллектуального агента или движок правил, приёмка должна быть дополненаМеханизм выборочной проверки: Случайно вводятся граничные сценарии, проверяется, соответствуют ли отказ в ответе, перевод на человеческую поддержку и блокировка по правам доступа заданным требованиям дизайна, а не просто убеждаемся, что «можно общаться».
Три распространённые категории споров и меры их предотвращения
Спор первый: «Все функции уже реализованы, почему же бизнес их не использует?»——Профилактика: привязка ключевых этапов к должностным обязанностям и регистрация на тренингах; при приёмке — обход объекта на месте, а не только демонстрация PPT.
Спор второй: «Почему за добавление небольшой функции нужно платить дополнительно?»——Профилактика: в изменении указываются затронутые ключевые этапы, скрипты и сроки выполнения; разработка начинается только после подписания документа обеими сторонами.
Спор третий: «AI повысил эффективность — можно ли сократить штат?»— Профилактика: в договоре разделяются «реальные затраты» и «сложность бизнес‑процессов»; повышение эффективности может отражаться в общей стоимости или сроке, но стандарты приемки не снижаются.
Рекомендация по пилотному проекту: начать с одного замкнутого модуля
Не нужно ждать, пока вся система будет переписана. Выберите один.2–3 недели для замкнутого цикламодули (например, приём‑отпуск товаров, учёт выполнения работ по нарядам, утверждение расходов), используя новый шаблон, подписывают дополнительное соглашение: указывают сценарии, скрипты, исключения и этапы оплаты. После проверки корректности внедряют во все проекты. Оценивают успех по…Снижает ли изменение заказа время разбирательств?、Повысился ли уровень прохождения UAT с первого раза?, а не смотреть, насколько меньше стороной Б указала человеко‑дней.
Человеческий труд не исчезнет в одночасье, но он превращается из «единственного объекта ценообразования» в «ориентир для оценки затрат». Включение в контракт ключевых этапов и скриптов приёмки — это базовый навык, позволяющий кастомизированному программному обеспечению и в условиях сочетания «искусственный интеллект + ПО» по‑прежнему предоставлять надёжные результаты.
Совместная работа с фиксированной общей стоимостью и гибкими итерациями
Приёмка по этапам не исключает гибкость: каждый спринт по‑прежнему может предоставлять демонстрируемый прирост, ноОплата и официальная приемкаЗакреплён на более крупном этапе. В договорах с фиксированной общей стоимостью особенно важно чётко прописать «точку заморозки объёма» — после какого именно согласования добавление новых требований должно оформляться через изменения, чтобы избежать устного внесения функционала. Для модулей, включающих интеллектуальных агентов, рекомендуется проводить отдельную приёмку по этапу, оценивая «версию правил + процент прохождения выборочной проверки», не связывая это с общим запуском всего сайта по единому подходу.
Отраслевые данные показывают, что около … проектов программного обеспечения заканчиваются неудачей.ТретьЭто обусловлено неясностью требований и критериев приёмки, а не самой технической реализацией. Сначала прописать в договоре, что именно считается завершённым — гораздо важнее, чем спорить о том, сколько программистов заменил ИИ. В следующий раз на этапе рассмотрения проекта можно сначала задать вопрос: если завтра вся команда подрядчика уедет в отпуск, сможем ли мы по скриптам определить, соответствует ли текущий этап установленным требованиям? Если ответить не получится, значит, условия приёмки ещё недостаточно чётко прописаны.