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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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