Компания может владеть продуктом, который не может ни задеплоить, ни восстановить, ни перенести, ни передать кому-то ещё. Узнаёт она об этом обычно на той неделе, когда заканчиваются отношения с теми, кто его построил, — и к этому моменту тех, кто мог бы это предотвратить, уже нет.
Никто не подписывает договор с намерением потерять репозиторий. Подписывают тот, где о нём не сказано, а потом проходит три года. Эта проверка задаёт десять вопросов, которые устанавливают, как обстоит дело на самом деле, и называет цену каждого разрыва в тех терминах, в которых он в итоге и обойдётся.
Для продукта, который уже существует и который кто-то другой построил, обслуживает или хостит.
Это не для проекта, который ещё не построен. Вопросы, важные до того, как появится что контролировать, задаёт «Готовность финтех-проекта». Готовность финтех-проекта
Десять вопросов из чек-листа, по которому идёт аудит FinMV «Ownership and Project Continuity». Тот аудит — пакет, который вы запускаете в своей среде; обратно отправляется его структурированный результат. На эти десять вы отвечаете сами за полторы минуты, и «не уверен» — полноценный ответ, который засчитывается.
В чьём аккаунте лежит исходный код и есть ли у компании доступ владельца сегодня, а не обещание такого доступа.
В чьём облачном аккаунте работает продакшен и у кого учётные записи, которые могут изменить всё: root на сервере, владелец облака, суперпользователь базы.
Кто контролирует домен и на кого оформлены платёжный провайдер, KYC-провайдер и облачный аккаунт.
Есть ли бэкапы, восстанавливал ли их кто-нибудь хоть раз и смогли бы вы сегодня выгрузить свои данные по инвесторам и транзакциям, никого не спрашивая.
Сможет ли новая команда разобраться по написанному — или ей придётся восстанавливать устройство системы чтением кода.
Сколько человек способны поддерживать это в работе и сможет ли кто-нибудь принять проект, если текущие разработчики завтра остановятся.