Фреймворк для управления инициативами помогает быстро продвигать их от идеи до прибыли, разрешать блокаторы, мешающие этому продвижению. И важно понимать, что возникшую в реализации инициативы проблему неправильно постоянно решать на той стадии, на которой она появилась.
Фреймворк является системным инструментом – case by case систематизируются возникающие типовые блокаторы и разрешаются, в том числе, превентивно – то есть вы основываетесь на данных и при необходимости меняете модель в тех частях, в которых возникают стопоры.
Важно понимать: решая блокатор, связанный с одной инициативой, вы работаете не над одной инициативой. Вы работаете над корпоративным, кросс-функциональным фреймворком всей компании.
Это значит, что на каждой из стадий, чтобы достигнуть Time to market и P&L, вам придется менять взаимодействие абсолютно разных функций. Возможно, например, вы обнаружите проблему: разработчики не умеют работать спринтами, по полтора года «пилят» решение, вы решаете эту проблему, вносите найденное решение во фреймворк, и в следующий раз такие проблемы уже не возникают.
Рассмотрим пример блокатора на стадии Deploy, конкретный кейс.
Был запущен пилот, «задеплоен» в операционную деятельность, в итоге этого возникли блокаторы в виде негативных NPS и CSI, вплоть до того, что начался отток пользователей внедренного решения.
Но при этом Time to market на Development, на разработке решения, составил 2 года. Это явно проблема не Deploy, а другой стадии, Develoment!
Если бы практик выбрал правильную методологию Development, запустил пилот на early adopters, потенциальных пользователях, условно, 20 людях, некой целевой аудитории, дружелюбной к продуктовой команде, которая видела бы решение каждые три недели - в виде картинки, кнопочки, не полностью запрограммированного решения - они бы участвовали в продуктовой практике демо, в рамках которой команда показывает инкремент, промежуточный результат, итоги были бы другими. Команда получила бы фидбэк спустя три недели после начала разработки, а не через 2 года – о том, что что-то не так.
И тогда на Deploy, возможно, внедряли бы не целое приложение, а, например, какую-нибудь фичу, новую функцию в текущем рабочем инструменте и так далее.
Возможно, и Discovery было проведено неправильно – оно, в принципе, не может длиться 2 года.
На пилоте необходимо сформулировать DoD (Definition of done), сделать минимальный функционал, убедиться, что это то, что нужно, получив обратную связь от пользователей и уже потом наводить красоту и удобство в сделанной фиче.
Еще одна проблема Внедрения может быть связана с отсутствием финансовой мотивации функции, в которой продукт внедряется (если говорить о внутренних продуктах) – людям просто невыгодно пользоваться этим продуктом, из-за него они будут терять в деньгах, например. Т.е. на стадии Проектирования решения должна быть продумана эта финансовая мотивация – а об этом не подумали.
Таким образом, пропуская инициативы через стадии фреймворка, вы постепенно будете менять компанию – не резко, а последовательно, на основе кейсов.
Нужна помощь в обучении топ-менеджмента и "продактов", цифровой и продуктовой трансформации?
Мы всегда на связи: Telegram, сайт, info@neuromap.tech.
