Короткий ответ
#Что понять в первую очередь
Зависимость от подрядчика — это не одна вещь. Их пять, и у них очень разная цена и очень разные способы исправления:
- Владение — на чьё имя каждый аккаунт. Может лишить возможности работать.
- Эксплуатируемость — может ли кто-то ещё запускать и выпускать систему. Стоит недель.
- Понимание — может ли кто-то вне подрядчика описать систему. Стоит месяцев.
- Доступы — где лежат ключи. Чинится за часы и может стоить всего, если пересекается с первым пунктом.
- Заменяемость — сколько пройдёт от решения до того, как новая команда начнёт выпускать изменения. Следствие остальных четырёх.
Разделять их стоит потому, что большинство компаний обнаруживают: с отношениями всё в порядке, а конструкция хрупкая. Это хороший исход: он означает, что исправление — это администрирование, а не смена подрядчика.
#Шесть ходов
-
Перевести все аккаунты на компанию
Домен, DNS, облако, база, бэкапы, репозиторий, CI, платёжный провайдер, почта, мониторинг — и адреса восстановления у всех них.
Примерно полдня работы, и это снимает единственную категорию риска, которую нельзя отменить деньгами. Сделайте это первым, даже если больше не сделаете ничего.
-
Один раз дать выкатить кому-то вне подрядчика
Один релиз под присмотром, который проводит внутренний человек или независимый подрядчик. Это превращает «у них есть процесс» в факт и надёжно находит два-три недокументированных шага.
-
Развернуть бэкап во временную среду
Тоже силами того, кто обычно этим не занимается. Эта проверка проваливается чаще всего, а побочным продуктом даёт ваше настоящее время восстановления.
-
Вывести техническую картину, которой владеет компания
Из чего система состоит, от чего зависит и чего сейчас никто подтвердить не может — выведенное из кода, а не написанное той стороной, от которой вы однажды можете уйти.
Не как вызов. Как актив компании, который переживёт любую смену подрядчика, включая ту, которую инициирует сам подрядчик.
-
Записать вопросы, на которые может ответить только он
Дыры в этой картине и есть список. Задайте их сейчас, письменно, в рамках обычной работы, а не в рамках выхода.
-
Вписать условия перехода при следующем продлении
Аккаунты остаются за компанией; при расторжении — определённый период передачи с определёнными приёмочными проверками; платное окно консультаций после.
Обеим сторонам выгодно, чтобы это существовало до того, как понадобится, — именно поэтому это легко согласовать, пока не понадобилось.
#Что не помогает
Просить больше документации.
Вместо этого Структурную половину выведите, а на остальное задайте конкретные вопросы. Просьба о документации даёт документ, написанный так, чтобы удовлетворить просьбу.
Нанять одного внутреннего разработчика, чтобы «присматривал за ними».
Вместо этого Один человек, который не подрядчик, — это новая точка отказа. Сначала владение и эксплуатируемость; нанимайте потому, что нужна мощность, а не в качестве страховки.
Разделить работу между двумя агентствами, чтобы не зависеть от одного.
Вместо этого Обычно получаются две частичные зависимости, стоимость координации и никого, кто понимает целое. Зависимость надо снижать, а не делить.
Требовать исходники, которые у вас и так есть.
Вместо этого Репозиторий у вас почти наверняка есть. Зависимость не в коде, а в понимании и в аккаунтах.
Угрожать уходом как приёмом на переговорах.
Вместо этого Это портит рабочие отношения и ничего не меняет структурно. Сделайте шесть ходов тихо: они действеннее и не враждебны.
#Как говорить об этом с подрядчиком
Работает рамка непрерывности: «нам нужно уметь отвечать на эти вопросы инвестору, покупателю или страховщику». Это правда, это не про них, и срок задаёте не вы.
Три вещи, которые стоит знать о том, как это принимают:
- Большинство подрядчиков испытывают облегчение. Держать домен клиента — обязательство, о котором никто не просил.
- Компетентный подрядчик и сам это знает. Он видел, как бизнесу клиента угрожал аккаунт, оформленный не на того, и предпочёл бы, чтобы это был не его аккаунт.
- Сопротивление — самый полезный сигнал из доступных. Если вопрос «на чьё имя домен?» создаёт проблему, эта реакция сказала вам больше, чем сказал бы ответ.
#Зависимость, которую убрать нельзя
Часть её структурная, а не отношенческая, и её стоит назвать отдельно, чтобы ею управляли, а не раздражались:
- Знакомство с системой. Команда, работавшая с системой четыре года, быстрее любой замены, и никакой объём документации этот разрыв полностью не закрывает. Это настоящая цена смены, и ничьей вины в ней нет.
- Проприетарные компоненты. Собственный фреймворк или внутренняя библиотека подрядчика внутри вашего продукта переживают договор. Стоит об этом знать; иногда стоит заплатить за избавление.
- Необычные технологии. Стек, который знают немногие, — это маленький рынок найма, кто бы ни был подрядчиком.
- Недокументированные соглашения. Сильные внутренние паттерны, которые никто не записал, дороги любому новичку.
Привязка к поставщику — о том, за избавление от каких из них стоит платить.
#Что идёт не так
Начать с понимания, а не с владения.
Вместо этого Сначала владение. Это быстрее, дешевле и это единственная часть, после которой можно остаться в проигрыше навсегда.
Сделать всё разом как формальный проект.
Вместо этого Шесть ходов за квартал, в рамках обычной работы. «Проект по рискам подрядчика» читается как начало выхода, хотите вы этого или нет.
Вывести картину один раз и больше никогда.
Вместо этого Картина двухлетней давности — картина другой системы. Обновляйте её, когда меняется что-то существенное; ценность в сравнении.
#Чего это не покрывает
Чего это не делает
- Хорошо ли подрядчик работает. Это отдельное суждение, и эта страница по нему позиции не занимает.
- Договорное право, сроки уведомления и интеллектуальную собственность. Спросите того, кто в этом разбирается.
- Что делать, если подрядчик уже перестал сотрудничать, — тогда читайте руководство о смене агентства.
- Ценообразование и коммерческие переговоры: это совсем другой разговор.