Были бутиковым консалтингом — стали компанией полного цикла. Вот что изменилось в управлении

Недавно мы в «Экспресс 42» пережили объединение с АО «Флант». Расскажу, как я вместе с командой прошла через этот процесс, перенесла данные из старого таск‑трекера в общий через API и научилась настраивать инструмент буквально под любую задачу — от технических тасков до HR и документооборота.

Сразу оговорюсь: я очень люблю нести добро в массы. Иногда — принудительно. Так что местами это будет история про то, как я приучала команды к порядку, а они привыкали.

Кто мы и как дошли до жизни такой

В прошлом году «Флант» и «Экспресс 42» завершили объединение.

До этого «Экспресс 42» более 13 лет работал как центр компетенций по DevOps‑консалтингу, помогая крупным компаниям — от Авито и Т⁠-⁠Банка до Х5 и Райффайзенбанка — выстраивать процессы разработки.

Теперь вместе с «Флантом» у нас единая компания полного цикла — мы сопровождаем клиентов на всех этапах: анализируем текущие процессы, проектируем будущую архитектуру, внедряем платформы и помогаем с дальнейшей эксплуатацией.

Фокус «Фланта» — экосистема решений Deckhouse, и почти все в компании крутится вокруг нее. Внутри мы поделены на 3 подразделения — у нас их принято называть бизнес‑юнитами:

1. Первый — Deckhouse, продуктовый департамент: делает фичи, модули, развивает и поддерживает решения, работает с партнерами.
2. Второй — DaaS, DevOps as a service: DevOps‑сопровождение у клиентов, причем не только решений Deckhouse, но и всей смежной DevOps‑инфраструктуры.
3. Третий — это мы, «Экспресс 42»: консалтинговые практики. Анализируем, как у клиента сейчас устроена поставка — инфраструктура, процессы и команды, и проектируем, как это перестроить и развить для получение осязаемых результатов для бизнеса наших клиентов.

Еще во «Фланте» есть общие команды: PR, маркетинг, документооборот, юристы, HR, рекрутинг, финансы и т.д. Мы называем их федеральными. Они не относятся к конкретному бизнес‑юниту, а работают со всеми.

История про два Кайтена — и как мы их объединили

После объединения у нас оказалось два Кайтена — у «Фланта» и у «Экспресса». Мы очень хотели их соединить, потому что проектов, где мы работаем вместе, становилось все больше. Цикл «под ключ» — значит, мы постоянно передаем задачи от юнита к юниту. На этапе продаж тоже общаемся с командами Sales из разных юнитов. Плюс совместные проекты с федеральными командами: интегрированные кампании и вебинары с маркетингом, с PR готовим новости и пресс‑релизы — и им нужно приходить и видеть статус в Кайтене.

Но было одно «но», и оно меня сильно беспокоило. В своем Кайтене мы наворотили кастомизации по полной: все держалось на типах карточек, проектных шаблонах, пользовательских полях. Тащить это в общий Кайтен к другим командам не хотелось. У других команд своя кастомизация — и я давно наблюдала боль: кто‑то создает поле, его начинают использовать другие, а создатель даже не знает, кто и где. Потом он меняет поле под себя — и оно меняется у всех. Вот это и не давало нам объединиться.

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

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

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

Доступы мы тоже сразу разложили по группам. Папка делится на 2 части: «Проекты» открыты всему «Экспрессу», а «Управление» — частично закрыто: что‑то открыто всем, а документооборот и HR — только тимлидам и HR. Еще завели отдельную папку с шаблонами проектов, чтобы не собирать каждый проект с нуля, — но про них расскажу чуть позже.

Ключевое правило: не ломать друг другу процессы

Когда объединяешь компании, есть большой соблазн всех причесать под один процесс. Мы сознательно так не делали. Одна из задач при объединении была сохранить все процессы и ничего не поломать.

Если коротко, для тех, кто слышит про нее впервые. P3.express (расшифровывается как People, Projects & Products) — это фреймворк для управления проектами: 37 шагов от появления идеи до получения выгод, сгруппированных в 7 фаз.

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

Как поменялся сам процесс: доска теперь показывает весь жизненный цикл

По P3.express мы работаем в Кайтене уже 3+ года. Чтобы держать методологию перед глазами, у нас есть отдельная доска процесса управления проектом — внутри команды она давно известна под коротким названием «ПУП». Название настолько прижилось, что стало локальным мемом: если кто‑то говорит «посмотри в ПУПе», все сразу понимают, о какой доске идет речь.

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

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

Теперь весь бэклог лежит в одной длинной «колбасе», разбитой на дорожки по фазам. А колонки показывают статус конкретной задачи: бэклог, бэклог на неделю, в работе, готово. Так команда сама двигает задачи и закрывает их — и при этом видно, в какой фазе мы находимся.

Удобно еще и тем, что каждый участник команды может отфильтровать задачи по своей роли и посмотреть, что делать — чтобы не забыть свои активности. Доской при этом управляет менеджер проектов.

