Цифровая трансформация без хайпа

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

Я сейчас работаю в большой компании, где как раз идёт ЦТ и хочу поделиться своим видением.

Вот моя формула продуктового подхода:

Цифровая трансформация без хайпа

Зачем нужна ЦТ большим компаниям?

Давайте начнём с начала. Зачем это бизнесу? Бизнес хочет чтобы было быстрее и дешевле (собственно всегда так и было) и, в современном мире, «быстрее и дешевле» часто может быть за счёт продуктового подхода.

Раньше, чтобы сделать «хорошо», надо было взять какой-то процесс и наладить его его: расшить «узкие горлышки» (привет Голдратту) и выстроить эффективную цепочку согласовав все правила игры. Этот подход никто не отменял, но в современном мире, где большое количество изменений, на момент, когда мы выстроили процесс, оказывается, что его надо менять. Всё осложняется тем, что процессы связаны и всё это нужно согласовывать с ответственными за смежные процессы…

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

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

В большой организации — это может быть корпоративный портал или обеспечение питанием сотрудников (почему нет?). Тут главное, что Владелец продукта сконцентрирован на повышении эффективности этой функции и отвечает за неё целиком.

В чём же особенность?

  • Команда максимально независима (имеет в составе всех необходимых участников). Это сложно в больших компаниях, т.к. невозможно собрать у себя специалистов по всем системам (если их 200+). Тут нам в помощь микросервисная архитектура (чтобы не надо было копаться в каждой системе), но с этим не просто когда много легаси.
  • Результаты должны быть измеримы. В больших компаниях, где десятки продуктов, проектов и разных процессов сложно понять как один конкретный продукт влияет на деньги компании. А строить пирамиды метрик задача не простая, но решаемая.
  • У владельца продукта (ВП) должны быть все полномочия (в т.ч. распоряжаться бюджетом). Ну тут без комментариев.
  • Большая компания живёт в больших процессах и «быстро» что-то поменять для конкретного продукта не всегда «быстро».
  • Все привыкли к проектам и перестроиться нужно на всех уровнях. Хорошо, если есть поддержка ТОП-менеджмента.

Преимущества продуктового подхода

Давайте поговорим о преимуществах.

  • Продуктовая команда делает то, что нужно сейчас.

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

Например: Ваша услуга — продажа велосипедов. И вот, случилась эпидемия и все перешли "в онлайн". В обычной ситуации надо составить план, проанализировать и согласовать с собственником/директором/начальником изменения в бизнес-модели (ну и вообще всё не плохо бы согласовать и защитить).

Продуктовая команда не будет тратить на это время и постарается быстро создать и проверить гипотезы: а что если мы введём доставку с возможностью посмотреть несколько моделей рядом с домом? А может продавец будет в режиме видеочата общаться с клиентом? А если мы будем продавать модельки и менять их когда люди выйдут с карантина (для тех кто хочет что-то физическое или сделать подарок прямо сейчас), А что если… Когда команда нащупает путь "как выполнить показатель — продажи", то просто будет прямо сейчас делать то что нужно и забросит то что было запланировано ранее, даже если это было анонсировано "на самом верху". И для этого не надо ничего кроме понимания всеми участниками цели и наличие нормальной мотивации.

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

  • Продуктовая команда может ошибаться (но это стоит дёшево), но получить «сверхрезультат» на рискованных гипотезах.

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

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

  • Продуктовая команда не галлюцинирует, а делает то что нужно пользователю.

Продукт строится вокруг 2х вещей (очень крупно): стратегии компании + пользователь.

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

Продуктовый подход подразумевает постоянный диалог. Появилась идея — поговорили с пользователями (привет CustDev). Идея кажется "норм" — сделали макет. Макет "зашёл" — сделали прототип. Прототип понравился — сделали минимальный жизнеспособный продукт (да, не красивый, без половины функций, но работающий). Пользователи используют им нравится идея — идём дальше. На каждом этапе должен быть диалог с потребителем.

В проектах обычно аналитики всё прорабатывают, продумывают, а потом оказывается что всё надо было сделать не совсем так… или совсем не так… но проект уже сдан и приходится пользоваться тем что есть (кому повезло — можно не пользоваться). В продукте не так.

Прототипы и быстрая проверка гипотез — это основной ключ к успеху.

  • Продуктовая команда даёт быстрый результат, а не сдаёт «готовый продукт в конце»

Я об этом писал в п.3. Как показала практика, можно остановиться на проработке уровня: «20% усилий даёт 80% результата».

Мир меняется, всем нужно быстро сделать нужную функцию, а «бантики» часто не нужны и функции которые разрабатываются неделями, а вручную делаются за секунды - это не то, на чём нужно концентрироваться когда "только начали раскопки и впереди ещё много нефти".

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

Резюмируем что же такое продуктовый подход?

  1. Это здравый смысл + много модных терминов. «Вторая» часть не обязательна :)
  2. Единый фокус на цели Владельца продукта и команды (и "сквозные" KPI)
  3. Эксперименты. Быстрая проверка гипотез и готовность к неудачам
  4. Коммуникации на всех этапах и открытость информации для всех
  5. Цифры и метрики. Мы не можем постоянно улучшать процесс без понимания как было «до и после» изменения.

Когда не получается цифровая трансформация

  1. Продакт — не продакт. Если владелец продукта не имеет полномочий, не умеет продавать и отстаивать своё мнение.
  2. Нет измеримых показателей. Любой продукт должен иметь измеримые бизнес-показатели и метрики связанные с этими показателями. Любая фича должна иметь измеримые показатели эффективности. Иначе мы делаем работу ради работы.
  3. Нет готовности инфраструктуры и возможности сформировать самодостаточную команду.
  4. Нет готовности меняться у большинства сотрудников в компании.
11
1 комментарий

Нормальная статья, кстати. Странно что не зашла никому четыре года назад )

Ответить