Предмортем: воркшоп перед переписыванием или переходом на новую платформу

Почему планы по переписыванию рушатся ещё до начала кодирования

Большинство планов по переписыванию проваливаются до того, как кто‑то напишет код. Команда начинает обсуждать будущую систему — разговор заполняется новыми экранами, сервисами и более чистым стеком. Между тем текущему продукту дают поверхностное описание, хотя его ежедневные проблемы должны формировать всё решение.

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

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

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

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

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

Именно поэтому предмортем-воркшоп важен перед решением «идём/не идём» по переписыванию. Он даёт каждой команде пространство назвать пути отказа рано, пока изменение объёма ещё дешёвое, а сказать «нет» — ещё возможно.

Что на самом деле делает предмортем-воркшоп

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

Вообразите, что прошло шесть или девять месяцев. Бюджет вышел, клиенты разозлились, продажи не смогли объяснить изменение, тикеты поддержки накопились, у инженеров всё ещё работает половина старой системы. Тогда задайте один вопрос: «Что пошло не так?»

Этот сдвиг меняет разговор. Люди говорят более честно, когда им не нужно защищать план. Они перестают продавать переписывание друг другу и начинают называть способы, которыми оно может провалиться.

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

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

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

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

Именно в этом упражнение особенно полезно: оно заменяет оптимизм по переписыванию доказательствами.

Кто должен быть в комнате

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

Для большинства команд достаточно пяти–семи человек. В небольшой компании один человек может закрывать две роли — это нормально, если каждая точка зрения всё равно представлена.

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

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

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

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

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

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

Не приглашайте только по званию. Человек, близкий к работе, часто даёт самые жёсткие ответы. Именно такие ответы в этом формате чаще всего нужны.

Что подготовить до сессии

Предмортем лучше работает, когда команда реагирует на факты, а не на догадки. Начните с одного простого предложения, объясняющего, зачем переписывание. Если предложение расплывчатое, план тоже будет расплывчат.

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

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

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

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

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

Ещё одна вещь в подготовке: стоимость задержки. Спросите каждую команду: «Что сломается, если cutover случится на месяц позже?» Хочется получить конкретные ответы, а не драму. Может быть, поддержка выдержит двойной объём; может быть, продажам придётся снова объяснять пропущенную дату; может быть, финансы снова запустят ручную сверку.

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

Как провести воркшоп шаг за шагом

Начните с жёсткой рамки. Покажите цель, назовите, что команда планирует переписать или заменить, и укажите дату, к которой все идут. Если группа не может согласовать объём и сроки за две минуты, остановитесь и решите это сначала.

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

Достаточно простого потока:

1. Дайте всем 10–15 минут тишины, чтобы каждый написал пути отказа самостоятельно.
2. Обойдите комнату и зачитайте каждую заметку вслух. Захватывайте их там, где их видят все.
3. Сгруппируйте похожие заметки.
4. Спросите, какие риски наиболее вероятны, самые дорогостоящие или самые трудные для восстановления.
5. Назначьте владельца, следующий шаг и триггер паузы для каждого серьёзного риска.

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

Вопросы, на которые должна ответить каждая команда

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

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

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

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

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

Несколько вопросов особенно полезны:

• Где пользователи почувствуют изменение первыми, и что они называть сломанным в первый день?
• Какие странные случаи агенты исправляют вручную сегодня, и что случится, если эти исправления исчезнут?
• Какие активные сделки зависят от текущего рабочего процесса, даже если он кажется старым или неуклюжим?
• Какие переносы данных, интеграции или шаги релиза могут провалиться так, что их трудно будет отменить?
• Какой точный сигнал заставит команду остановиться и объявить паузу?

Последний вопрос часто самый честный в комнате. «Пауза» должна означать что‑то конкретное: всплеск ошибок, пропажа клиентских данных, сбои синхронизации биллинга, удвоение объёма поддержки или блокировка крупной сделки.

Если люди с трудом отвечают, это тоже сигнал. Обычно это значит, что переписывание идёт быстрее, чем понимание командой текущего продукта.

Простой пример из реального планирования

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

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

Затем провели предмортем.

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

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

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

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

Это решение, вероятно, спасло их от дорогостоящей катастрофы.

Ошибки, которые портят упражнение

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

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

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

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

Не заканчивайте с полной доской и без выполнения. Каждый серьёзный риск требует владельца, следующего шага, срока и правила, когда команда ставит паузу или пересматривает переписывание. Без этого встреча превращается в приличную рутину, которая ничего не меняет.

Комната должна уйти немного неудобной, но гораздо яснее понимать, стоит ли двигаться дальше.

Быстрая проверка перед утверждением переписывания

Утверждение должно ждать, пока команда не сможет ответить на простой вопрос: кто пострадает первым, если всё пойдёт плохо? Если никто не может назвать первых пострадавших пользователей, план всё ещё слишком абстрактен. Переписывание обычно ломает что‑то небольшое раньше, чем что‑то очевидное, и эти ранние трещины часто проявляются в аккаунтах с необычными рабочими процессами.

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

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

Один шаг постоянно пропускают: кому‑то нужно превратить заметки в мемо о go/no‑go. Не огромный документ — одна‑две страницы достаточно. Оно должно перечислять риски, предположения, триггеры паузы, владельца для каждой проблемы и причину, почему идти сейчас, а не позже.

Это мемо важно, потому что энергия воркшопа быстро уходит. Через неделю люди помнят оптимистичные части и забывают предупреждения. Запись заставляет принять реальное решение. Если мемо похож на список неизвестных без владельцев, у вас уже есть ответ: не утверждать переписывание пока.

Что делать после воркшопа

Воркшоп должен изменить план. Если команда вышла с тем же объёмом, теми же сроками и теми же рисками — сессия не сработала.

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

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

Короткое письменное сопровождение держит всех честными. Зафиксируйте, что вы убрали из первого релиза. Превратите неизвестности в эксперименты, маленькие пробы или проверки с клиентами. Назначьте дату ревью до того, как кто‑то начнёт длинную разработку. Если первые эксперименты провалятся — остановитесь и пересмотрите.

Эта дата ревью важна. Две недели доказательств могут сэкономить два месяца напрасной работы.

Если команде не удаётся договориться о рисках, привлеките нейтрального технического лидера. Внешний взгляд помогает, когда продукт хочет скорости, инженерия — безопасности, а продажи — чтобы все обещания были выполнены одновременно. Для команд, которым нужен такой обзор, Oleg Sotnikov на oleg.is работает как внештатный CTO и консультант стартапов. Короткий внешний проход по объёму, архитектуре и рискам rollout может сильно прояснить решение «идти/не идти» прежде, чем месяцы работы будут зафиксированы.