Для ведения проектов используем шаблоны

Чтобы видеть все проекты сразу, я собрала их в одном месте — пространстве «Портфель проектов». Это вид сверху: на одном экране видно, что происходит по всему юниту.

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

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

Выглядит шаблон так: в пространстве есть карточка-«задача проекта», эпики, общий бэклог, бэклог на текущий этап, колонки «в работе», «заблокировано», «ревью», «валидация» (когда передаем тимлидам или заказчику), «готово» и «отменено / потеряла актуальность». Рядом всегда лежит доска ПУП — чтобы процессно не забывать, что нужно делать.

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

Отдельно стоит сказать про еще одно большое переосмысление. Я решила объединить пресейл и производство в единый процесс. Раньше они существовали отдельно, хотя на самом деле речь всегда шла об одном и том же проекте — менялась только его стадия. У нас нестандартный продукт, поэтому пресейл — это полноценная работа: мы встречаемся с заказчиком, разбираемся в его задачах, выявляем потребности, проектируем решение, готовим и рассчитываем коммерческое предложение. Да, на этом этапе заказчик может отказаться. Но команда уже потратила время и ресурсы, а значит, для меня как руководителя это такой же проект, который должен быть в общем портфеле. Теперь там все в разных стадиях: бэклог продаж, продажи, бэклог производства, производство и завершенное.

Типы карточек — наш главный рабочий инструмент

Типы карточек мы используем очень активно. Расскажу про самые любимые.

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

Очень удобно хранить всю историю проекта в одной карточке — от запроса клиента до завершения. У нас были случаи, когда запрос клиента где‑то терялся, и мы от этого сильно страдали. Теперь в карточке пресейла есть чек‑лист, и его последний пункт — «зафиксировать все договоренности и записать в карточку». Это сильно снижает риск что‑то потерять, особенно когда от продажи до старта проходит много времени и команда проекта еще даже не определена.

Изменение (развитие юнита). Отдельная доска, куда мы записываем, какие процессы меняем и внедряем. Дорожки — по годам, карточки двигаются. В конце года смотрим и видим: вот сколько мы всего сделали помимо проектов. Раньше это было сложно вспомнить, а теперь — видим, столько всего сделали.

Артефакт. На проектах мы готовим клиенту артефакты — отчеты,, дорожные карты, паспорта систем, value stream map и многие другие. Каждый артефакт изображаем карточкой, чтобы привязывать к нему подзадачи: черновик, вторая версия, сбор обратной связи.

Люди. В HR‑пространстве на каждого сотрудника есть карточка: когда начал работать, кто руководитель, кто бадди у инженера, дата окончания испытательного срока, город. К ней привязаны заметки со встреч один‑на‑один — удобно находить.

Еще есть типы «Процесс» (с обязательными полями «бизнес‑ценность», «текущее состояние», «целевое состояние»), «Результат», «Задача АИК» (развитие анализа и консалтинга), «Задача с ретро» и стандартные баг, эпик, веха, задача. Ко многим привязана автоматизация: при перемещении меняется тип, добавляются поля, назначаются ответственные. Например, на этапе согласования автоматически создаются дочерние карточки на нужных людей — и они сразу видят их у себя в личном.

Миграция через API: 125 пространств, сотни досок, месяц работы

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

Нам помогли коллеги из другой компании — у них была та же боль с объединением Кайтенов. Они показали Kaiten Migration Tool, который умеет переносить через API. Это был хороший старт, но инструмент не мог выполнить нашу задачу на 100%. В нашем юните как раз был инженер, который хотел попрактиковаться на Python, — так что эта задачка быстро нашла исполнителя. Он дописал Kaiten Migration Tool. В итоге за месяц мы перевезли:

• 125 пространств с сотнями досок;
• 17 типов карточек;
• 43 пользовательских поля.

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

С этого момента прошло уже больше 2 месяцев. Сейчас мы используем 436 лицензий — и все они в едином пространстве.

Что в итоге изменилось

Если коротко — появилась гибкость. Процессно мы остались верны P3.express, но сам шаблон выстроили под себя: пользовательские поля, типы, автоматизации, жизненный цикл на доске. Получилось не сразу — мы подвигались туда‑сюда, — но сейчас все работает на комфортном уровне.

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

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

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

Если вы сами объединяете команды и инструменты

За время этого переезда мы набили несколько шишек и вынесли выводы, которыми хочу поделиться, — они пригодятся любому бизнесу, который сводит несколько команд (и их системы) в одно.

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

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

Переносите данные программно, а не руками. 125 пространств и 4+ года истории невозможно перетащить вручную без потерь. Мы переносили через API (взяли готовый Kaiten Migration Tool и дописали под себя) — и сохранили даже комментарии с авторами и датами. Если у вас есть инженер и доступ к API, это в разы надежнее ручного копирования.

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