Проверка совместимости проекта: кто несет ответственность?

Проверка на совместимость.

Долго ли, коротко ли, подошел красивый проект к логической точки релиза. И тут - ой. Новый функционал не совместим (со старым, с интеграциями, с реальными данными и т.п.). Кто виноват и что делать?

Сюрприз - чаще всего в таких случаях ответственность после долгих разбирательств со скрипом принимает на себя заказчик. И вот почему:

1️⃣Юридически — в договоре / техническом задании не прописано, что ответственность за совместимость несет подрядчик. А значит - "мы написали что хотели, а вам не подошло - так это вы до нас что-то не донесли/криво". Знакомо же, да?

Формулировка в договоре, которая должна быть, если вы хотите на старте обозначить границы:

Исполнитель обязуется до начала производства/разработки проверить совместимость всех используемых компонентов (материалов, комплектующих, кода, библиотек, API, версий окружений и т.п.) с проектом Заказчика. Исполнитель несёт полную ответственность за последствия, вызванные несоответствием или несовместимостью таких компонентов, если иное не согласовано в письменной форме с Заказчиком до начала работ.

Дополнительно:

🥺 Прописать, что любой новый компонент (что угодно, библиотека, API) должен быть согласован письменно с результатами теста на совместимость.
🥺 Установить штраф или обязанность исправить за свой счёт в случае, если проблема возникла из-за отсутствия проверки.

2️⃣Управленчески — в проектной документации должен быть этот пункт! Даже если в договоре всё прописано, в реальной работе подрядчики любят “забывать” про это. Поэтому в ТЗ или брифе добавляется блок:

Блок “Проверка совместимости”:

Что именно проверяем (для производства: размеры, материал, стандарты; для IT: версии ПО, окружения, API-форматы).
Кто проверяет (имя, должность со стороны подрядчика).
Как фиксируем результат (отчёт, фото, скриншот, тест-кейс).
Критерий: “Согласовано с заказчиком” — только после подтверждения теста.

Будь занудой - не пожалеешь!

3️⃣Операционно — в процессе работы не забывай спрашивать! Чтобы подрядчик реально проверял совместимость, а не только “на бумаге”!

Запрос подтверждения перед закупкой/интеграцией:

✔️“Прошу подтвердить, что выбранный компонент/версия протестирован на совместимость и подходит под наш проект. Пришлите, пожалуйста, результаты проверки.”
✔️Ведение логов/чата согласований — чтобы потом можно было показать: “Я запрашивала, вы подтвердили”.
✔️Визуальное подтверждение — фото, видео, тестовый билд, прототип до запуска массового производства или релиза.

❤️‍🔥Ключевой принцип для клиента: пока подрядчик не подтвердил тест на совместимость письменно (и ты это сохранила), — никаких закупок, интеграций и оплат за этап.

И да, с этим тоже придется учиться работать. +1 привычка в копилку полезных привычек руководителя проекта.

❤️- лайк, если было полезно.
😎- если знаешь что есть Git и умеешь контролировать все на свете, но хоть раз сталкивался с тем, что "пока пилили мы - релизнулись они"

#управлениепроектом #слезыпроджектменеджера