Выше я уже начала подводить итоги онлайн-воркшопа “Путь джедая”, прошедшего в конце мая на Инфостарте в преддверии старта Комплексного курса по управлению ИТ-проектами. Мы уже разобрали без чего не стоит вообще идти в РП, и чего нужно уметь, чтобы считаться опытным руководителем проектов.
Мастер-джедай. Какие компетенции нужны ведущему руководителю проектов?
Уметь работать с командой проекта - причем на этом этапе я бы даже добавила “виртуозно”:
- добывать ресурсы,
- проводить изменения в команде в ходе проекта,
- нанимать людей.
Про ресурсы я рассказывала в прошлой публикации, а вот про два последних пункта хочу поговорить немного подробнее.
Умение проводить изменения в команде в ходе проекта
Как я уже писала раньше, некоторое время назад я сдавала экзамен Professional Scrum Master (PSM I), проверяющий умение работать по правилам фреймворка Scrum. Формат экзамена следующий - за 60 минут надо ответить на 80 вопросов на английском. Проверять себя, сверяться с первоисточниками, гуглить и т. п. формально не запрещено, но в таком формате успеть мало реально - ты либо знаешь “правила игры по Scrum”, либо нет. Так вот, один из вопросов, который мне запомнился в этом тесте был про то, можно ли изменять состав команды, и в частности добавлять в нее новых членов в ходе проекта?
Правильным ответом вовсе не будет “нет, ни в коем случае”. Ибо мы с вами живем в реальном мире, имеем дело с живыми людьми и неожиданно всплывающими обстоятельствами. Кто бы мне год назад рассказал, что сегодня, когда я пишу эту статью, в июне 2020 года, наш мир будет выглядеть так, как он выглядит сейчас - я бы решила, что это сюжет плохого фантастического фильма - кстати, одна популярный канадский кинокритик опубликовала рецензию на COVID-19, где наглядно показала нелогичность сценария и нереалистичность сюжета… Так вот, независимо от наших намерений делать проект постоянной командой, команда меняться будет. Что здесь важно иметь в виду (кроме того, что стоит постараться минимизировать эти изменения)?
Здесь я вспомню, во-первых, правильный ответ на вопрос теста на Scrum-мастера, упомянутого мною выше: “Изменять состав команды можно при необходимости, но имейте в виду, что это вызовет кратковременное уменьшение продуктивности”.
Во-вторых. вспомню так называемый Второй закон Брукса: “Если проект не укладывается в сроки, добавление рабочей силы задержит его еще больше”.
Почему же так происходит? Ответ более менее понятен. Приходится вводить новых людей в курс дела, объяснять вещи всем уже очевидные, это займет ресурсы старых, ухудшится взаимопонимание в команде, и так далее.
На этом месте можно вспомнить стадии развития, которые проходит каждая команда (на русском их называют по-разному, но мне нравится вот такой перевод):
- формирование (команда существует только номинально),
- штормовое возмущение (идут ранговые разборки, борьба за власть и притирки),
- нормализация (договоренности о том, как выстраивать работу),
- выполнение (наконец-то)
- и расформирование (нас сейчас не очень заботит, до этого этапа еще дожить надо).
И беда в том, что при любых изменениях в команде группа, уже стабилизировавшаяся к этому моменту на продуктивном выполнении, откатывается на первые стадии и заново выстраивает там отношения...
В чем проблема - понятно. Теперь давайте подумаем, что можно сделать, чтобы неизбежные изменения в команде прошли как можно менее болезненно? Могу порекомендовать следующие меры:
- Максимально уменьшаем зависимость от того, что называется “bus factor” (автобусный фактор) - сколько человек из команды должно попасть под автобус, чтобы проект остановился? Стремимся к тому, чтобы информация была записана, а не хранилась в голове, чтобы на критичных участках могло работать несколько человек, а не один незаменимый, чтобы технологии передавались друг другу, а не оставались только у одного профессионала.
- Предпринимаем осознанные усилия по тому, чтобы при включении нового человека помочь команде в новом составе максимально быстро и безболезненно пройти первые стадии развития группы, в частности:
- Формирование - познакомить всех со всеми, организовать общение в неформальной обстановке и обсуждение, кто чем может быть полезен
- Возмущение - замечать назревающие конфликты между участниками и помогать их разруливать всем вместе (не гасить, пользуясь властью, а именно - вместе разруливать)
- Стабилизация - иметь записанные правила игры. Например, мы иногда использовали такой документ, как “Устав команды”, где в явной форме озвучены договоренности о принципах работы. Еще полезен такой документ, как “Матрица ответственности” (уже упомянутая мною в прошлой статье), где указывается, кто какими вопросами занимается и за какие задачи отвечает.
- И еще, если речь идет о внешних проектах - помощь в знакомстве новых членов команды с заказчиком и даже своеобразная реклама нового члена команды
Умение нанимать людей
Про то, как определять потенциал людей уже в ходе найма - недавно наткнулась на интересный текст про набор , хочу процитировать:
Я отбирал своих сотрудников сам. Рассказав, как много придется у нас работать, как мало мы за это будем платить и какие высокие требования предъявляем, я предлагал маленький тест. Набор из двадцати семи кубиков, никак не скрепленных между собой. Игрушка для детей 2–4 лет. Из него можно сложить большой куб с гранями три на три так, чтобы все грани были одного цвета. Например, красного. Или желтого. Или синего. Показывал его потенциальному сотруднику … рассыпал кубики и отходил в сторону. Люди работают так же, как играют. Через пятнадцать-двадцать минут я понимал все.
… Человек, который собирает кубик того же цвета, который был изначально, более осторожен. Тот, кто выбирает другой цвет, — склонен к инновациям. И то и другое — нужные качества, но в разных ситуациях.
… Интересно наблюдать и за процессом. Кто-то сразу приступает к сборке и просто берет кубик с подходящими гранями. Кто-то сначала анализирует, отделяет кубики с тремя гранями нужного цвета для углов, с двумя для ребер и уже потом начинает строить. Когда-то давно, когда знакомый психолог подсунул мне эту задачку, я сам начал первым способом, а потом, после неудачи, перешел ко второму. Знакомо, правда? Сперва попробуем по наитию, вдруг «прокатит». Не прокатило? Тогда читаем инструкцию...
Все качества, проявленные в этой незамысловатой игре, нужны и полезны. Где-то надо вдумчиво анализировать, где-то быстро пробовать. Где-то нужна осторожность, а где-то бесшабашность, потому что если делать только то, что умеешь, ничему новому не научишься. Руководителю просто надо знать, какое дело кому поручить.
(фрагмент текста от экс-руководителя компьютерной сети КЕЙ Олега Вайнберга)
Это я не к тому, чтобы всем закупиться кубиками Никитина и проверять на них сотрудников. А к тому, что по поведению человека на грамотно проведенном собеседовании, на тестовом задании, на первом проекте в рамках испытательного срока и т. п. можно многое про понять про его потенциал. Ну и осознать, насколько стоит с ним связываться.
Как можно развивать этот навык?
- Различные курсы, тренинги и литература по HR
- На Инфостарте, в частности, проходит курс "Оперативное управление персоналом", его ведущую Елену Дуюн искренне рекомендую - сама у нее училась.
Развивать людей в команде
В частности, быть наставником, уметь вдохновлять и хвалить членов команды. (кстати, навык “эффективно наказывать”, который я, если честно “вбросила” для оживления дискуссии был признан вредным - и да, соглашусь с этим - “кнут” хотя и может помочь “на короткой дистанции”, в перспективе обычно в большей степени демотивирует, чем поддерживает)
А поговорить я немного хочу про умение хвалить и вдохновлять
На самом деле, это гораздо важнее (а для многих - и сложнее) чем технические навыки. И для того, чтобы вдохновлять нам опять пригодится тот самый эмоциональный интеллект, про который я говорила в прошлой статье, только уже на следующем этапе - понять, что человека мотивирует, и создать максимально подходящие условия для реализации того, что людям необходимо.
А умение замечать позитивные шаги и говорить об этом - в российской практике мало принятое, и тоже помогающее создать рабочую команду.
Как можно проверить, что руководитель умеет вдохновлять свою команду?
Один из способов оценки, который был предложен в ходе дискуссии - независимый опрос сотрудников, средняя оценка удовлетворенности/"счастья" у членов команды, наличие у команды понимания цели и желания дальнейших действий, в том числе идти командой на другие проекты (мотивацию на совместную работу трудно создать, но легко поломать). Здесь, конечно, далеко не все зависит от РП, но многое (если он действительно лидер в команде).
Как можно развивать этот навык?
- На Курсах по управлению ИТ-проектами мы затрагиваем эту тему, как минимум разбираем виды мотивации, способы выдать эффективную обратную связь, методы развития команды и т. п.
- А дальше - здесь будут полезны ресурсы и инструменты, имеющие отношение к практической психологии, к бизнес-психологии.
Уметь отказываться от провального проекта
Честно скажу, на мой взгляд, это важно уметь не только ведущему РП, а начинающему РП особенно - ибо на них часто пытаются вешать заведомо "провальные" истории. Выпускники моих курсов знают мой любимый афоризм “Ты сильный, ты справишься - нет, я умный, я даже не возьмусь” - и мы начинаем разбирать в какой ситуации нужно бежать сверкая пятками уже в начале базового курса).
Проводить бизнес-анализ. Эти навыки упоминаются и раньше, но для опытного РП они признаются действительно необходимыми.
Как можно проверить, что бизнес-анализ от РП корректен? Участники воркшопа озвучили следующие критерии:
1. РП может описать бизнес-процессы "Как есть", и это описание понятно всем участникам проекта, причем владелец БП должен подтвердить корректность описания. Нередко проектная команда ждет от бизнес-заказчика, что они сами опишут процессы, и выдадут их в разработку с разъяснениями, что надо делать.
2. РП способен увидеть узкие места в процессах и простым понятным языком аргументированно донести до всех, почему именно эти места узкие?...
3. В начале работы (да-да, именно в начале, а не перед сдачей результата бизнес-заказчику!!!) стоит составлять таблицу с критериями, чего хочется получить при перестройке бизнес-процессов (минимизировать действия не несущие ценности клиенту, упорядочить хаотичный порядок согласования документооборота и т. п.). В таком случае в конце можно сверить результат с критериями и понять, соответствует ли он заявленным требованиям.
Работать на уровне “программы” и “портфеля” проектов
Что имеется в виду?
Согласовывать проекты со стратегией компании (для этого, честно скажем, надо, чтобы стратегия у компании была, причем желательно была измеримой - тогда можно использовать какие-либо метрики).
Считать рентабельность проекта. Здесь можно много копий сломать на тему, а можно ли вообще рентабельность проекта посчитать?.. (в первую очередь - ROI (возврат инвестиций), метод освоенного объема и план-фактный анализ по итогам проекта), защищать проекты.
По мнению участников дискуссии, признаком профессионализма здесь может считаться умение по итогам первичного анализа убедить заказчика согласиться на проект (вместе с суммой и всеми условиями). Для этого нужно, во-первых, уметь хорошо все просчитать, а во-вторых, владеть еще и умением управлять ожиданиями заказчика.
Быть честным с заказчиком
На тему умения “быть честным с заказчиком” много копий уже сломано и еще сломано будет. Не буду здесь спорить с тезисом, что “вешать лапшу на уши заказчику может быть выгоднее!”, а просто призову всех читателей этой статьи быть в первую очередь честными с самим собой. Тогда жить и работать становится куда приятнее. И напомню старый добрый тезис, что увеличение прозрачности способствует усилению доверия, и, как результат, более слаженной работе сторон. И если вы хотите, чтобы вам больше доверяли - хорошо бы, чтобы у вас не получалось как в истории, которую описал Григорий Орлов в своей книге “Джедайские техники конструктивного общения”:
- Как нам повысить уровень доверия в отношениях с заказчиком? — было видно, что слушательницу серьезно волнует эта проблема.
— А что сейчас не так с уровнем доверия?
— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам…
— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.
— Понимаете… Мы ему джуниор-инженеров продаем как синьор-инженеров… И нам не хотелось бы, чтобы он обнаружил этот факт.
Вместо заключения
Ну и на закуску - те, кто знают ответ на главный вопрос мироздания (да, я тоже люблю эту книжку ))) ) - прекрасно понимают, что вопросы часто бывают важнее ответов (в своих предыдущих статьях я уже рассказывала про то, что тезис “правильные вопросы важнее правильных ответов” верен для работы в информационной среде (по сравнению с работой в индустриальную эпоху).
Поэтому ниже список вопросов, который мы набросали в рамках практикума на Welcome-вебинаре Базового курса по управлению ИТ-проектами. Мною был придуман только один вопрос (сможете угадать какой? )))), остальные от участников практикума.
Комментировать эти вопросы здесь не буду, так что за ответами приходите на Комплексный курс по управлению ИТ-проектами - ближайший набор закрывается уже на этой неделе. Не обещаю, что ответы достанутся вам на блюдечке с голубой каемочкой, но будем их вместе искать.
