RU UA

Спасибо, ваша задача принята!


Кстати, чтобы быть всегда в курсе событий, приглашаем Вас зарегистрироваться в Facebook в нашей группе “Адизес навсегда”.


До встречи!

С уважением, Людмила Гегельская

и вся команда Института Адизеса


Опишите вашу задачу

4 типичные ситуации которые не решить без проектного менеджмента


Стили менеджмента
25.01.2022
4 типичные ситуации которые не решить без проектного менеджмента

Этот пост был опубликован 25 января 2022 года.

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

В этом материале я рассмотрю несколько типичных ситуаций, с которыми часто сталкивается команда проекта, и покажу инструменты, позволяющие решить эти проблемы. Такие сложности-проблемы у нас принято называть ПИПами, от английского PIP (Potential Improvement Point) - потенциальными точками улучшений, так как любая, нерешенная на данном этапе проблема, по сути, является возможностью для изменения вашего продукта в лучшую сторону.


PIP №1 Исполнители саботируют решение руководителя 

Задача – необходимо создать новый процесс в компании.


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


Ну а далее –  нежелание реализовывать поставленные задачи, которое маскируется под “чрезмерную сложность” или “невозможность исполнения в оговоренные сроки”.


Знакомая ситуация?


В итоге задание провалено, люди, которым поручили выполнение, не справились с задачей.

PIP №2 Конфликт внутри команды  

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


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


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


Участники делают вывод о невозможности продолжения взаимоотношений. В качестве послевкусия - печальный вывод, “что с этими людьми, в принципе, ничего решить невозможно” и “нам с ними не по пути” или “этот тип задач в нашей компании решить невозможно”.


 PIP №3 IT департамент работает как “черный ящик” 

Вы заметили, что многие “обычные” компании по-сути превращаются в ИТ-компании? 


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


А как функционирует IT-департамент такой компании? 


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


Анализ потерь показывает, что большая часть работы, выполненная IT департаментом, отправляется в корзину, так как требования заказчиков, по мере реализации проекта, постоянно эволюционируют и меняются существенным образом. 


Задачи IT департамента - одни из сложнейших в интеллектуальном плане. Как известно программист 80-90% времени исправляет ошибки в коде, но все становиться еще печальнее, если приходится полностью переписывать большие модули разработанные достаточно давно. Кроме полной переработки большого объема кода производительность труда падает еще ниже.

PIP №4 Задержка в разработке новых продуктов  

Компания разрабатывает новые продукты или технологии, отвечает за выполнение работ R&D департамент. Бюджет на R&D априори конечен, а результаты неутешительные. Время упущено, ROI (возврат на инвестированный капитал) низкий, продукты не окупаются, а на разработку новых нет ни времени, ни денег.



Вот вам 4 ситуации, которые мы наблюдаем у многих наших потенциальных клиентов.

Не в наших правилах искать виноватых, поэтому сразу к тому, то можно со всем этим сделать. В практике Synerteam, разработанной доктором Ицхаком Адизесом, для решения ситуаций, подобных PIP №1 и 2, наиболее часто используют 3 основных инструмента для формирования проектных команд: 

  1. формирование взаимодополняющих команд;

  2. распределении полномочий особым образом (принцип CAPI); 

  3. создание и поддержание взаимного уважения и доверия в команде.


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


Например, участники с предпринимательской доминантой (Е) - генерируют идеи;

Ориентированные на быстрый результат (Р) - продумывают детали исполнения;

Критично настроенные (А) - оценивают риски, обращая внимание на не самые очевидные детали;

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

Второе важное правило формирования кросс-функциональной команды это принцип CAPI (coalesced authority, power and influence) (https://adizes.ru/articles_and_video/tpost/386b1tt282-capi) нацеленно на увеличение вероятности внедрения/успешной имплементации решения.


Для разрешения ситуации №2 (глубокий деструктивный конфликт) важно заложить основы соблюдения принципа взаимного уважения и доверия, который хорошо раскрыт самим доктором Адизесом в данном ролике (https://www.youtube.com/watch?v=v6ruD8YvX3s).


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

Для профилактики таких ситуаций нужно поддерживать взаимное доверие в команде, основанное на общих целях и ценностях, а также соблюдать определенные правила коммуникации и другие инструменты совместного принятия решений, о которых мы будем детально говорить на мастер- классе https://events.adizes.me/scrum

Для поддержания культуры взаимного уважения и доверия в работе кросс-функциональной команды нам нужны правила и инструменты. Один из интересных инструментов - Еще одной техникой для повышения качества принятия оптимального решения является QDD (Question, Doubt, Disagree - Вопрос, Сомнение, Несогласие). С помощью этой техники мы проверяем качество предварительно принятых решений, пропуская их через “Вопросы”, “Сомнения” и “Несогласие”.

Как уже было сказано, для поиска выхода из ситуаций № 1 и 2, наиболее эффективны технологии Synerteam, для ситуаций № 3 и 4 это технологии семейства Agile. Самый известный инструмент “семейства Agile”, это SCRUM. Ему отдали предпочтение подавляющее большинство команд в мире в целом, и в России и Украине в частности. Поэтому в дальнейшем мы будем исходить именно из логики применения именно данного инструмента. SCRUM становится “томографом”, делая управление сложным проектом прозрачным, позволяет принимать оптимальные управленческие решения и гибко настраивать основные процессы.


Одним из главных его “фишек” является регулярная встреча команды и стейкхолдеров (ключевых заинтересованных сторон) проекта.


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

Другим важным следствием применения Agile является значительное увеличение потребительской ценности продукта. У стейкхолдеров, как правило, “аппетит появляется во время еды”. Они приходят к пониманию и видению того что им нужно, только на этапе обсуждения частично или полностью работающего функционала продукта. Выявление дополнительных ключевых требований к продукту не в конце, а на ранней стадии, позволяет корректировать планы так, чтобы обеспечить максимальный прирост потребительской ценности продукта. Поскольку все элементы продукта оцениваются на предмет “бизнес/потребительской”-ценности, то, комбинируя элементы, можно увеличивать конечную бизнес-ценность или потребительскую-ценность продукта.

Последняя, ситуация №4 (задержка разработки новых продуктов), как правило, складывается, когда R&D сфокусирован на одном-двум наиболее перспективных продуктах. Но проблема в том, что представление об успешности продукта приходит только в конце периода разработки! Получается, что “наиболее перспективные”, на которые брошен основной ресурс, могут оказаться “совершенно не-перспективными”! 

Современный Agile-подход основан на предположении, что более эффективной будет диверсификация инвестиций на ранней стадии (до 10 - 20 стартовых проектов). Но каждый из продуктов мы разрабатываем только до стадии MVP (Minimum Viable Product), говоря проще “рабочий прототип”.

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

На мастер-классе https://events.adizes.me/scrum вы получите возможность оценить описываемые инструменты, выбрать и освоить наиболее целевые для вашего бизнеса. И, что немаловажно, сверить практику их применения со своим управленческим опытом и здравым смыслом.



Антон Толмаков


Авторские права на данный текст (перевод) принадлежат Институту Адизеса. Перепечатка возможна только с письменного разрешения и при условии наличия ссылки на сайт adizes.me

Возврат к списку

Комментарии

Текст сообщения*

Все статьи