Осторожно, статья-детектор.
Разбираем, как команды играют в метрики, вместо создания ценности, и как это обходится компании в сотни миллионов убытков в год, а также ищем корень проблемы и решение.
Есть много статей про успешные трансформации. Но следует отметить, что часто это компании с одним основным бизнесом. У них есть один глобальный продукт и всё строится вокруг него. Это логично, когда ядро, движимое одной целью, развивается и обрастает периферией, особенно если это ядро сформировалось относительно недавно, лет 5-10 назад. Либо еще вариант, когда пишут про успешную трансформацию в одной отдельной команде.
Но что происходит у гигантов или в госсекторе? Они развивались по старым правилам, а потом стали расширяться, путём поглощений и создания новых, несвязанных, направлений. Когда банк, например, становится не только банком.
Именно у таких компаний часто разворачивается «театр продуктового подхода». Он не только не улучшает ситуацию, а даже ухудшает. Вместо создания ценности команды учатся играть в метрики и отбывать стендапы.
Краткий смысл «продуктовости»
Продуктовая трансформация дает компании способность системно и быстро создавать продукты, которые нравятся клиентам и приносят устойчивый бизнес-результат. Это переход от «фабрики по выполнению заказов» к «фабрике по созданию ценности». Здесь каждый сотрудник понимает, для кого и какую пользу он создает.
Звучит красиво, «Значит, хорошие сапоги, надо брать!»
Философия модели превращает продуктовые команды в маленькие стартапы внутри компании. У них есть:
Своя «выручка» (реальный доход или внутренний бюджет)
Свои «затраты» (на команду и услуги других)
Своя «прибыль» (остаток для реинвестирования)
Это создаёт здоровую предпринимательскую среду. Решения принимаются на основе экономики, а не внутреннего лоббирования.
Вернёмся в реальность
Крупнейшие компании, развивая и поглощая разные бизнесы, в какой-то момент начинают задыхаться от несварения желудка. Нужно срочно что-то делать, где-то брать таблетку. Консалтинги им предлагают такую таблетку в виде продуктового подхода и agile.
Волна продуктовых трансформаций покатилась несколько лет назад и теперь уже можно проанализировать результаты.
Спойлер: Именно у таких закостенелых гигантов получается театр продуктового подхода.
Как начинается трансформация
Коучи красочно показывают упражнение с переворачиванием игральных карт.
Это выглядит примерно так: несколько человек в цепочке, первый переворачивает все карты и передаёт второму участнику. Второй переворачивает в обратную сторону и передает третьему и т.д. пока все карты не достигнут последнего участника. Процесс идёт долго.
Затем коуч меняет правила: переворачивать по одной карте и сразу передавать. Появляется поток. Время резко сокращается.
Казалось бы — вот она, серебряная пуля!
Но что, если добавить зависимости между картами? Ведь в реальной жизни зависимости повсюду.
Связать нитями карты: 1-3, 2-5, 4-1. Повторить упражнение. Получится ли так же быстро? Эта неудобная действительность часто замалчивается.
Дальше — раздача ролей: продуктовнеры, техлиды.
Структура уже существует (старая). ИванИваныч — начальник отдела. Разумеется, одна из ролей достанется ему. Раньше он подписывал отпуска и утверждал ТЗ. Теперь на бейджике у него «техлид».
Есть ещё аналитик. Раньше он писал ТЗ под диктовку бизнеса или рисовал отчёты в Excel. Теперь он — продуктовнер. Ему предстоит управлять стратегией продукта.
Ну всё, с завтрашнего дня попрёт!
Но годится ли ИванИваныч на роль техлида? Писал ли он код вообще, знаком ли с технологиями? Или он всегда был просто начальником?
Подходит ли аналитик на продуктовнера? Насколько он инициативен, имеет ли он коммерческую хватку? Возможно, ТЗ у него получались отлично, благодаря флегматичности и скрупулезности. Он прекрасно видит нестыковки в деталях. Но здесь нужны другие качества.
Продуктам прикручивают модные метрики: MAU, NPS, PQI.
Пытаются встроить их в KPI.
Появляются всевозможные центры, комитеты (продуктовые, архитектурные и прочие), защита бюджета, OpEx, CapEx.
Я не против метрик и комитетов самих по себе. Речь о другом — ничего не меняется с точки зрения ценности. Всё как было, так и осталось, только добавилась бюрократия с бюджетами и комитетами. Это затормозило работу и повысило расходы.
В календарях появились стендапы, ретро и прочие пятничные встречи от HR и Agile. Это отнимает время.
На ежедневных встречах, вместо поиска ценности, обсуждают, что сделали вчера:
—Нуу, я продолжаю писать код...
—А я тестирую интерфейс...
—Скрам-мастер говорит: «Петя, ты выбиваешься из тайминга, переход хода».
На ретро все участники жалуются на боли, перетаскивают стикеры в Miro. Но из раза в раз ничего не меняется и команда разочаровывается в этом мероприятии.
Коучи рассказывают, как двигать задачи на доске, будто в этом самоцель.
У ИванИваныча календарь забит бесконечными встречами, даже 1 января. Интересно, он вообще отдыхает?
Коучи говорят, что команда сама определяет, как работать. Но когда команда пытается скинуть оковы формальностей, коуч останавливает: «Ребята, давайте не будем спешить. Давайте попробуем поменять порядок выступающих. Раньше Петя был первый, теперь пусть будет Маша».
Через время команда видит: метрики не дотягивают до ожидаемой премии. А премию хочется. Тогда начинается магия цифр. В PQI смещают фокус с функционала на доступность. По NPS ссылаются на кривой опросник, якобы из-за него показатель такой низкий. И все получают премию. Рабочая схема. Почему бы в следующий раз не повторить?
Перед защитой проблематику клиента и цели пишут максимально размыто, чтобы нельзя было поймать за руку.
P.S. Я не предлагаю отменять стендапы. Я предлагаю применять их там, где они уместны. Особенно это касается ежедневных.
Кому подходят ежедневные стендапы и ретро?
Стендапы подходят небольшим командам (<10 человек) с очень коротким циклом.
Гипотеза — проверка — корректировка — внедрение.
День 1: Так, ребята, клиент хочет новый баннер. У меня есть одна мысль, нужно ее проверить. Для этого я попрошу вас к завтрашнему дню сделать эскизы одноразовых стаканчиков для кофе.
День 2: Все подготовили наброски. Вместе посмотрели и выбрали вариант Васи. Теперь его нужно раскрасить в мультяшном стиле. Оля говорит, что уже знает, как примерно это будет выглядеть, и к завтрашнему дню будет готово. А у Васи другая концепция и он тоже вызвался раскрасить по-своему.
День 3: Все соберутся и обсудят результат.
Здесь стендапы работают и они полезны.
Но когда это огромная команда разработки какого-нибудь сервисного продукта вроде ERP… Люди сидят и пишут код под новый закон. Какие стендапы? О чём там говорить?
Сервисный продукт/платформа
Особенно абсурд трансформации заметен на внутренних/сервисных «продуктах». ERP, CRM, бухгалтерский софт, порталы. Ими пользуются сотрудники, а не клиенты. В этих системах часто нет метрик, либо они не измеряются. Зато крупным шрифтом PQI = 99%.
Если поинтересоваться, как у легаси может быть PQI 99%? Окажется, что под PQI подразумевали только доступность (без учета функциональности, удобства и дизайна). Посмотрите, там же звездочка рядом мелким шрифтом. Но кто на это обращает внимание? Куда интереснее спросить: почему Python, а не Java и где у вас тут ИИ?
Внутренние продукты не мотивированы что-то улучшать. Им добавили бюрократии в виде комитетов. Выделяют виртуальные бюджеты, которые нужно потратить до конца года, иначе в следующий раз не дадут.
Что делают в такой ситуации? Правильно!
Продукт А договаривается с продуктом Б о фиктивной доработке. Бюджет мигрирует к Б. В следующем году Б вернёт «долг» обратной доработкой. Бюджет освоен, все довольны. Можно просить новый, не меньше прежнего.
Даже когда клиентский продукт А (витрина для клиентов) приходит во внутренний продукт Б (ERP), чтобы тот разработал API-интеграцию, начинается долгая история. «За чей счёт банкет? У нас рефакторинг. Бэклог забит до конца квартала».
Бесконечные переписки в почте на 20 человек в копии, потому что не понятно к кому пойти. Петя добавляет Васю, Вася — Олю. В итоге кто-то из эксплуатации решает проблему щелчком мышки — святые люди, я не шучу!
Да, часто только эксплуатация и знает, как реально все работает и насколько это оторвано от презентаций. Переписки с фразой «Посмотрю на следующей неделе» протухают, если не напоминать каждый день. В итоге продукт А получит свой API-метод через несколько месяцев и потратит астрономическую сумму.
Примечательный факт
Продукт Б разработает что-то для продукта А и получит оплату один раз. Но он эта доработка создаст нагрузку на сервера, добавит код для поддержки. Теперь продукт А будет создавать инциденты в адрес Б, если что-то перестанет работать.
Продукт А — сервис самообслуживания (посмотреть баланс). Он надстройка над Б. Таких интеграций уже много, а станет еще больше. Все они будут портить жизнь Б.
Продукт А похвалят за NPS, дадут премию.
А что получит Б? Только головную боль. Увеличение штата для Б не согласуют. Наоборот, попросят сократить при оптимизации. Заинтересованы они в доработках? Вопрос риторический.
Для наглядности — пример с интеграцией
Вы открываете прачечную. Даёте деньги соседу с просьбой купить для вас стиральную машину и поставить у него дома. Вы будете приходить к нему стирать за счёт его воды, электричества и порошка. Зарабатывать деньги (получать премии). Если машинка сломается, сосед ремонтирует за свой счёт. Порошок у него должен быть всегда. Красота!
Попахивает паразитизмом, не находите?
А сколько всё это стоит?
Давайте поверхностно посчитаем, во сколько обходится ежедневная встреча десятка сотрудников на 30 минут? Возьмем самый минимум.
Пусть, средняя зарплата в ИТ ~200к руб
Годовой доход: 2 400 000 руб (200к х 12 мес)
Рабочих часов в 2025: 1 972
Стоимость часа: ~1 217 руб
Рабочих дней: 247
Годовые затраты на встречи 1 человека: 150к руб (247 х 0.5 х 1 217)
У крупных компаний 100+ продуктов. В командах 10-50 человек.
Затраты на команды из 10 человек: 150 млн руб в год (150к х 10 х 100 и это только на ежедневные стендапы)
Добавим планирование, ретро, спринт-ревью и прочую чепуху: ещё ~70-80 млн/год.
Итого на ритуалы: ~220 млн/год
Нашли ли на этих ритуалах решения, приносящие такую же прибыль?
А ведь есть ещё время на переключение между задачами. Исследования говорят, что на микропереключения может уходить до 40% времени.
Если брать продуктовые команды не по 10 человек, а больше, то счет уже идет на миллиарды.
Добавим митапы, воркшопы, пятничные встречи, комитеты, обучения, армию методологов и блюстителей.
Попытки привить культуру, пригласить экспертов, консультантов по эмоциональному здоровью и как не выгореть на работе от трансформации. И ведь чаще всего это не приносит ожидаемого эффекта.
То есть команды работают в прежнем режиме. Но к этому добавились ритуалы, отнимающие время у них время.
Неудобный момент
Забавно видеть, как продукт А показывает, что после трансформации у них изменился лидтайм.
С чего вдруг? Платформы как разрабатывали интеграцию месяц, так и разрабатывают. Витрина без интеграции не может выкатить фичу. Но показатели позеленели. Отличный результат!
И здесь нет никакой магии, просто считать начали не с момента появления идеи, а с момента появления интеграции. Но им не оставили выбора, ведь они не могут повлиять на продукт Б (платформу).
Руководство начинает подозревать, что деньги уходят не туда
Стандартная реакция:
⦁ Надо больше отчётов, дашбордов, метрик и контролёров!
⦁ Надо сокращать операционные затраты и ФОТ!
⦁ Мои сотрудники ничего не понимают, надо их лучше обучать
⦁ Надо, надо, надо!
В результате поверх бюрократии вырастает новая, чтобы контролировать старую.
Но дашборды не покажут такие манипуляции с бюджетом, а если даже и покажут, то люди быстро найдут, как это обойти.
Почему так происходит
Опасения высшего руководства сломать то, что хоть как-то работает.
Нежелание брать ответственность если таки сломается.
Страх потерять власть и работу у руководителей среднего уровня. А они — связующее звено между топами и командой.
Попытка решить всё сразу, просто заплатив деньги консалтингу. Но коучи не погружены в специфику предприятия и натягивают типовые лозунги.
Решения принимаются наверху, как и прежде. Компания хочет трансформации, но боится разжать кулак.
Всякие центры компетенций не слышат обратную связь от сотрудников. Продолжают гнуть свою линию. Кроме того, они сами зажаты в рамки, которые были спущены сверху.
Есть иллюзия успешности других крупных игроков мирового уровня. Но их успех часто связан не с тотальной трансформацией, а с изолированными «анклавами», защищёнными от бюрократии.
Сначала коучи обучают, а потом остаются навсегда, оправдывая свое существование все новыми выдумками.
Чем больше команд участвует в трансформации, тем сложнее их контролировать и тем быстрее они адаптируются в свою пользу. Это — закон самоорганизации сложных систем. Они не саботируют, они оптимизируют (минимизация усилий для максимальной выгоды — премий, спокойствия).
Если ваша продуктовая трансформация начинается с выбора фреймворка — вы на пути к провалу
Читаешь статью, где люди искренне хотели трансформацию внутри команды, начинали так хорошо и правильно. И вот в каком-то абзаце пишут как они выбирали фреймворк по Aglie... Все. Можно дальше не читать.
— Поверь мне, Карлсон, не в пирогах счастье.
Как разорвать порочный круг
Определиться, действительно ли в новой схеме нужны руководители среднего звена (те самые ИванИванычи), когда их качества не подходят для обозначенных ролей. Если да, то чем конкретно они должны заниматься. Понимаю, это неприятный вопрос, но когда начнется оптимизация ФОТ, под нож, в первую очередь, пойдут члены команд — те, которые стоят у станка и несут непосредственную ценность. А среднее звено, скорее всего, так и останется нетронутым.
Не переводить все информационные системы в разряд продуктов. Разделяйте на сервисные и клиентские. Применяйте к ним разные условия.
Начинайте в пилотном режиме. С одного или нескольких продуктов, которые без всяких сомнений подходят под определение "продукта". Постепенно распространяйте опыт (не схему, а опыт). В пилоте уделяйте пристальное внимание метрикам. Избегайте подтасовок и сокрытия неудобных фактов. Цель — запустить продуктовый подход, а не наказать команду. Команда не должна бояться сообщать о неудачах. Наоборот — она должна говорить обо всех проблемах, чтобы можно было вовремя корректировать ситуацию. И говорить она об этом должна тому, кто принимает решения, а не коучу, который не может ни на что повлиять.
У сервисных продуктов тоже должна быть мотивация и ощущение части общей цели. PQI должен учитывать доступность, функциональность, удобство, дизайн. Это нужно измерять и у каждого пункта должны быть разные веса, чтобы команда не увлекалась красотой в ущерб функционалу.
Измерять надо не только мониторингом, но и отзывами пользователей. Сотрудники компании — тоже клиенты. Когда они видят, что бухгалтерский софт стал работать лучше на основании их отзывов, они чувствуют участие и это повышает мотивацию.
Для работ на стыке продуктов (интеграций) должны быть сквозные метрики. Они должны ронять KPI обеих команд, если задача затягивается, чтобы команды быстрее договаривались. Если задача затягивается из-за согласований ИБ, то безопасники тоже должны быть в этой метрике.
Все должны быть максимально собраны в решении задач, от которых зависит скорость поставки ценности клиенту. Личные и командные стимулы должны быть выровнены с этой скоростью и качеством результата, а не с внутренней отчетностью. Если одно из звеньев цепи не настроено на результат, страдает вся цепь.
Заключение
Самая частая ошибка — в первую очередь «натянуть» продуктовую модель на важный, но умирающий проект. «Натянуть», не дав реальных полномочий.
Если есть страх провала, начните с продуктов, где потери от провала минимальны.
Задача — изменить культуру. Но культура не появляется на ровном месте. Она появляется только в рамках правильных ограничений.
Системы (и люди в них) всегда адаптируются к реально действующим правилам и стимулам, а не к провозглашённым целям. Если правила настроены криво — вы получите кривое, но рациональное поведение.
Вспомните сцену из фильма Волк с Уолл-стрит: "Продай мне эту ручку!". Успешная продажа происходит не через перечисление свойств предмета (красивая, надежная), а через создание у покупателя острой необходимости в этом предмете — просьба оставить автограф. Ваши правила должны ставить сотрудников в условия такой необходимости, но в контексте создания ценности бизнесу. Человек должен захотеть решить задачу. Тогда он найдёт такие способы, о которых вы, создавая правила, даже не думали.
Провал происходит на стыке трёх факторов:
Кадровый (не те люди на ролях)
Мотивационный (KPI и премии не связаны с ценностью)
Организационный (старая бюрократия + новые ритуалы = театр)
Если после прочтения этой статьи у вас появилось желание затянуть гайки, всех уволить и вообще... Значит, вы так ничего и не поняли.
