Еженедельные ритуалы, которые стоит освоить менеджеру ИТ-проекта
Сегодня я хочу рассказать о буднях менеджера проекта. Когда я управляю проектом, то придерживаюсь определенного списка деятельности на каждую неделю. Эта комплексная деятельность требует встреч или обсуждений, но наличие четкого представления о том, чем необходимо заниматься каждую неделю помогает сделать более ясным, на чем следует сфокусироваться.
Сегодня я хочу рассказать о буднях менеджера проекта. Когда я управляю проектом, то придерживаюсь определенного списка деятельности на каждую неделю:
- Определите следующую веху. Есть ли цель, до которой осталось меньше месяца? Если нет, определите ее так быстро, как только сможете. Обсуждайте следующую веху на каждой встрече с командой.
- Актуализируйте план проекта. Каждую пятницу выделяйте час или два на ревью и актуализацию плана проекта.
- Обновите реестр рисков. В течение времени, выделенного на планирование проекта, обновите реестр рисков.
- Отправляйте еженедельное обновление проекта. После обновления плана проекта и реестра рисков сделайте рассылку, в которой собраны статусы всех проектов, за которые вы отвечаете.
Эта комплексная деятельность требует встреч или обсуждений, но наличие четкого представления о том, чем необходимо заниматься каждую неделю помогает сделать более ясным, на чем следует сфокусироваться.
1. Определите следующую веху
Люди работают лучше всего, когда они работают над достижением близкой и понятной цели. Они вовлечены, более продуктивны и более эффективны, когда работают над важной вехой, до которой осталось меньше месяца. Кроме того, это позволяет разделить сложность на части, которыми легче управлять. Люди понятнее такой объем работы. Они более эффективно трудятся над ним.
Почему месяц, а не раньше или позже? Простой ответ: это то, в том, что я убеждался на собственном опыте и на основании некоторой подборки случаев, которые я наблюдал. Подробнее об этом можно прочитать в моей статье о вехах в проектах.
Я рекомендую собрать вместе менеджера по продукту, дизайнера и людей, которые больше всего думали о технических контурах проекта и обсудить с ними следующую веху: «Какой будет лучшая цель, достижимая за месяц? Давайте придумаем несколько вариантов и выберем тот, который всем больше нравится».
Начните с того факта, что вам всегда нужна веха, до которой осталось меньше месяца. Если вы собираетесь завершить этап, убедитесь, что вы определили следующую веху. Узнайте больше об искусстве разбивать проекты, а также помните, что это серьезный навык, для развития которого требуется время и практика.
2. Актуализируйте план проекта
Каждую неделю я выделяю время для обновления своих проектов. Я просматриваю план проекта и убеждаюсь, что он отражает мое текущее видение. Я спрашиваю себя, кажется ли он все еще реалистичным. Я продумываю оставшуюся часть проекта и думаю о потенциальных источниках задержки и рисках.
Принятие желаемого за действительное — ваш враг. Смотрите на все со скептицизмом. Для некоторых людей это естественно, а для других требуется практика.
Вам потребуется информация от других, чтобы обновить план проекта. Обычно я резервирую еженедельные встречи для каждой команды или проекта. На этой встрече я приглашаю основных руководителей, подробно рассказываю им о следующих двух неделях, презентую им свое текущее представление о плане проекта и прошу критически его проанализировать. Затем я заглядываю дальше в будущее, но чем дальше мы уходим, тем меньше точность. Обычно я приглашаю кого-то, кто представляет продуктовую команду, техническое руководство и дизайн.
Старайтесь проводить эти встречи на достаточно высоком уровне. Они не должны стать напрасной тратой времени для участников. Я считаю, что лучше всего объединить это с собранием, имеющим глобальную цель. Например, на собрании лидеров команды этому вопросу можно уделить 5-10 минут каждую неделю, но большую часть времени мы можем обсуждать другие вопросы, например, то, что нас беспокоит или что нужно улучшить.
Один из антипаттернов для менеджеров проектов заключается в том, что вы можете привыкнуть постоянно запрашивать информацию у людей. Это в лучшем случае раздражает. Сделайте так, чтобы люди информировали вас без особых затрат. А также поощряйте людей сообщать о своих наблюдениях, чтобы вам не приходилось их тревожить. Предпочтительно переключение взаимодействия на инициативность.
Как должен выглядеть план проекта?
Я составляю планы проектов по неделям. Каждая неделя имеет пару пунктов списка. Пункты списка это то, что мы планируем продемонстрировать на этой неделе. Демонстрации должны включать технические демонстрации, но главное, что мы будем поставлять, с точки зрения клиента.
Я также добавляю временные события, имеющие отношение к реализации проекта. Например, время отпуска, графики дежурств и выезды на работу.
Нет нужды конкретизировать план проекта более чем на пару пунктов списка. Вам нужен план, который легко изменить. Чем детальнее ваш проект, тем дороже его переделка. Хороший план проекта должен быть инструментом для обсуждения и стимулировать изменения, а не препятствовать им. Когда я вижу много артефактов проекта и вещей, требующих обновления, я становлюсь скептичным. Диаграммы Ганта эффективны, но часто являются признаком того, что базовые данные трудно изменить.
Одна вещь, на которую следует обратить внимание, это то, что многие команды разработки распределяют проект персонально по людям. Чем больше вы используете команду целиком как единицу реализации ваших проектов, тем лучше. Это обширная тема, поэтому я не буду сейчас вдаваться в подробности, но в целом, когда я вижу планы проекта, в которых указано, что делает каждый человек, я рассматриваю это как признак того, что проект излишне хрупок, а команда чрезмерно специализируется и недостаточно делится знаниями. Это может быть уместно для небольших компаний, но в остальном я склонен препятствовать этому. Если я вижу дробное распределение «ресурсов» в проекте, я обычно кричу, достаю из сумки зажигалку, поджигаю волосы и выбегаю из комнаты. Чем меньшим количеством проектов вы управляете, тем лучше вы с ними справитесь, так что это еще один аргумент в пользу команд, сосредотачивающихся на меньшем количестве проектов.
Часто спрашивают, нужен ли вам недельный план проекта, если вы работаете в команде, у которой есть двухнедельные спринты. Конечно, решать вам, но я бы делал это каждую неделю. В противном случае у вас будет очень мало информации о том, есть ли прогресс или нет. В течение двухнедельного спринта я говорю команде, что это план, показывающий, сможем ли мы демонстрировать результат к пятнице каждую неделю.
3. Как должен выглядеть реестр рисков?
Когда вы обновляете планы своих проектов, вы также должны спросить себя, что может пойти не так. Вот несколько способов задать себе или другим вопросы, которые помогут лучше планировать:
Что, скорее всего, пойдет не так в этом проекте?
- Какие прошлые проекты были похожи на этот? Какие проблемы у нас были с ними?
- Что самое худшее может произойти в этом проекте на самом деле?
- Если бы нам пришлось поставить месячную зарплату на успех проекта, о чем бы мы сейчас беспокоились?
Управление рисками – это балансирование. Вы не хотите чрезмерно инвестировать во многие риски, но вы хотите их продумать. После того, как вы обнаружите новые риски, перечислите их в качестве маркеров в вашем реестре рисков.
Для каждого риска вы или ваша менеджерская группа должны решить, можно предпринять какие-либо действия для снижения этого риска. Рядом со своим реестром рисков укажите свой план по каждому из них или запишите «согласиться риск».
Если ваша менеджерская группа работает хорошо, у вас получится рационально обсудить риски и затраты на их снижение. Я предлагаю обсудить не только затраты на снижение риска, но и то готовы ли вы в это инвестировать.
4. Распространите еженедельное обновление проекта
После обновления моего плана проекта и реестра рисков у меня есть четкое представление о текущем состоянии проекта. Теперь я могу помочь окружающим, поделившись этим пониманием в максимально сжатой форме.
Цель еженедельной рассылки не в том, чтобы рассказать все о проекте. И не для того, чтобы показать, насколько хороша ваша команда. Когда вы подходите к рассылке с любой из этих точек зрения, ваше сообщение становится неудобно читать. Вместо этого вы должны сосредоточиться на потребностях вашего респондента и предоставить ему ровно столько информации, чтобы он мог обратиться к вам в случае необходимости за деталями.
За эти годы я узнал многое о написании кратких, удобочитаемых рассылок. Есть несколько замечательных примеров, поэтому я настоятельно рекомендую обратить внимание на пример:
Одна вещь, которую я хотел бы подчеркнуть, это то, что вы должны производить впечатление нейтральной стороны: объективной, откровенной в отношении риска и беспристрастного отображения.
Ваше сообщение должно включать ссылку на источник информации: план проекта, реестр рисков и ссылку на демонстрацию текущего состояния проекта.
После того, как вы напишете сообщение, отправьте его заинтересованным сторонам. Вы можете использовать список рассылки или канал в Slack. Постарайтесь, чтобы людям было легко следить за новой информацией. Вы, вероятно, будете удивлены, сколько людей найдет это полезным. Вы можете обнаружить, что другие подразделения компании сочтут ваши рассылки значимыми.
Эти обновления помогают людям вокруг вас быть эффективными. Ваши менеджеры будет проинформированы о состоянии проекта, чтобы представлять вашу работу на встречах (вы даже не представляете, насколько это полезно для них). Другим командам, которые зависят от вас, не нужно будет связываться с вами, чтобы получать обновления. Это обеспечивает очень хорошую коммуникационную основу. Вы даже можете получить благодарственные письма!
Между прочим, эти обновления помогают продемонстрировать вашу способность управлять проектом.
Я считаю, что обновления проекта являются хорошим стимулом для выполнения остальной части управления проектом. Знание того, что мне нужно рассылать еженедельные обновления, заставляет меня тратить время на все остальное.
В идеале обновление должно состоять всего из одного или двух коротких сообщений. Вам не нужно много деталей: люди могут поговорить с вами, если у них возникнут вопросы.
Моя благодарность
У меня долгая история управления проектами, в прошлом я даже писал программное обеспечение для управления проектами, но Бьорн Фриман-Бенсон действительно донес до меня детали того, как написать хорошее сообщение. Он выступал в роли редактора, каждую неделю обучая меня тому, как сделать это лучше.
by Jade Rubick оригинал статьи