Перевод команды на один инструмент за неделю

Объединение трёх-четырёх инструментов в один звучит как проект на целый квартал. На самом деле это не так. Основная часть работы — экспорт данных, воссоздание структуры, переучивание привычек — умещается в одну сфокусированную неделю, если выстроить последовательность правильно. Вот план, которого мы придерживались бы с любой командой, используя Proman в качестве рабочего примера, — но последовательность применима к любому инструменту, на который вы переходите.

День 1: аудит вашего стека

Прежде чем что-либо трогать, запишите, что у вас есть на самом деле:

Каждый инструмент, который используется сейчас, включая те, что никто официально не одобрял (та самая теневая доска в Trello, которую кто-то ведёт).
Каждый активный проект и то, какие из них действительно активны, а какие фактически заброшены. Будьте честны — проекту без активности за последние 60 дней не нужна аккуратная миграция, ему нужен архив.
Каждая интеграция, связывающая инструменты между собой (уведомления в Slack из вашего PM-инструмента, записи времени, попадающие в инструмент выставления счетов, и т. д.) — каждую придётся воссоздать или заменить.
Кто за что отвечает — кто администратор в каждом инструменте, у кого есть доступ к биллингу, кто должен будет позже одобрить отмену подписки.

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

День 2: экспорт и импорт проектов

Начните только с активных проектов — со списка из Дня 1.

Сначала экспорт, всегда. Большинство PM-инструментов предлагают экспорт задач, проектов и комментариев в CSV или JSON. Сделайте это прежде, чем что-либо ещё, даже если в итоге не воспользуетесь исходным файлом — это ваша страховка.
Сначала перенесите один проект. Не импортируйте всё пакетом сразу. Выберите самый активный проект, вручную воссоздайте его структуру (колонки, приоритеты, сроки) и используйте его как шаблон для остальных. Это рано выявляет структурные несоответствия — пользовательское поле или этап процесса, который не переносится напрямую, — пока зона поражения ограничена одним проектом, а не двенадцатью.
Сохраняйте контекст, а не только задачи. Названия задач и сроки переносятся легко. История комментариев и вложения файлов — часто нет. Заранее решите, нужно ли переносить эту историю или старый инструмент останется в режиме «только чтение» для справки (см. День 5).
Назначайте ответственных по ходу дела. Не импортируйте задачи без исполнителей, чтобы разобраться с этим позже, — назначайте владельцев во время импорта, пока вы ещё помните, кто чем занимался.

День 3: переход на новый чат — архивируйте, не удаляйте

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

Сначала разверните новые пространства чата, отразив в них самые используемые каналы (общий, по проектам, по командам).
Объявите конкретный момент перехода — не «где-то на этой неделе», а конкретное время. Именно неопределённость приводит к разрозненному использованию.
Архивируйте старые каналы, не удаляйте их. Спустя недели вам понадобится искать контекст в старой истории чата. Архивирование сохраняет её доступной для поиска и только для чтения, не конкурируя за внимание с новыми каналами.
Направляйте, а не напоминайте назойливо. Закреплённое сообщение в старом канале со ссылкой на новый плюс сообщение от бота, если старый инструмент это поддерживает, работает лучше, чем повторяющиеся напоминания.

День 4: учёт времени и шаблоны

Это день, который команды чаще всего пропускают, — и именно поэтому старые привычки возвращаются спустя месяц.

Сначала настройте категории учёта времени — отразите те же категории биллинга или отчётности, что использовались раньше, чтобы исторические сравнения оставались осмысленными.
Создайте шаблоны для повторяющихся типов проектов. Если вы регулярно ведёте однотипную работу (ежемесячный ретейнер, стандартный спринт), создайте шаблон доски/задач один раз, чтобы каждый новый проект стартовал единообразно.
Переносите данные о времени только за текущий расчётный период, если старый инструмент поддерживал экспорт. Более старую историю времени обычно можно оставить в старом инструменте для справки, не перенося заново.
Протестируйте весь путь выставления счетов от начала до конца, прежде чем полагаться на него для реального клиентского счёта. Зафиксируйте тестовую запись времени, сформируйте тестовый счёт, убедитесь, что цифры совпадают с ожидаемыми.

День 5: отключение старых инструментов

Оставьте старые инструменты в режиме «только чтение» на определённый срок (обычно 2–4 недели), вместо того чтобы отменять подписку немедленно. Это даёт вам страховку на случай, если что-то было упущено при экспорте.
Установите конкретную дату отмены в календаре прямо сейчас, а не «когда мы будем уверены». Открытый период «только чтение» имеет тенденцию становиться постоянным, и в итоге вы бесконечно платите и за старый, и за новый стек.
Убедитесь, что каждая интеграция либо перенесена, либо явно отключена. Забытое подключение Zapier, за которое вам всё ещё выставляют счета, или вебхук Slack, который продолжает срабатывать в канал, который никто не читает, — это то, что незаметно тянется месяцами.
Отмените подписки в назначенную дату. Именно этот шаг реально реализует экономию — всё до этого было подготовкой.

Типичные ошибки

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

Перенос неактуальных проектов. Не уделяйте мёртвому проекту столько же усилий на перенос, сколько активному. Если к нему никто не притрагивался два месяца, заархивируйте его в старом инструменте и оставьте там — не тратьте День 2 на воссоздание его доски.

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

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

Недели достаточно, чтобы сделать это правильно, если выстроить последовательность: аудит перед переносом, один проект перед всеми остальными, архивирование перед удалением и фиксированная дата перед фактической отменой чего-либо. Инструмент, на который вы переходите, имеет меньшее значение, чем выполнение этих пяти шагов по порядку.