Прежде чем перейдем к сути вопроса - небольшой анонс.
Кому интересно еще немного поговорить про компетенции менеджера проектов - приходите на открытый Welcome-вебинар Базового курса в среду 3 июня - там мы попробуем поговорить про ступени профессионального роста для руководителя ИТ-проектов.
Кто собрался на воркшопе и что происходило?
Подобный онлайн-воркшоп был для Инфостарта своеобразным экспериментом, мы сами были не уверены, что получится.
Получилось плодотворно и насыщенно, не смотря на то, что большая часть участников была готова общаться только в чате, а не голосом (как я, честно говоря, надеялась). Но в правильно организованном пространстве текстом тоже можно вести обсуждения и находить ответы. Краткое резюме: общая доска - это крайне удобная вещь для групповых дискуссий, всячески рекомендую! Правда, честно скажу, нет ощущения, что за полтора часа мы составили именно полную карту компетенций руководителя проекта. Но составили некую картинку - на что обратить внимание в первую очередь? Для меня, как для ведущего курса по управлению проектами на Инфостарте, это было еще очередной сверкой, насколько то, чему мы учим на курсах, совпадает с запросом сообщества на знания и навыки? Спойлер - пока кажется, что более менее совпадает.
В воркшопе приняло участие несколько десятков РП Инфостарта. На этой диаграмме видно, что большинство участников считает себя опытными руководителями проектов, при этом стаж работы у всех варьируется - от нескольких месяцев до многих лет (зеленым цветом отмечали себя представители франчайзи, красным и желтым - те, кто ведет внутренние проекты)
Мы выбирали ключевые навыки в шести разных группах, а потом свели самые важные результаты всех групп воедино. Как это часто бывает на подобных воркшопах, результат довольно неплохо показывает общие представления о том, что является самым главным. И здесь самое интересное на мой взгляд - обратить внимание на те компетенции (совпадающие или похожие), которые назвали самыми важными сразу несколько групп. Именно про эти умения я и хочу здесь поговорить в первую очередь.
Падаван. Начинающий РП. Без каких компетенций не стоит вообще идти в руководители проектов?
Умение вести документацию и писать убедительные отчеты.
Без этого действительно никуда. Некоторое формальное требование к руководителю проекта, без которого его странно назвать руководителем.
Честно скажем, в разных организациях РП оказываются в разном положении. Я бы сказала, что здесь может быть три варианта:
1) Документирование в компании ведется по принципу “как получится”, шаблонов и регламентов как таковых нет. От РП ждут, что он сам сообразит, каким образом следует вести отчетность. В такой ситуации “умение вести толковую документацию” - некий сакральный трудно формализуемый навык, требующий большого житейского опыта (либо обучения). Если вы жалуетесь на нехватку кадров и ощущаете что “некому передать управление проектами” - подумайте, насколько порядок ведения проектов в вашей организации представляет собой технологию, которую можно передать - и если пока нет, то подумайте, как можно двигаться в этом направлении. Если у начинающего руководителя проекта будет простой чек-лист, что ему нужно сделать, какие документы подготовить - рост новых кадров упростится, проверено.
2) Хорошо, когда в компании есть толковые регламенты и шаблоны, помогающие ситуацию мониторить. Собственно, начинающему руководителю проектов как раз проще работать и расти именно в этой ситуации. В этом месте компетенция “умение вести документацию по проекту” волшебным образом превращается из труднодостижимой и сложной в более менее рутинную и понятную. Правда, один раз нужно вложиться как следует - шаблоны документации разработать (и потом периодически сверять, насколько они удобные и работоспособные - без этого почти гарантированно получится что-то странное, увы). Причем профессиональный рост здесь происходит более менее сам собой - чем больше отчетов составляешь и корректируешь по итогам полученной обратной связи, тем их качество постепенно становится выше.
3) Печально, когда документация призвана в первую очередь производить впечатление на заказчика, и имеет смутное отношение к действительности. (Увы, я встречала такие истории у крупных франчей, когда заметная часть работы аналитика и технического писателя была направлена на создание иллюзии проведенной для заказчика работы в том месте, где на самом деле используются базовые компоненты прикладного решения. Здесь навык смещается в сторону “создавать иллюзию и производить впечатление”. Это вряд ли то направление, в котором хочет развиваться уважающий себя специалист, поэтому призываю всех стремиться в сторону второго варианта.
Как можно учиться вести документацию?
- 1С в рамках ПрофКейса предлагает технологии управления проектами (1С:ТБР и 1С:ТКВ), которые теперь доступны не только франчайзи, но и для ИТ-отделов. На мой взгляд они чаще всего избыточны, но из них вполне можно “выковырять” то, что будет вашей компании полезным.
- В рамках “Базового курса” мы говорим про минимальный комплект документов (Устав, описание содержания, реестр заинтересованных сторон, матрица ответственности и др.). В рамках “Продвинутого курса по классическим методам управления (PMBoK)” каждый участник может выбрать и составить комплект документов, подходящий для управления проектами в его компании (бизнес-кейс, реестр рисков, план управления проектом, диаграммы контроля качества и т. п.)
Знание прикладных решений
Здесь тоже все примерно понятно. Без знания матчасти управление проектом будет являться профанацией идеи. На практике встречается ситуация, когда команду технических специалистов направляет специалист именно в управлении. Но, во-первых, это не история начинающего РП, во-вторых чаще всего получается что-то странное. “Взлететь” комбинация управленца и технических специалистов по моему опыту может только если управленец внимательно прислушивается к мнению команды, а не пытается ее “строить”. Причем важно наличие в команде грамотного технического лидера (пока не готового быть руководителем проекта в силу личностных качеств), который советует управленцу что делать, и тот его слушает.
Но это все-таки исключение, которое подтверждает правило. А на самом деле никто не спорит, что матчасть знать, конечно же, надо.
Как изучать прикладные решения?
- На Инфостарте в разделе “Курсы” можно найти различные курсы от 1С и не только по прикладным решениям. Но, конечно же, лучший вариант когда параллельно с изучением курса есть возможность решать практические задачи.
- В ходе дискуссии было озвучено, что хорошо помогает ставить и реализовывать цели составленный план развития сотрудника: прикладное решение+сроки получения сертификата 1С, курсы, которые предлагается завершить и т. п.
Как можно проверять знание прикладных решений?
Самым простым инструментом, подтверждающим знание той или иной конфигурации являются сертификаты от 1С.
- Хотя, честно скажу, сдав сертификат 1С:Профессионал по ERP я испытала некоторое разочарование: у меня не осталось ощущения, что тест проверил мое умение работать с конфигурацией. Существенная часть вопросов была скорее на способность вызубрить ответы. Если вопросы из серии, скажем, как связаны маршрутная карта и ресурсная спецификация я еще могу понять - здесь для ответа важно понимать внутреннюю структуру конфигурации. То каким образом знание, сколько, допустим, есть пунктов в том или ином меню, продвигает меня в умении пользоваться этим прикладным решением я не могу никак...
- Сертификат Специалист и Специалист-Консультант показывает компетенции существенно лучше, ибо требует довольно серьезного практического опыта. Хотя тоже не идеален.
- Впрочем, альтернатива, если вас не устраивают экзамены от 1С - внутренний экзамен, существенно более энергоемкое мероприятие.
Развитие себя и команды
Следующая серия компетенций, необходимых начинающему РП может быть озаглавлена как развитие себя и команды - контролировать свои эмоции, уметь хвалить и вдохновлять, проводить конструктивные совещания.
Про тему контролировать свои эмоции хочу сказать несколько слов отдельно.
Дело в том, что в качестве руководителя проекта часто ставят человека, хорошо показавшего себя в роли технического специалиста, и рекомендованного поэтому к повышению.
При этом очень часто в роли руководителя оказываются люди, которым ближе и комфортнее работать не с людьми (есть такая градация в сфере профориентации - см. схему. Работа программиста здесь, скажем, явно относится к категории “человек-знаковая система”).
Если человек при этом не развивается как руководитель, то, в соответствии с принципом Лоуренса Питера («В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности») человек так и остается в некомфортной для себя роли.
И если вы оказались как раз в такой ситуации, то возникает вопрос - как развивать ту самую эмпатию, эмоциональный интеллект и т. п. если их вам, по ощущениям, изначально выдали недостаточно? Из рекомендаций в рамках воркшопа мне больше всего понравился совет в формулировке “качать коммуникационную мышцу” (как можно больше взаимодействовать с коллегами, подрядчиками, топами, пытаться разрешать конфликты, воспитывать в себе эмпатию и пр.). Важно осознание причин возникновения эмоций в конкретных ситуациях, поведенческий анализ со стороны специалиста
Как можно развивать эти компетенции?
- На Инфостарте проводятся курсы по ведению переговоров от Дмитрия Коткина, они позволяют как раз “прокачать коммуникационную мышцу”
Добавлю еще, что мне в качестве основы того, как “коммуникационную мышцу качать” нравится квадрат Гоулмана. Мы его разбираем на курсе, ибо здесь важно помнить про то, что начинается развитие эмоционального интеллекта с осознания своих эмоций. Потом стоит двигаться в сторону понимания эмоций других, и только научившись хорошо понимать других и контролировать себя, можно мечтать про то, чтобы влиять на эмоции коллег. В рамках Продвинутого курса по Agile мы разбираем качества, которые помогают вдохновлять и мотивировать команду (я обычно формулирую это как “Быть Скрам-мастером”, потому что как цензурно перевести на русский английский термин Servant Leader я придумать не могу).
Рыцарь-джедай. Какие компетенции необходимы, чтобы РП можно было считать опытным?
Умение разрешать конфликты
Конфликты, как известно, это не временное зло, а неизбежное следствие рабочего взаимодействия. Так что хочу сразу вас успокоить - конфликты на ваших проектах будут обязательно. Весь вопрос, насколько получится вместо того, чтобы развалить с их помощью команду, обратить их на благо проекта.
На воркшопе мы попробовали обсудить - а как оценить, насколько руководитель с конфликтами справляется? Самый простой способ измерения - сам по себе позитивный результат: если Заказчики удовлетворенные, команда сплоченная, нет текучки кадров, конфликты не влияют на проект - значит, все ок. Правда, честно скажем, нам трудно судить: все хорошо благодаря заслугам руководителя, или безотносительно от его поведения? Впрочем, на практике оно и не всегда важно… Ну, а если хочется понять, насколько умеет работать с конфликтами данный руководитель - можно воспользоваться техникой получения обратной связи (встречаясь один на один с членами команды). Вообще, мониторинг в динамике отсутствия обид, замечаний, претензий позволяет понять общий фон в команде (только не надо использовать этот критерий для KPI у РП - иначе команда будет делать покерфейс, и эффект от мониторинга будет исключительно обратный - конфликты будут замалчиваться и скрываться).
Уметь добывать ресурсы
В каждой компании под этим словосочетанием понимается что-то свое, но ресурсы в проектах больная тема практически в любой организации.
Если на прошлом уровне начинающего РП мы говорили про работу с уже готовой командой, то для опытного руководителя чаще всего требуется более деятельное участие в том, чтобы эту команду сначала создать.
В первую очередь (если не брать найм на работу новых сотрудников, мы его рассматривали как отдельную компетенцию), это умение складывается из двух:
1. Умение определять компетенции необходимых ресурсов
2. Умение оправдывать необходимость в ресурсах
Что потребуется от РП для успешного добывания ресурсов?
Итоги обсуждения показали, что это в первую очередь:
- Умение обосновывать затраты на проект.
- И, кроме этого, умение показать руководству, что если людей выделить, то результат будет существенно лучше, чем если пытаться долго и мучительно решать задачу негодными средствами.
- Что еще важно - важно уметь распределять работы между имеющимися сотрудниками, чтобы оптимизировать те ресурсы, которые есть.
Как развивать умение добывать ресурсы?
- В первую очередь практикой. Ну и плюс развитием коммуникативных навыков (см. выше про развитие себя и команды)
- Полезный инструмент для оптимизации ресурсов и обоснования - это матрица ответственности. Про матрицу RACI немного рассказывает Иван Селиховкин в своем курсе по управлению проектами, опубликованном в виде серии статей на Инфостарте (ну а подробно мы ее разбираем и практикуемся в рамках уже упомянутых выше онлайн-курсов по управлению проектами)
Проводить совещания, в первую очередь - ретроспективы (сбор извлеченных уроков)
Что характерно, проведение совещаний на воркшопе упоминали среди ключевых компетенций у начинающих РП, а проведение ретроспектив - у РП-гуру. Что логично - ибо совещания - неизбежный аспект руководства, а умение собирать извлеченные уроки - признак мастерства. Так что если взять нечто среднее - можно принять, что проведение совещаний и ретроспектив - необходимый навык для опытных РП .
Как можно проверить, что РП умеет ретроспективы проводить?
Формальный критерий - наличие по их итогам планов действий, изменений, улучшений при согласии команды. Еще один формальный - что команда готова сотрудничать с таким руководителем (увы, я видела ситуации, когда команда реально “сплачивалась против Agile-коуча, который мешал работать” - это, конечно, сводит к минимуму всю потенциальную пользу от проведения ретроспектив).
Как можно проверить наличие этого навыка? Что касается совещаний, то здесь в первом приближении все более менее очевидно - важно, чтобы у совещаний была повестка, был протокол, и цели совещаний не только ставились, но и достигались. Если копать глубже, то важно обеспечить, чтобы польза от совещаний превышала затраченное время (увы, в моей практике такое бывало далеко не всегда). Мне нравится подход, когда все совещания длятся не более часа - ибо если проблему не получилось решить за час, то дальше сидеть скорее всего бессмысленно, и стоит, как минимум, разойтись, спокойно подумать и “перезагрузиться”.
Как можно развивать навык проведения совещаний?
- Мы разбираем его в рамках Продвинутого курса по Agile - отдельное занятие посвящено проведению демонстрации и ретроспективы, в том числе с возможностью практикума для желающих.
Продолжение итогов воркшопа - компетенции “Мастера-джедая” - будет в следующей публикации - а то, кажется, я слишком растеклась мыслью по древу...
И еще раз приглашаю на Welcome-вебинар в среду 3 июня.
