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