Аутсорсинг разработки экономит деньги ровно до того момента, пока контракт не превращается в спор о том, что считать «готовым». Заказчик ждёт работающую систему, подрядчик – закрытый акт. Разрыв между этими ожиданиями убивает проекты чаще, чем технические ошибки. Контракт должен закрывать этот разрыв заранее: фиксировать измеримые требования, понятную процедуру приёмки и ответственность за качество. Ниже – три блока, без которых не обходится ни один договор на заказную разработку бизнес-систем.

SLA: считаемые цифры вместо обещаний

SLA работает только тогда, когда каждый показатель можно измерить без споров. «Высокая производительность» и «надёжная работа» – это не SLA, а декларация о намерениях. Пишите конкретно: время отклика ключевой операции – не более 2 секунд при 200 одновременных пользователях; доступность в рабочие часы – 99,5%; реакция на критический инцидент – 2 часа, восстановление – 8 часов.

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

Отдельно зафиксируйте границы ответственности. Подрядчик не отвечает за простой, вызванный чужим оборудованием, каналами связи или действиями самого заказчика. Без этого SLA становится односторонним и подрядчик закладывает риски в цену.

Приёмка: критерии до начала работ, а не после

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

Разбивайте приёмку на этапы. Помодульная сдача с промежуточными актами снижает риск: дефект всплывает на своём этапе, а не за неделю до запуска. По каждому этапу заранее опишите тест-кейсы, ожидаемый результат и допустимое число открытых дефектов по категориям. Блокирующие и критические – ноль, иначе акт не подписывается. Незначительные замечания фиксируйте в реестре с плановыми сроками устранения, чтобы они не стопорили оплату завершённого объёма.

Учитывайте среду эксплуатации. Если систему планируют использовать на мобильных устройствах руководителей, проверяйте её в реальных условиях, а не только на стенде. Корпоративные сценарии работы с iPhone мы разбирали в дорожной карте под iPhone 3GS и в обзоре защитных кейсов для корпоративных устройств.

Управление качеством: процесс, а не финальный контроль

Качество нельзя «проверить в конце» – его выстраивают на всём протяжении работ. Закрепите в контракте право заказчика на доступ к промежуточным сборкам, к системе учёта задач и к отчётности по дефектам. Регулярные демонстрации каждые две-три недели дают раннее предупреждение об отклонениях, пока их ещё дёшево исправить.

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

Вывод

Хороший контракт на аутсорсинг – это не толщина юридического текста, а три согласованные вещи: измеримый SLA, поэтапная приёмка с понятными критериями и встроенный в процесс контроль качества. Договоритесь об этом до старта и спор о слове «готово» просто не возникнет.