1-ую часть статьи можно прочитать здесь.
Это статья-размышление - она скорее не дает инструкции, как надо работать, а предлагает задуматься - а что из этого я умею?
Также как и в прошлый раз, буду рада продолжить тему очным разговором на вебинарах и курсах. Ближайший разговор состоится в четверг 10 декабря в 12:00 на открытом вводном вебинаре Продвинутого курса по PMBoK.
Задача 7. Учитывать и устранять препятствия для команды
- Определять критичные препятствия
- Приоритизировать критичные препятствия
- Использовать окружение для внедрения решений по устранению препятствий
- Постоянно продолжать оценивать, все ли препятствия устранены
В прошлой статье я уже рассуждала про роли “менеджера” и “лидера”. И про идею “лидера слуги”. Короче, все большее внимание приобретает концепция руководителя, который вместо того, чтобы “строить” свою команду, занимается тем, что создает для нее подходящие условия.
Натыкалась когда-то на просторах Интернета на историю (сейчас попробовала найти - не нашла, кто найдет - поделитесь!) про директора типографии, который явно говорил своим подчиненным, что мои главные обязанности - чтобы у вас всегда были в наличии туалетная бумага и бумага для печати… И работала при нем типография существенно лучше и четче, чем при его преемнике, который занимался микроменеджментом.
Теперь давайте разберемся, а что же такое эти самые “препятствия”?
Кстати, этим словом я перевела целых три понятия, упомянутые в английской версии описания содержания экзамена: impediments, obstacles, and blockers
Что может быть в роли препятствий? Все что угодно. То, что мешает команде двигаться дальше. Например, из моей свежей практики, это могут быть, скажем:
- Баг от 1С, не позволяющие реализовать требуемый пользователю функционал
- Отсутствие доступа для удаленного подключения к серверу бизнес-заказчика
- Сломавшееся оборудование
- Неподписанные документы
- Не идущий на контакт и вечно занятый владелец продукта/функциональный заказчик
(Список можно дополнять бесконечно)
Так вот, идея списка компетенций как раз про то, что главная задача руководителя - это помогать с теми препятствиями, с которыми команда сама справиться не может.
А посильные трудности - это не трудности, это так, из серии - то что нас не убивает - делает нас сильнее… На этом месте интересный вопрос, как определить: является ли препятствие критичным? Простой ответ: находится ли устранение этого препятствия в зоне влияния команды?
Вообще, деление по зонам влияния (то есть по тому, кто может исправить те или иные сложности) я бы определила следующим образом:
Ну и задача РП - не лезть в то, что посильно команде. Но при необходимости устранять мешающие препятствия, эскалировать наверх или привлекать к этому процессу заинтересованных сторон.
Задача 8. Уточнять проектные договоренности
- Анализировать границы, в которых могут быть уточнены договоренности
- Оценивать приоритеты и определять конечные цели
- Проверять, что цели проектных договоренностей достигнуты
- Участвовать в переговорах по договоренностям
- Определять стратегию переговоров.
Умение договариваться - это отдельная тема. Мы целые вебинары и практикумы проводим с целью моделирования различных переговорных ситуаций.
Скажем, многим франчам знакомая история, когда условием клиента является подписание актов в конце проекта. Мол, руководство хочет получить конечный результат, и не готово платить за то, что его не устраивает. “Когда будет так, как я хочу - тогда мы заплатим”. (Кстати, интересен ваш опыт - как можно взаимодействовать в подобной ситуации?)
Что самое важное при ведении переговоров?
Если в двух словах:
Оптимальный вариант - когда обе стороны готовы к взаимодействию в формате Выиграл-выиграл. И кроме цели “добиться бизнес-результата” еще и фигурирует цель “сохранить рабочие отношения”
Важно понять позицию и мотивы собеседника, и разговаривать исходя из них
К переговорам нужно готовиться. Стоит понять свою позицию и интересы, позицию собеседника
Важно заранее придумать и предложить собеседнику разные варианты действий в той или иной ситуации, то что называется BATNA - best alternative negotiation agreement - лучшая альтернативная договоренность по итогам переговоров.
Задача 9. Сотрудничать с заинтересованными сторонами
- Оценивать потребности по вовлечению заинтересованных сторон
- Находить баланс между потребностями и ожиданиями заинтересованных сторон и целями проекта
- Создавать атмосферу доверия и направлять заинтересованные стороны к достижению целей проекта
Для меня очень показательны в плане взаимодействия с заинтересованными сторонами итоги курсов по управлению ИТ-проектами. Мы на выходе собираем “копилку”, какие инструменты им показались наиболее важными и полезными - и большинство признает, что инструменты работы с заинтересованными сторонами (реестр, матрица влияния, план вовлечения) оказались полезными и их будут применять в дальнейшем (см. пример матрицы в действии).
Задача 10. Создавать взаимопонимание
- Анализировать ситуацию и определять основную причину недопонимания
- Анализировать позиции всех сторон для достижения консенсуса
- Поддерживать принятые договоренности
- Предвидеть потенциальные недопонимания
По моему искреннему убеждению, у современных подходов к поиску взаимопонимания, ноги растут еще от метода “Грозовая туча”, придуманного Голдраттом. В чем суть метода? Мы обостряем противоречия, и понимаем, в какой именно исходной предпосылке кроется первопричина конфликта.
И дальше пытаемся разобраться: а действительно ли здесь есть неразрешимое противоречие? Очень часто оказывается, что многие посылки на самом деле не являются истинными. И то, что кажется противоречием - перестает им быть, если вникнуть в ситуацию глубже, и уточнить исходные предпосылки сторон.
Пример из статьи Евгения Панина с habr.
Задача 11. Вовлекать и поддерживать виртуальные команды
- Выяснять потребности членов виртуальных команд (связанные с окружением, географией, культурой, глобальные и т. п.)
- Находить альтернативные пути (инструменты коммуникации, совместное расположение и т. п.) для вовлечения членов виртуальных команд
- Внедрять опции, способствующие включенности виртуальных членов команд
- Постоянно оценивать эффективность включенности виртуальных членов команд
Если честно, за “год Летучей мыши по китайскому календарю” столько говорилось на тему виртуальных команд, что я уже ничего не хочу здесь писать, чтобы не оспаривать лавры Капитана очевидность.
Пожалуй, только хочу еще раз напомнить, что работать с уже зрелой командой профессионалов виртуально можно практически столь же эффективно, что и очно. А вот развивать людей и складывать команды в “виртуальной реальности” куда сложнее. И обмен опытом и взаимное обучение идет куда хуже - надо какие-то специальные меры для этого применять. Например, мы практикуем какие-то мастер-классы и семинары, проводимые коллегами друг для друга - где люди делятся своим практическим опытом (как на текущем месте работы, так и на других).
12. Определять командные договоренности
- Обсуждать организационные принципы с командой и внешними заинтересованными сторонами
- Создавать окружение, которое способствует приверженности командным договоренностям
- Исправлять ситуацию в случае нарушения договоренностей
Одно из понятий, утащенных мною из литературы по проектному управлению в реальную рабочую практику - это Устав команды (team charter), упомянутый первый раз во втором пункте. Не путать с Уставом проекта, вообще ничего общего.
Так вот, Устав команды - это очень классная штука. Это командные договоренности про то, как наша команда работает. Каким образом назначаются задачи, когда проводятся совещания, какие часы обязательны для посещения, каковы критерии выполненной работы и так далее. И важно, чтобы эти договоренности определяла и придумывала команда. Потому что, как гласит первый закон фасилитации,
Люди гораздо охотнее исполняют решения, принятые с их участием.
Задача 13. При необходимости выступать в роли наставника для заинтересованных сторон
- Выделять время для наставничества
- Замечать и использовать возможности для наставничества
На тему “роли руководителя проекта” я всегда предлагаю взять на вооружение текст про “6 шляп Agile-лидера/Скрам-мастера”. На тему поведения в разных ситуациях на последнем митапе “Гибридные методы управления проектами” хорошую метафору привел Павел Алферов: руководителю проекта важно, во-первых, как хорошему охотнику иметь с собой в патронташе большой набор разных патронов - на все ситуации. А во-вторых, уметь наиболее подходящие патроны для каждой ситуации грамотно выбирать. Так вот, роль “наставника” - это как раз один из таких “патронов”.
Задача 14. Увеличивать эффективность команды с помощью эмоционального интеллекта
- Понимать поведение при помощи индикаторов личностных особенностей (personality indicators)
- Анализировать индикаторы личностных особенностей и подстраиваться под эмоциональные потребности ключевых заинтересованных сторон проекта.
Про этот пункт тоже не буду распространяться слишком подробно. Вряд ли найдется человек, который будет спорить с тем, что эмоциональный интеллект руководителю проекта необходим, и что к каждому сотруднику нужно подбирать свой собственный “ключик” (см. мою любимую книгу на эту тему “Как пасти котов” Дж. Ханк Рейнвотер). Что помогает в этом направлении продвигаться? Мой опыт показывает, что в первую очередь это три вещи:
- Во-первых, практика - в том, чтобы понять и почувствовать других людей, учиться с ними взаимодействовать.
- Во-вторых, фокус внимания - осознанно следить за состоянием и поведением других людей и учитывать его.
- В-третьих, обратная связь - проверять, насколько мои предположения и предложения были комфортны окружающим.
В качестве заключения - полный список компетенций "про людей" с пометками по итогам нашего вебинара-дискуссии: красным цветом отмечены "самые больные", зеленым цветом - "самые важные".
Достаточно ли этих компетенций для руководителя проекта? Нет, конечно. Проверке компетенций, которые я здесь написала, посвящено чуть менее половины вопросов экзамена. Остальное - это процессы (управление изменениями, передача знаний, управление расписанием и так далее) и бизнес-окружение (оценивать выгоды проекта, поддерживать изменения в организации и так далее). Но это тема отдельного разговора…
Приходите на открытый вебинар (отвечу на вопросы по курсу, про программу сертификации на PMP, и, традиционно, разберем несколько кейсов из опыта участников), записывайтесь на Продвинутый курс по управлению ИТ-проектами!
Источник содержания экзамена на английском языке. Вольный перевод с английского мой, не судите строго ))). Рассуждения на тему - не перводные, а мои.
