CRM-маркетолог уходит через неделю. В компании остаются сотни файлов, доступ к платформе и обещание «пишите, если что». Новый сотрудник открывает список цепочек и не понимает, какие из них влияют на деньги, какие давно остановлены и почему в одной ветке стоит странное исключение. Документов много, а способность управлять системой не передана.

Передача CRM-проекта — переход ответственности за действующие процессы к человеку, который может их поддерживать и изменять. Полнота архива важна, но готовность нового владельца определяется действиями: способен ли он найти источник проблемы, безопасно остановить отправку и объяснить результат отчёта.

Сначала передайте критичные процессы

При ограниченном времени расставляйте приоритеты по последствиям. В начале нужны денежные механики, разрешения на коммуникацию, массовые отправки, критичные интеграции и ближайшие обязательства. Историю всех декоративных изменений можно изучить позже.

Составьте список действующих сценариев с владельцем, статусом, последним изменением, источником данных и способом остановки. Отдельно отметьте ручные действия: ежедневную загрузку файла, обновление курса валют или переключение акции. Именно такие операции часто исчезают вместе с человеком, который выполнял их по привычке.

В руководстве Google SRE по подготовке новых сотрудников рекомендуются последовательное обучение, работа с реальными инструментами и безопасные упражнения с неисправностями вместо первого знакомства со сбоем во время настоящего дежурства. Для CRM это повод включить в передачу практическое выполнение задач. Пример ниже — адаптация CRM Lab, а не обещание освоить любой проект за фиксированное число дней.

Организуйте передачу вокруг рабочих вопросов

Вопрос нового владельцаЧто должно быть доступноКак проверить передачу
Что сейчас работаетРеестр активных сценариев и календарьНайти все отправки на ближайшие дни
Откуда приходят данныеСхема источников и ответственныеПроследить один заказ до CRM
Что делать при ошибкеПравила остановки и контактыОстановить тестовый сценарий и подтвердить результат
Почему есть исключениеРешение с причиной и датойОбъяснить последствия его удаления
Как считается результатОпределения метрик и источник отчётаВоспроизвести один показатель
Кому передать проблемуВладельцы систем и порядок эскалацииНайти нужного человека без личной переписки предшественника

Не ограничивайтесь ссылкой на общую папку. У каждого документа должен быть понятный статус актуальности и связь с действующей версией. Если схема устарела, отметьте это прямо и заведите задачу на восстановление. Архив не должен выглядеть как проверенная инструкция.

Используйте совместный проход и обратный показ

Сначала уходящий сотрудник показывает типовую задачу и объясняет решения. Затем новый выполняет похожую задачу сам, а предшественник наблюдает. Такой обратный показ быстро обнаруживает пропущенные шаги: особый фильтр, скрытую очередь согласования, ручную проверку суммы.

Условный план двух дней передачи. В первый день команда разбирает ближайший календарь, критичные сценарии, доступы и остановку. Во второй новый владелец выполняет тестовый выпуск, разбирает один прошлый инцидент и воспроизводит отчёт. По итогам фиксируются пробелы, временные ограничения и ответственные за оставшиеся вопросы. Это план приоритизации, а не гарантия полной готовности за два дня.

Если важный навык ещё не освоен, ограничьте соответствующие изменения и назначьте временную поддержку. Лучше честно обозначить «массовый запуск только с проверяющим», чем считать проект переданным после подписания списка файлов.

Передайте доступы через владельцев систем

Проверьте учётные записи, роли, многофакторную аутентификацию, сервисные интеграции, домены, платёжные настройки и оповещения. Автоматические отчёты и аварийные уведомления должны приходить действующим владельцам.

Не передавайте личный пароль прежнего сотрудника. Создайте необходимые доступы новому, проверьте их и затем отзовите старые по принятому процессу. Для сервисных ключей сначала выясните зависимости: необдуманная замена ключа может остановить интеграцию. План смены должен включать проверку работы и возможность восстановить соединение.

Список секретов и сам секрет — разные вещи. В документации достаточно указать назначение и место хранения в утверждённом хранилище. Копии токенов в скриншотах, письмах и записанном видео создают лишние точки утечки.

Сохраните незавершённые решения

Передача должна включать не только «как устроено», но и «что пока не решено». Запишите известные ошибки, временные обходы, действующие эксперименты, ожидаемые ответы подрядчиков и обещания бизнесу. Для каждого пункта нужны следующий шаг, срок или условие возвращения к вопросу.

Особенно внимательно передавайте эксперименты. Новый сотрудник должен знать, какие группы нельзя смешивать, когда заканчивается наблюдение и какие изменения способны нарушить дизайн. Остановка непонятной ветки «для порядка» может уничтожить ценность уже собранных данных.

Разберите один отчёт с расхождением: где находится источник истины, какая задержка допустима, что делать при несовпадении. Это полезнее, чем механически перечислить все показатели в дашборде.

Когда передачу можно считать завершённой

Новый владелец должен самостоятельно пройти заранее выбранные рабочие сценарии и знать, куда обратиться за пределами своей компетенции. Проверяется не память на названия полей, а способность безопасно действовать.

Итог передачи — короткая запись: что принято, какие ограничения остаются, кто временно помогает и когда закрываются пробелы. После первого самостоятельного цикла работы обновите инструкции по возникшим вопросам. Тогда смена сотрудника становится управляемым переходом, а не длительной зависимостью от человека, который уже ушёл.

Источники

Widdowson A. Accelerating SREs to On-Call and Beyond. Site Reliability Engineering. O’Reilly Media, 2016. Chapter 28.