Проверка на совместимость. Долго ли, коротко ли, подошел красивый проект к логической точки релиза. И тут - ой. Новый функционал не совместим (со старым, с интеграциями, с реальными данными и т.п.). Кто виноват и что делать?
Сюрприз - чаще всего в таких случаях ответственность после долгих разбирательств со скрипом принимает на себя заказчик. И вот почему: 1️⃣Юридически — в договоре / техническом задании не прописано, что ответственность за совместимость несет подрядчик. А значит - "мы написали что хотели, а вам не подошло - так это вы до нас что-то не донесли/криво". Знакомо же, да?
Формулировка в договоре, которая должна быть, если вы хотите на старте обозначить границы:
Исполнитель обязуется до начала производства/разработки проверить совместимость всех используемых компонентов (материалов, комплектующих, кода, библиотек, API, версий окружений и т.п.) с проектом Заказчика. Исполнитель несёт полную ответственность за последствия, вызванные несоответствием или несовместимостью таких компонентов, если иное не согласовано в письменной форме с Заказчиком до начала работ.
Дополнительно:
🥺 Прописать, что любой новый компонент (что угодно, библиотека, API) должен быть согласован письменно с результатами теста на совместимость. 🥺 Установить штраф или обязанность исправить за свой счёт в случае, если проблема возникла из-за отсутствия проверки.
2️⃣Управленчески — в проектной документации должен быть этот пункт! Даже если в договоре всё прописано, в реальной работе подрядчики любят “забывать” про это. Поэтому в ТЗ или брифе добавляется блок:
Блок “Проверка совместимости”:
Что именно проверяем (для производства: размеры, материал, стандарты; для IT: версии ПО, окружения, API-форматы). Кто проверяет (имя, должность со стороны подрядчика). Как фиксируем результат (отчёт, фото, скриншот, тест-кейс). Критерий: “Согласовано с заказчиком” — только после подтверждения теста.
Будь занудой - не пожалеешь! 3️⃣Операционно — в процессе работы не забывай спрашивать! Чтобы подрядчик реально проверял совместимость, а не только “на бумаге”!
Запрос подтверждения перед закупкой/интеграцией: ✔️“Прошу подтвердить, что выбранный компонент/версия протестирован на совместимость и подходит под наш проект. Пришлите, пожалуйста, результаты проверки.” ✔️Ведение логов/чата согласований — чтобы потом можно было показать: “Я запрашивала, вы подтвердили”. ✔️Визуальное подтверждение — фото, видео, тестовый билд, прототип до запуска массового производства или релиза.
❤️🔥Ключевой принцип для клиента: пока подрядчик не подтвердил тест на совместимость письменно (и ты это сохранила), — никаких закупок, интеграций и оплат за этап.
И да, с этим тоже придется учиться работать. +1 привычка в копилку полезных привычек руководителя проекта.
❤️- лайк, если было полезно. 😎- если знаешь что есть Git и умеешь контролировать все на свете, но хоть раз сталкивался с тем, что "пока пилили мы - релизнулись они"
