Когда я впервые начал участвовать в IT-проектах, мне казалось, что договор — это просто бумажка, которую надо подписать, чтобы «оформить всё по правилам». Главное — начать работу, обсудить задачи, собрать команду, запустить процесс. А что там в договоре написано… ну, вроде бы всё понятно и так. Заказчик хочет систему, мы её делаем. Всё логично.
С тех пор прошло много проектов. И чем дальше, тем яснее становилось: если договор составлен поверхностно, то вы уже проиграли. Не сегодня, не завтра, но обязательно позже. Когда сроки горят, когда заказчик вдруг заявляет: «А разве это не входит в стоимость?», когда выясняется, что под «интеграцией с CRM» он понимал совсем не то, что вы. И вот вы уже не команда и клиент, а две стороны, которые спорят о том, кто что имел в виду полгода назад.
Многие руководители проектов до сих пор относятся к договору как к формальности. Пишут общие фразы вроде «разработка программного обеспечения по требованиям заказчика» или «поставка IT-решения». Звучит неплохо, но ничего не значит. Это не описание проекта, а заголовок. А внутри — пустота. И в эту пустоту потом влезает всё: недопонимание, претензии, задержки, убытки.
Если тема договоров и «как всё зашить в бумагу так, чтобы потом не воевать на проекте» вам откликается, заглядывайте в наш Telegram-канал — там регулярно разбираем реальные кейсы по договорам, SLA и зоне ответственности в ИТ-проектах. А на курсе «Школа руководителя проекта» отдельно проходим, как увязать договор, ТЗ, объём работ и приёмку так, чтобы контракт действительно стал фундаментом проекта, а не формальностью. Подробнее на сайте.
Хороший договор — это не юридический ритуал. Это инструмент управления проектом. Он фиксирует не просто обязательства, а границы. Границы того, что вы делаете, и того, что не делаете. Что входит в стоимость, а что будет стоить отдельно. Какие решения принимает заказчик и когда он обязан дать обратную связь. Какие сроки считаются реалистичными, и что происходит, если они срываются не по вашей вине.
Вот, например, часто забывают прописать, кто отвечает за предоставление данных, доступов, согласований. А потом выясняется, что без этих данных работа стоит. А в договоре написано только: «Исполнитель обязуется разработать систему». Кто должен был подготовить тестовые данные? Кто согласовывает дизайн с маркетингом? Кто утверждает техническое задание? Если это не зафиксировано — виноваты будете вы. Потому что «вы же специалисты, должны были всё предусмотреть».
Ещё один частый провал — нечёткое описание результата. «Система должна быть удобной», «интерфейс — современным», «производительность — высокой». Это не требования, а пожелания. Их нельзя проверить, измерить, принять. А договор должен содержать конкретику: какие функции реализуются, в каком виде, по каким критериям будет проходить приёмка. Лучше даже приложить спецификацию или прототипы, и сделать их неотъемлемой частью договора.
Особенно опасны формулировки, которые звучат умно, но на деле — туман. Например: «система должна обеспечивать гибкость масштабирования», «поддерживать высокую отказоустойчивость», «гарантировать соответствие лучшим отраслевым практикам». Звучит солидно, но что это значит на практике? Сколько пользователей должно выдерживать приложение? Какой уровень доступности считается достаточным? Какие именно «практики» имеются в виду? Без чётких метрик и определений такие фразы — не критерии, а повод для спора. Их невозможно обосновать, объяснить или проверить. А значит, при приёмке заказчик всегда сможет сказать: «Нет, это не то, что я имел в виду».
Не менее важен порядок взаимодействия. Кто ваш контакт на стороне заказчика? Как часто проходят встречи? Как согласовываются изменения? Как быстро заказчик обязан отвечать на запросы? Без этого вы зависите от чьего-то графика, настроения или загруженности. А проект не может ждать.
И да, нужно чётко прописывать, что происходит при изменении требований. Потому что они почти всегда меняются. Но если вы не зафиксируете, что каждое изменение — это отдельный запрос, оценка трудозатрат и, возможно, допсоглашение, то рискуете работать бесплатно. Или, что хуже, — терять контроль над сроками и бюджетом.
Некоторые считают, что если отношения с заказчиком доверительные, то «всё и так обсудим». Но доверие — не замена договору. Оно помогает в работе, но не защищает от недопонимания. Особенно когда в проект вовлечены разные люди: технические специалисты, менеджеры, юристы. У всех них разное восприятие. А договор — единая точка отсчёта.
Я не призываю превращать договор в том на 50 страниц. Но даже короткий документ может быть точным, если в нём есть суть: что делаем, как делаем, кто за что отвечает, как принимаем результат и что делать, если что-то пошло не так.
В конце концов, договор — это не столько защита от заказчика, сколько защита самого проекта. Он помогает не сбиться с курса, не тратить время на споры о том, «а кто это обещал», не выгорать от постоянных переделок. Он даёт чёткость. А чёткость — это основа любого успешного IT-проекта.
Так что не спускайте этот этап на тормозах. Не надейтесь, что «обойдётся». Обойдётся, только если вы заранее всё пропишете. Потому что потом уже будет поздно.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
Подробнее о наших курсах — на сайте