Об осуществлении стратегии при помощи тактики.

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

Наш процесс продаж ориентирован на работу с топ-менеджментом на стороне клиента. В момент, когда сделка становится более реальной, на сцену выходит, как я его называю, "project execution level" - ПМы (или другие роли) с обеих сторон, ответственностью которых является воплощение стратегических задач, которые поставило руководство. Именно в этот момент главной сложностью является выравнивание участников всех уровней вокруг целей проекта или программы. Должен сказать, что наши сейлы справляются отлично, мы действительно глубоко копаем в бизнес-ценность и программное управление, предоставляем клиентам комплексные решения и не боимся бросать им вызовы. Но иногда чудеса начинаются там, где их не ждешь. Итак, кейс.

У клиента "Рога и копыта" стоит стратегическая тема - радикально преобразить устаревший продукт, чтобы оставаться конкурентным с молодыми стартапами, которые изначально инвестируют в UX. Открытую под эту цель программу полностью отдают нашей команде. И со стороны клиента ее курирует Джон. Проблема в том, что Джон по скиллсету является техническим лидером продукта, а не проектным или программным руководителем.

Сначала Джон выражал свое глубокое неудовольствие нашим желанием общаться с конечными пользователями. В конце концов, он и его руководитель и без этого отлично знают, что должно быть в продукте. Потом его перестало устраивать количество рекомендаций и новшеств, которые мы привносим в процесс разработки, потому что это отвлекает разработчиков от кодирования (для понимания, продукт существовал 5 лет без единого дизайнера в команде). Позже, он начал напрямую вмешиваться в исследовательский процесс, пытаясь навязывать желаемые компоненты в дизайн-систему. Апофеозом такого "менеджмента" стала следующая ситуация:

🈯️ Джон принял решение переформатировать наше участие в программе путем высвобождения наших UX-спецов в пользу внутренних свеженанятых джуниоров;
🈯️ Пока происходила передача проекта, эти джуниоры были определены в другие внутренние проекты;
🈯️ Как итог, Джон рисует вайрфреймы в Миро самостоятельно и хвастается, насколько это легко и просто =). Не нужно лишний раз говорить о качестве этой работы.

Что же, с точки зрения программного менеджмента, Джон делает не так?

㊙️ Джон не имеет компетенций по управлению проектами или программами в продуктовой компании. Конкретнее, он ничего не знает и не хочет слышать о user-centered design, UX research, design thinking.
㊙️ Джон не знает, как встраиваются discovery процессы в общий поток доставки ценности.
㊙️ Будучи проектным/программным руководителем по роли, Джон не считает нужным сверяться со стратегией компании при принятии важных решений.
㊙️ Джон не обновляет/не создает планы, если это продиктовано решениями, которые он принимает.
㊙️ Джона не заботит реализация выгод от программы, которую мы выполняем, он уверен, что программа выполняется "для него".
㊙️ Джон считает, что он все знает в домене и ему нечему учиться.
㊙️ Главная техника приоритезации для Джона - HiPPO (Highest paid person's opinion).

Не будь как Джон.

#beardthink #практика