“User Stories” как эффективный инструмент согласования на стадии роста

Всем привет! На связи Дмитрий Веснянкин и в данном посте я расскажу об опыте использования ИТ-фреймворков в качестве инструментов стратегического и проектного менеджмента.

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

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

Волшебной таблетки, увы, не существует, но все лучшее (почти) уже было когда-то придумано.

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

Один из таких фреймворков называется "User Stories" (пользовательские истории) и представляет собой отражение клиентократичного подхода в разработке программных продуктов (приложений и сервисов).

Небольшой туториал для разогрева.

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

Такой запрос декомпозируется на ключевые составляющие, отражающие:

У каждой функциональной роли в данном случае свой набор мотиваторов.

Таким образом, пользовательская история менеджера по продажам может звучать как: "Я как менеджер по продажам банковских услуг и продуктов хочу получить возможность автоматической синхронизации заявок, поступающих в мессенджеры, с CRM-системой, используемой в банке, чтобы увеличить количество обрабатываемых мной клиентов"

А пользовательская история руководителя отдела продаж может звучать как: "Я как руководитель отдела продаж банковских услуг и продуктов хочу увеличить производительность труда менеджеров по продажам, достигнув за счет увеличения их эффективности роста LTV наших клиентов"

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

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

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

В целом по фреймворку User Stories в Сети можно найти много развернутой информации.

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

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

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

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

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

По порядку и структуре.

Пример формулирования такой стейкхолдерской истории может звучать следующим образом: "Я как руководитель отдела снабжения предлагаю внедрить в логистические бизнес-процессы нашей компании инструменты RFID-трекинга грузов и автомобилей, чтобы на основании аналитики о движении транспорта и работы всех ключевых подразделений, задействованных в сборке, отправке и доставке груза, принимать решение о совершенствовании нашей маршрутной карты, оптимизации цепочки задействованного персонала, тем самым сокращая срок поставки, а также ряд переменных и постоянных затрат"

Такая история, отражающая функциональный запрос и управленческую мотивацию, раскладывается по формуле:

Дьявол в деталях (в мотивации).

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

В случае, когда руководитель предлагает изменения, бизнес-результат которых не связан с установленным, мотивирующим деятельность этого управленца KPI/OKR, мы как собственники бизнеса или ТОП-менеджеры должны реагировать на это, как на поле для проработки новых мотивирующих стимулов, созвучных бизнес-результату.

В случае, когда бизнес-результат связан с системой мотивации, мы можем похвалить себя за эффективное выстраивание параллели: мотивация собственников - мотивация руководителей.

Почему это важно? Потому что только при правильной мотивации история будет завершена. И именно поэтому формат такого описания и последующего согласования называется прежде всего историей. История должна быть завершена. В контексте бизнеса - история должна быть завершена успешно.

Как это работает в согласованиях?

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

1. первый столбец отражает функциональную роль автора инициативы
2. второй столбец отражает предложение, желаемое изменение, запрос
3. третий столбец отражает видение и ожидание итогового результата

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

А как понять, что из получившегося массива имеет ценность, а что является шумом, проявлением низкого понимания стратегии компании, слабых компетенций или имитацией (а как же без этого) деятельности?

На помощь нам приходит известный все в тех же ИТ-кругах фреймворк приоритизации RICE, где:
1. R (reach) - отражает охват, является валидационным коэффициентом полезности, ценности для сотрудников компании от потенциального изменения
2. I (impact) - показывает влияние предполагаемого изменения на бизнес, на ключевые метрики, определенные стратегией
3. C (confidence) - отражает нашу уверенность в том, насколько качественно мы способны реализовать тот или иной проект (в ряде случаев является репутационным коэффициентом, подсвечивающим соответствующие риски)
4. E (effort) - показывает степень затрат, необходимых для реализации проекта изменения

Функциональные руководители, предлагая те или иные проекты изменений, проходят путь приоритизации по простой математической формуле: (R*I*C)/E

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

Такая таблица помогает ТОП-менеджменту оценить с позиции быстрого helicopter view стратегические и тактические инициативы, уровень погружения и компетенций функциональных руководителей, соответствие системы мотивации заданным стратегическим целям.

Таким образом, ТОП-менеджмент сможет понимать истинную суть запроса на изменения, влияние результата на метрики бизнеса, что существенно ускоряет процесс согласования.

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

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

Всем крутых проектов!

P. S. Шаблоном с описанной структурой могу поделится по запросу.