При внедрении в корпорации продуктового подхода и фреймворка для управления инициативами нужно правильно выстраивать систему мотивации людей, задействованных в работе над продуктом. Рассмотрим в качестве иллюстрации несколько стадий фреймворка.
На стадии Ideation нужно заинтересовать людей, которые предлагают идеи.
Иначе может произойти следующее: они придумают идею, у вас ее не реализуют, пойдут в другую компанию, где у них все получится, и, возможно, сразу займут позицию CDTO. Вы их просто потеряете.
Потому что вовремя их не замотивировали, сами не были заинтересованы в том, чтобы они реализовали свою идею, или в реализации идеи поучаствовали.
Проще всего с мотивацией, на стадии Discovery (Исследования).
Методологически дотошные исследователи обожают этот процесс в принципе – не то, чтобы они готовы делать свою работу бесплатно, лишь бы делать, но близко к тому – лишь дайте им что-нибудь поисследовать.
На стадии Design(проектирования) самая сложная мотивация.
Во-первых, она касается финансовой функции, которую надо замотивировать давать деньги. Акционеры и топ-менеджеры должны договориться с CFO об инвестиционной политике, гибком бюджетировании.
Возможно, для этого нужно провести стратегическую сессию, обучение по 6 моделям мышления в корпорации, чтобы руководство «понадевало эти разные шляпы», то есть поняло, что значит мыслить в каждой из систем, чтобы у финансистов появилась мотивация выдавать деньги.
На стадии Develoment (Разработка) у ИТ-разработчиков мотивация делать продукт, как правило, отсутствует, потому что у них другое мышление, инженерное - архитектурой, поиском сложных решений, но они не думают о стейкхолдерах и value proposition, ценности, которую они сгенирируют за первый спринт.
Нет смысла менять их культуру, лучше, если вы хотите, чтоб у вас были быстрые спринты, найти продуктовых разработчиков – с нужной вам культурой, мышлением и мотивацией.
Да, они стоят чуть-чуть дороже, но они себя «отбивают» - поэтому HR не стоит писать для ИТ-разработчиков и HR одинаковые грейды.
И еще очень важно, не мешайте «продуктовикам» работать.
Их не должны постоянно дергать бизнес-заказчики, не нужно практиковать старую модель «я – барин, я - заказчик, я тебе скажу, что делать».
Дайте разработчикам свободу и дайте им проектный офис, PMO, который будет предоставлять им сервис по назначению встреч, напоминаниям, что нужно сделать – так вы избежите расхлябанности и бардака.
На стадии Внедрения (Deploy)очень сложная мотивация информационной безопасности и ИТ в целом.
Дело в том, что ИТ блок, как правило, не PnL ответственный – у него нет KPI от инициатив на их реализации, только если разработчики или Product owners не сидят в ИТ, чего лучше не делать.
Посадите владельцев продуктов в бизнес - если вы посадите "продактов" в ИТ, на них автоматически перейдут все конфликты между ИТ и бизнесом, а это им совершенно не нужно.
Задача на этой стадии так продумать кросс-функциональное взаимодействие, чтобы инициативы внедрялись и не «висели» на безопасности, которой занимается ИТ по полгода или году.
Таким образом, мотивацию людей, вовлеченных в продуктовую разработку, нужно продумывать на всех стадиях фреймворка, предназначенного для управления реализацией инициатив.
Нужна помощь в разработке и внедрении фреймворка для управления инициативами в корпорации? Обращайтесь!
Мы всегда на связи: Telegram, сайт, info@neuromap.tech.