Как мы пережили войну локальных KPI против общих целей компании

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

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

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

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

В этой войне локальных KPI против общих целей мы упустили, что продукт-то у нас один. Клиенты спрашивали, чего вообще ждать от системы, а мы даже не могли сделать нормальный роадмэп. 

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

Что именно ломалось

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

На продуктовую разработку это наложилось напрямую. К нам переезжали компании разного масштаба, запросы росли, а синхронизировать хотелки команд мы тогда умели плохо. Сегменты могли делать фичи, которые шли параллельно друг другу, или вообще дублировать проекты (так было с BI-системой). 

К нам постоянно приходили клиенты с логичным вопросом: «Какой у вас вообще план развития? Когда появится такая-то функция, какие сроки?» А мы не могли им нормально ответить. 

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

Нас объединил роадмэп

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

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

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

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

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

Тут мы поняли, что надо менять не подходы к планированию, а то, как вообще принимаются решения о крупных инициативах. 

Переход на новые процессы

Поэтому в январе мы запустили проектный офис — PMO. Это управленческая структура с директором, координатором и понятным процессом работы над кросс-командными проектами.

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

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

Этап квалификации появился не сразу, сначала в инициацию несли сумбур без нормального описания. Быстро стало понятно, что нужен фильтр здравого смысла. Мы переписывали этот регламент на коленке прямо во время первых спринтов, когда увидели, что PMO начинает тонуть в мелких бытовых хотелках отделов вместо проработки крупных системных проектов.

Дальше — регулярная встреча PMO, куда приходят все бизнес-лидеры и заинтересованные. На ней инициатор рассказывает про проект и объясняет, кому это может быть интересно. А главное — спрашивает, кто хочет стать стейкхолдером.

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

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

Если возникает жёсткий клинч (например, команде нужно катить срочный релиз для энтерпрайз-клиента, а PMO требует их лид-разработчика), — ситуацию решает управляющий совет. Там проект защищается как стратегическая инвестиция всего Кайтена, и совет авторизует выделение ресурсов сверху.

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

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

Что сделали с роадмэпом

Проект по созданию роадмэпа как раз стал полигоном для обкатки новых процессов.

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

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

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

Чтобы эта история не стала мёртвым памятником, мы внедрили регламент: роадмэп обновляется строго каждый месяц. Мы актуализируем статусы и двигаем сроки, если жизнь внесла свои коррективы (что-то сделали раньше, что-то сдвинули).

Адаптация людей

Сначала люди посмотрели на все эти новые процессы и ожидаемо не очень поняли. А потом начали замечать, как через PMO реально продвигаются инициативы, которые раньше висели годами.

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

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

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

Как теперь решаются кросс-командные вопросы

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

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

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

Объединили разные хотелки в один проект

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

Сегмент с микробизнесом хотел дешёвый или бесплатный курс, который можно выдавать новым пользователям, чтобы они сами разобрались. Средние хотели примерно то же самое, но ещё обучать внутренних сотрудников коммерческого сектора. Вместе с энтерпрайзом (А+) они видели возможность продавать консалтинг, потому что большим клиентам нужна трансформация бизнес-процессов в целом.

Если бы каждый пошёл решать это сам, пришлось бы нанимать отдельных людей в каждый сегмент и пилить три разных продукта с пересекающимися, но разными задачами. Через PMO мы собрали всех стейкхолдеров, сопоставили ожидания и увидели, что сегменты с микро- и средним бизнесом (В) хотят, по сути, одно и то же. Просто B ещё хочет тестирование для сотрудников. И это уже не два разных курса, а один с дополнительным модулем. 

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

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

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

PMO допиливаем по ходу. Работаем по канбан-методу — запустили базовый процесс и докручиваем. Процесс живой, и это правильно.

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