Начну с разочаровывающего сообщения. Я толком не управлял руководителями и прям экспертом по этому вопросу выступить не могу. Но могу поделиться соображениями, к которым пришёл, будучи в роли управляемого.
В целом, управлять группой исполнителей не очень сложно. Рассказывать им о стратегических целях компании, обозначать фронт работ, давать конкретные указания, разумно контролировать, проводить 1-2-1, иногда разговаривать «за жизнь». Думать о развитии сотрудников, держать руку на пульсе, глубоко вникать во все реализуемые проекты. Да, некоторые испытывают проблемы уже на этом уровне, сюда относятся, например, любители «показать класс этим щенкам», которым сотрудники садятся на шею, но статья не о них.
Мышление
Однако, когда вы становитесь руководителем портфеля, ситуация меняется. Под вашим руководством оказывается несколько проектов, вникать в каждый в деталях уже не получится. У вас не выйдет ходить на каждую встречу каждого подчинённого пиэма, посещать каждый дейлик и быть детально в курсе всех дел, как было, когда вы управляли отдельным проектом. Нужно перестраивать схему управления, а заодно и мышление. Прочтите мою заметку о пирамиде принятия решений.
Главными мышленческими проблемами при таком апгрейде являются:
- Старые привычки пиэма;
- Прежние подходы и инструменты;
- Неумение делегировать;
- Недостаток доверия сотрудникам;
- Неправильная система мотивации;
- Размытые границы ответственности.
Если проанализировать этот список, можно прийти к выводу, что главная проблема свежеиспечённого ППМ — недостаток доверия. Однако дело в том, что просто взять и начать доверять, слишком опасно.
Доверие — это смелость, чтобы позволить другому использовать нас.
Мая Анджелу
американская поэтесса, писательница и общественный деятель.
В целом, чтобы преодолеть эти проблемы, нужны две вещи.
Безопасная среда. Ошибки и эскалации декриминализированы, пиэмы не боятся пробовать и ошибаться. Даём определённую степень свободы, ограничивая её бюджетами и верхнеуровневыми регламентами.
Личный пример. Где-то месяц назад мой деливери доложил моему ресурсному, что я, в том числе, спросил у своего предшественника, где лежит актуальная оценка по проекту, хотя должен был это знать сам.
Пришлось потратить время, чтобы объяснить ресурсному, что оценка делалась моим предшественником в несколько подходов и было создано несколько файлов с кучей вкладок, на части которых лежат архивные версии оценки и нужно было точно узнать, какая именно актуальная. Из-за таких чудаков, как этот деливери, безопасную среду создать не удаётся. В очередной раз повторяю, ошибки и эскалации декриминализированы.
Прозрачная среда. Вы должны легко получать нужную вам информацию о работе группы. Крайне желательно, чтобы эта инфа извлекалась не дёрганьем пиэмов, а из таск-трекеров и систем метрик.
Кроме того, в плане мышления, нужны ещё три корректировки:
- Управлять не людьми, а системой, исповедуя системный подход.
- Ставить не задачи, а цели.
- Не давать готовых решений, заставлять думать.
Нужно очень чётко понять, что подчинённые пиэмы будут управлять своими проектами самостоятельно и достигать поставленных целей сами, вы ими только верхнеуровнево руководите и вмешиваетесь только в случае сложных проблем, которые на пиэмском уровне не решаются.
Инструменты управления руководителями
Цели вместо задач
Если путник, взбираясь в гору, слишком занят каждым шагом и забывает сверяться с путеводной звездой, он рискует её потерять и сбиться с пути.
Антуан де Сент-Экзюпери
Писатель-эссеист и лётчик Второй Мировой.
Объясняем пиэму, что есть цель — например, реализовать новое приложение в определённый срок с определённым бюджетом. У приложения есть заказчик, к нему можно ходить за требованиями и более детализированными целями, но главным образом, пиэм должен самостоятельно разбить цель на задачи подзадачи.
Есть такая штука как коммитмент. Это когда пиэм, осознавший цель, даёт официальное обязательство эту цель выполнить со всеми условиями и прилагает все усилия, чтобы это сделать.
В PMBOK есть метафора с яйцом. Конечная цель с определением результата — скорлупа, а методы её достижения — всё, что под скорлупой. И пиэм вправе этой внутрянкой яйца распоряжаться самостоятельно.
Ограничения вместо контроля
Бюджет. Отличный инструмент управления. Пиэм на старте проекта делает детализированную оценку. Кстати, я считаю ошибкой попытки на старте оценить и спланировать весь фиксированный проект, сначала надо оценить и провести стадию сбора требований, только после этого планировать всё остальное, тогда ваши планы не будут филькиной грамотой. Итак, требования собраны, мы чётко понимаем, что именно будем разрабатывать, можем оценить сроки, назначить конкретных специалистов с известными ставками и вычислить бюджет проекта. Закладываем некоторые буферы и заставляем пиэма закоммититься на бюджет. И с этого момента он имеет свободу действий, но только в рамках бюджета. Если проект вылезает из бюджета, это уже повод для разбирательства.
Бизнес-процессы. Не надо регламентировать каждый чих, но основные типовые процессы должны быть регламентированы. Почитайте мою старую статью о регламентах в разработке. Это наша вторая сабелька для управления руководителями, нужно только грамотно организовать контроль соблюдения процессов. Но это уже значительно легче детального контроля за всеми проектами портфеля.
Прозрачность
Метрики. Желательно их собирать автоматизированно, на основании данных из таск-трекеров.
В целом, для начала можно взять такой набор (метрики, предложенные командой гугловых девопсов):
- Deployment Frequency — частота поставки;
- Lead Time for Changes — время от коммита до релиза;
- Change Failure Rate — количество багов на релиз;
- Time to Restore Service — время на фикс бага в проде.
Вот примеры других метрик:
Основные метрики Scrum:
- Аккуратность оценки задач;
- Burnout time – время сгорания;
- Velocity – скорость команды;
- Estimated time of delivery – оценочное время поставки.
Основные метрики Kanban:
- Lead Time – время, которое задача проходит от момента создания до релиза;
- Cycle Time – время, которое задача проходит от момента старта работ до релиза;
- WIP – количество задач/SP в работе;
- Wasted Time – время, которое задача находится в ожиданиях;
- Effectiveness – время, которое задача находится в полезной работе;
- Throughput – пропускная способность команды.
Основные метрики PMBOK:
- Плановый объем бюджета;
- Освоенный объем бюджета;
- Прогнозный объем бюджета;
- Отклонение по срокам;
- Отклонение по стоимости.
Потом можете нарастить метрики, специфичные для вашей компании.
Отчёты. Сюда входит всё, что невозможно автоматизировать. Например, сбор текстовых статусов о проекте раз в неделю или две. Советую отчётами не увлекаться и оставлять только самое минимальное.
Обычно я в конце статьи пишу, что это всё, что пиэму нужно знать по вопросу, но эта статья — лишь первая попытка к вопросу подступиться. Будут ещё. Ну и надеюсь однажды получить в управление собственный портфель и сделать продолжение, уже на основе реального опыта.
