Договор на внедрение проверяется за полтора часа, если читать его не подряд, а по списку. Подряд читать бессмысленно: из 14–16 разделов исход разговора с подрядчиком определяют примерно шесть, и они разбросаны по документу так, что связь между ними видна только если знать, что искать.
Ниже — 22 пункта в трёх блоках. Формат рассчитан на владельца, который проверяет договор сам перед встречей, а не на юридическую экспертизу: у каждого пункта есть признак, по которому видно, что дело плохо, и отметка, идёт ли вопрос юристу. Таких отметок шесть. Мы инженерное бюро, а не юридическая фирма, и на этих шести пунктах мы прямо останавливаемся.
Отдельно оговорим границу: чек-лист проверяет текст договора, а не подрядчика. Компетенция команды, реалистичность сроков и способность довести проект до эксплуатации проверяются другим списком — он собран в материале о проверке подрядчика. Идеальный договор с командой, которая не справится, — обычная и дорогая ситуация.
Как устроен один пункт
Каждая строка списка — это вопрос, на который есть три ответа: есть, нет и переписать. Третий вариант нужен чаще двух первых: обычно нужный пункт в договоре присутствует, но сформулирован так, что не работает. «Работы принимаются в порядке, согласованном Сторонами» — это не отсутствие приёмки, это приёмка, которой нет.
Быстрый способ проходить блок — три вопроса к каждому разделу вместо чтения всех абзацев: что здесь измеряется числом, что произойдёт, если сторона это нарушит, и можно ли по этому тексту понять, выполнена работа или нет. Раздел, в котором нет ни одного числа и ни одного последствия, читать дальше не нужно — его надо переписывать целиком.
Список удобнее всего распечатать на одном листе с тремя колонками пустых клеток и проходить карандашом. На переговорах это работает лучше, чем присланные замечания: вы не спорите, а зачитываете пункт и спрашиваете, где он в тексте. Подрядчик, у которого всё в порядке, отвечает номером раздела за десять секунд; подрядчик, у которого не в порядке, начинает объяснять, что «на практике так не делают». Второй ответ информативнее первого.
Схема из трёх вертикальных колонок-блоков. Блок А «Предмет, ТЗ и сроки — пункты 1–8», блок Б «Деньги, приёмка, гарантия — пункты 9–16», блок В «Права, доступы, данные, выход — пункты 17–22». Внутри каждого блока — ряд пронумерованных строк-клеток; клетки 8, 15, 16, 17, 18 и 21–22 выделены штриховкой и вынесены вправо в отдельный список с заголовком «к юристу — 6 вопросов». Сверху над схемой подпись «1,5 часа чтения», справа над списком юриста — «2,5 часа × 4 500 ₽». Чертёжный стиль, подписи по-русски.
Блок А. Предмет, ТЗ и сроки: пункты 1–8
Первый блок отвечает на вопрос «что и к какому сроку». Если он провален, остальные четырнадцать пунктов не спасают: приёмка не может быть строже, чем описание предмета, а неустойка не начисляется за нарушение срока, которого нет.
| № и что проверяем | Плохо, если | К юристу |
|---|---|---|
| 1. Предмет описан через результат и ссылается на приложение | «Разработка системы учёта» без номера и даты приложения | Нет |
| 2. ТЗ приложено, подписано обеими сторонами, есть номер, дата и версия | ТЗ живёт по ссылке на редактируемый облачный документ | Нет |
| 3. Приложения названы неотъемлемой частью договора | Приложения упомянуты, но их статус не определён | Нет |
| 4. Календарный план отдельным приложением, у каждого этапа свой срок | Один срок «5 месяцев» на весь договор | Нет |
| 5. Срок этапа течёт с даты предоставления доступов и данных по перечню | Срок считается от подписания договора независимо ни от чего | Нет |
| 6. Расчётные объёмы записаны числами: заявок в день, документов в месяц, пользователей | Объёмы не названы вовсе — граница ответственности отсутствует | Нет |
| 7. Порядок изменения объёма: допсоглашение с оценкой в часах и новой датой | «Изменения согласовываются Сторонами в рабочем порядке» | Нет |
| 8. Привлечение соисполнителей: с уведомлением и переносом на них обязательств | «Исполнитель вправе привлекать третьих лиц» без всяких условий | Да |
Пункты 5 и 6 пропускают чаще остальных, а стоят они дороже прочих в этом блоке. Пятый защищает подрядчика — и именно поэтому его наличие говорит о зрелости команды: тот, кто про него помнит, обычно помнит и про приёмочные сценарии. Шестой защищает обе стороны: числа в ТЗ одновременно и обязательство исполнителя, и граница, за которой начинается новая работа. Подробный разбор всех разделов с пометкой «несущий или декорация» — в опорном материале о существенных условиях договора на внедрение.
Блок Б. Деньги, приёмка, гарантия: пункты 9–16
Второй блок отвечает на вопрос «когда платим и как понимаем, что работа сделана». Здесь живёт большинство реальных конфликтов, потому что здесь сталкиваются два разных интереса: подрядчику нужен предсказуемый денежный поток, заказчику — предсказуемый результат.
| № и что проверяем | Плохо, если | К юристу |
|---|---|---|
| 9. Цена разложена по этапам, а цена этапа — по отдельным результатам | Одна сумма на весь договор без разбивки | Нет |
| 10. Платёж привязан к подписанию акта этапа, а не к календарной дате | «Оплата производится по факту на основании счёта» | Нет |
| 11. Аванс считается от цены этапа и не превышает 30–50 % от неё | Аванс 50 % от цены всего договора | Нет |
| 12. Срок проверки 5–10 рабочих дней, отсчёт от передачи полного комплекта | Два рабочих дня с даты письма «мы всё сделали» | Нет |
| 13. Есть перечень приёмочных сценариев с числовыми критериями | «Работы должны соответствовать техническому заданию» и больше ничего | Нет |
| 14. Замечания разделены на классы, у каждого свой срок устранения | Один общий «разумный срок» на любые недостатки | Нет |
| 15. Гарантия: срок, момент начала отсчёта, срок реакции и срок устранения | 30 календарных дней с даты акта и «разумный срок» на починку | Да |
| 16. Потолок ответственности не ниже цены этапа, есть исключения из него | Ответственность ограничена 5 % цены договора без исключений | Да |
Тринадцатый пункт — самый дорогой в списке. Именно он превратился в 691 000 ₽ убытка на модельном проекте, где интеграция с 1С:УТ была описана фразой «настройка обмена данными с учётной системой Заказчика». Как превращать требование ТЗ в проверяемый критерий, разобрано в материале о поэтапной приёмке; там же — рабочие сроки для классов замечаний из четырнадцатого пункта.
Два столбца на общей рублёвой шкале. Левый узкий столбец «Проверка — 30 000 ₽» из трёх сегментов: «собственник 1,5 ч × 2 500 ₽ = 3 750 ₽», «юрист 2,5 ч × 4 500 ₽ = 11 250 ₽», «инженер 6 ч × 2 500 ₽ = 15 000 ₽». Правый высокий столбец «Три пропуска — 1 199 000 ₽» из трёх сегментов: «критерий приёмки 691 000 ₽», «доступы на подрядчике 124 000 ₽», «нет пункта о выходе 384 000 ₽». Между столбцами выноска «отношение 1 к 40», внизу подпись «модельный проект 2 400 000 ₽». Чертёжный стиль, подписи по-русски.
Блок В. Права, доступы, данные, выход: пункты 17–22
Третий блок отвечает на вопрос «что останется у вас, когда проект закончится или оборвётся». Его проверяют реже всего, потому что на старте кажется, что до этого далеко. Четыре из шести пунктов здесь помечены как вопросы юристу.
| № и что проверяем | Плохо, если | К юристу |
|---|---|---|
| 17. Исключительное право переходит заказчику с даты акта этапа | «Исполнитель предоставляет неисключительную лицензию» | Да |
| 18. Есть право перерабатывать программу, в том числе силами третьих лиц | Право упомянуто без переработки — менять код нельзя | Да |
| 19. Перечень сторонних компонентов приложением: библиотеки, платные модули, платформа | Перечня нет, состав зависимостей выясняется после сдачи | Нет |
| 20. Перечень доступов приложением, передача — условие акта финального этапа | Доступы не упомянуты в договоре вообще | Нет |
| 21. Поручение обработки персональных данных оформлено до выдачи первого доступа | Есть только строка «Стороны соблюдают требования 152-ФЗ» | Да |
| 22. Пункт о прекращении работ: срок, передача незавершённого, методика расчёта | Пункта нет, есть только общая ссылка на законодательство | Да |
Пункты 17 и 18 идут юристу одним вопросом — про конструкцию прав целиком: отчуждение это или лицензия, что именно вы получаете и можно ли это менять. Поэтому отметок в таблицах семь, а вопросов к юристу шесть. Разбор самой конструкции — в материале о том, кому принадлежит исходный код, перечень из двенадцати позиций для двадцатого пункта — в материале о передаче доступов.
Пять красных флагов
Есть пять формулировок, при виде которых проверку можно не продолжать: договор возвращается на переработку целиком. Не потому, что подрядчик злодей, а потому, что такой текст не описывает работу, а описывает намерение её обсудить.
- 1Предмет одной строкой без отсылки к приложению. Под «разработку системы учёта» подходит и полноценный контур, и три экрана с формой. Дальше любая приёмка будет спором о вкусах.
- 2Один срок на весь договор. Пять месяцев без промежуточных точек означают, что отставание вы увидите на последней неделе, когда сделать уже ничего нельзя.
- 3Приёмка «в порядке, согласованном Сторонами». Порядок, который согласуют в момент спора, не согласуют никогда. То же относится к «работы принимаются по усмотрению Заказчика»: это зеркальная ловушка, и подрядчик от неё страдает не меньше.
- 4Потолок ответственности 5 % цены договора. На проекте в 2 400 000 ₽ это 120 000 ₽ на все случаи жизни. Неустойка внутри такого потолка становится декоративной: нарушать выгоднее, чем исполнять.
- 5Неисключительная лицензия вместо перехода права. Вы получаете право пользоваться собственной системой, а не саму систему. Отдельно проверьте, есть ли право на переработку: без него код формально ваш, а менять его нельзя.
Все пять формулировок встречаются в договорах вполне добросовестных команд: их туда положил шаблон, скачанный однажды и с тех пор не пересматривавшийся. Диагностическим является не наличие флага, а реакция на просьбу его убрать. Отказ обсуждать даже симметричную правку — это уже про подрядчика, а не про текст.
Протокол разногласий: три формулировки
Найденные проблемы оформляются протоколом разногласий, который подписывается вместе с договором и становится его частью. Практическое правило: три правки проходят почти всегда, десять не проходят почти никогда — из десяти получается новый раунд согласования на две недели. Поэтому выбирают самые дорогие.
- 1Правка 1. Права на результат вместе с правом на переработку
Было: «Исполнитель предоставляет Заказчику право использования результата работ». Стало: «Исключительное право на созданную программу и на входящую в её состав документацию переходит к Заказчику в полном объёме с даты подписания акта соответствующего этапа. Заказчик вправе перерабатывать программу, в том числе силами третьих лиц, без дополнительного согласия Исполнителя и без выплаты дополнительного вознаграждения.»
- 2Правка 2. Передача доступов как условие подписания акта
Было: «По окончании работ Исполнитель передаёт Заказчику необходимые доступы». Стало: «Передача учётных записей и ключей доступа по перечню Приложения № 4 является условием подписания акта финального этапа. Акт не подписывается до подтверждения Заказчиком самостоятельного входа под собственной учётной записью с правами администратора по каждой позиции перечня.»
- 3Правка 3. Порядок прекращения работ
Было: пункта нет. Стало: «Заказчик вправе в любое время до подписания акта последнего этапа отказаться от исполнения Договора, направив письменное уведомление; Договор прекращается через 10 рабочих дней с даты его получения. Исполнитель передаёт результат незавершённого этапа в состоянии «как есть». Стоимость фактически выполненных работ равна сумме цен результатов календарного плана, переданных Заказчику. Исполнитель не вправе удерживать результат работ, код, доступы и данные Заказчика в связи с разногласиями по расчётам.» Зачем нужен каждый абзац — в материале о расторжении договора на разработку.
Семь пунктов, если проект до 300 000 ₽
На маленьком проекте полный список избыточен: согласование двадцати двух пунктов обойдётся дороже предмета спора. Здесь работает другая логика — не выиграть спор, а сделать так, чтобы максимальный убыток был меньше аванса одного этапа, то есть 30 000–50 000 ₽.
- Пункт 1 — предмет ссылается на приложение с описанием работы.
- Пункт 2 — это приложение подписано обеими сторонами, у него есть дата.
- Пункт 4 — работа разбита минимум на два-три этапа со своими сроками.
- Пункт 10 — платёж привязан к акту этапа, а не к календарной дате.
- Пункт 13 — есть хотя бы короткий перечень проверок с числами: что должно работать и на скольких примерах.
- Пункт 20 — доступы и репозиторий с первого дня на вашей стороне, подрядчик приглашён.
- Пункт 22 — можно прекратить работу с оплатой сделанного и забрать результат.
Юрист на таком проекте обычно не окупается: два часа его времени — это 9 000 ₽, то есть 3 % бюджета в 300 000 ₽, и при этом взыскивать по такому договору всё равно невыгодно. Договорные конструкции под три разных бюджета сведены в таблицу в опорном материале кластера — там же видно, с какой суммы имеет смысл усложнять.
Сравнение в две колонки. Левая «Проект от 500 000 ₽ — 22 пункта»: три сгруппированных блока по 8, 8 и 6 строк, подпись внизу «проверка 30 000 ₽, 1,25 % бюджета». Правая «Проект до 300 000 ₽ — 7 пунктов»: семь строк с номерами 1, 2, 4, 10, 13, 20, 22, подпись внизу «максимальный убыток — аванс одного этапа, 30 000–50 000 ₽». Между колонками вертикальная подпись «выиграть спор — ограничить убыток». Чертёжный стиль, подписи по-русски.
Что чек-лист не ловит
Честная граница инструмента. Договор, прошедший все 22 пункта, не гарантирует ничего из перечисленного ниже — и это не недостаток списка, а разделение труда.
- Способность подрядчика сделать работу. Текст договора о компетенции не говорит. Для неё существует отдельный список из двадцати четырёх вопросов — чек-лист проверки подрядчика.
- Реалистичность оценки. Срок в 8 недель на работу, которая занимает 20, проходит все 22 пункта: этапы есть, сроки есть, критерии есть. Проверяется это не чтением, а разговором о том, из чего сложилась оценка.
- Качество самого ТЗ. Подписанное приложение с датой и версией может при этом описывать не тот процесс. Чек-лист проверяет форму документа, а не его содержание.
- Готовность вашей стороны. Данные, доступы, назначенный владелец процесса и человек, который принимает решения за два дня, а не за месяц. Половина срывов начинается здесь, и ни один пункт договора это не чинит.
- Гарантию, что спора не будет. Он просто будет коротким и об одном: соответствует система записанному критерию или нет. Как устроен гарантийный раздел, разбирает материал о гарантийном сроке на разработку.
Хороший договор не защищает от плохого подрядчика. Он делает так, что плохой подрядчик становится виден на втором этапе, а не на последнем.
