Памятка по управлению проектами

Хотя здорово получать знания и читать об идеальных процессах для руководства командой, также важно понимать, что не существует единого идеального процесса, который можно было бы применять повсеместно. В этой статье я расскажу о самых важных навыках, которые могут помочь вам стать лучшим менеджером проектов, независимо от используемой вами техники, фреймворка или методологии.

Команда, Команда, Команда

Команда — ваш безопасный дом. Очень важно установить хорошие отношения с вашей командой и улучшить командное общение и командный дух. Команда должна быть безопасным местом для всех членов, где они чувствуют себя сильнее всего. Каким бы ни было решение, оно принимается командой; какая бы фича ни создавалась, она создается командой; вы все берете кредит как команда, а не индивидуально.

Несколько лет назад я изменил свой этикет формального общения, переключившись с «я» на «мы». Например, когда я делюсь чем-то с заинтересованными сторонами за пределами команды, я говорю: « Мы создали диаграмму скорости для последнего спринта. Мы составили прогноз бюджета и сроков ». Хотя на первый взгляд это может показаться необычным, у этого есть очевидные преимущества. Во-первых, сила находится внутри команды, и решение становится более надежным, если вы пришли к нему как команда. Во-вторых, менеджеры проектов подают пример, и, не говоря «я», мы демонстрируем, что сами ни за что не берем ответственность. То же самое относится и к ошибкам⁠ — все, что было сделано неправильно, лежит на команде. Мы не виним отдельных членов команды. После этого мы проводим внутреннюю проверку, чтобы скорректировать процесс и улучшить его, чтобы избежать подобных ошибок в будущем.

Хватит искать идеальный процесс

Если вы гонитесь за идеальным процессом для своей команды, вы можете остановиться прямо сейчас. Нет такой вещи, которую можно было бы применять повсеместно.

Руководители проектов сталкиваются со многими различными структурами, практиками и процессами на протяжении всей своей карьеры. Они предпочитают использовать некоторые из фреймворков в своей команде, чтобы узнать, что конкретно работает. Однако, если команда сопротивляется процессу, важно не следовать модели «один размер подходит всем».

И наоборот, руководители проектов должны адаптировать процесс для работы со своей командой. За свою карьеру в ИТ я не встречал ни одной команды, которая использовала бы какой-либо фреймворк полностью «по инструкции». То, что работает для нас и формирования нашей команды, культуры и менталитета, вряд ли сработает для других команд. Таким образом, менеджеры проектов должны продолжать тестировать различные методы, пока они не достигнут оптимального результата⁠ — сочетания методов, которые лучше всего работают для команды.

Если команда внедрила Scrum, но обнаружила, что ежедневные собрания требуют дополнительных затрат, альтернативой может быть использование бота для собраний в Slack и планирование звонков только при необходимости. То же самое можно применить и к проверкам спринта: если члены команды считают их контрпродуктивными, менеджеры могут решить запланировать проверки в соответствии с потребностями команды. Важно понимать, что мы не являемся хранителями Scrum, Kanban или других фреймворков, и они существуют только для того, чтобы помогать команде добиваться производительности и мотивации.

Иметь много рук для выполнения многих задач

Когда дело доходит до заинтересованных сторон проекта, общение является ключевым. Нравится вам это или нет, менеджер проекта должен участвовать во всех коммуникациях по проекту. Иногда менеджеры перегружены сообщениями и задачами, но это та работа, на которую они подписались.

Опытные менеджеры проектов овладевают навыком быстрого просмотра сообщений и принятия решений о том, что требует их пристального внимания. Поначалу для этого может потребоваться больше усилий, но цель состоит в том, чтобы воздержаться от вникания в детали, такие как глубокие технические обсуждения, если они не приносят пользы проекту. Вместо этого, чтобы сэкономить время и избежать обмена сообщениями, руководитель проекта может запланировать групповой вызов для поиска решения. Один 15-минутный звонок часто может заменить часы безрезультатного письменного общения.

Все заинтересованные стороны должны знать, что менеджер проекта является единственным контактным лицом . Расстановка приоритетов и делегирование обязанностей — важная роль руководителя проекта, позволяющая следить за тем, чтобы проект не сбивался с пути. Многие менеджеры предпочитают выполнять задачи самостоятельно, чтобы убедиться, что требования выполнены, но в долгосрочной перспективе они могут потерять внимание к важным вещам. Делегируйте все, что можно делегировать. Вы по-прежнему можете выполнять задачи, которые обычно требуют внимания руководителя проекта; например, я занимаюсь контролем качества важных функций и задач, но никогда не слишком вовлекаюсь в задания других участников.

Доверьтесь оценкам по умолчанию, затем измерьте и обсудите

Менеджер проекта должен доверять оценкам, которые члены его команды дают по задачам. Прежде чем стать руководителем проекта, я четыре года был разработчиком. Я никогда не оспаривал оценку с разработчиком, не имея данных, подтверждающих мои аргументы. И под данными я подразумеваю предыдущую запись члена команды о предполагаемом и фактическом времени, затраченном на задачи, а не мой собственный опыт разработки. Вы должны учитывать различный опыт и опыт людей, когда они оценивают задачи. Если руководитель проекта хочет обсудить и поспорить по поводу оценки, он должен подкрепить свои аргументы данными и четко определить, чего он хочет достичь.

Прозрачность и контроль конфиденциальной информации

Менеджеры проектов являются связующим звеном между бизнесом и технологиями, и они часто владеют информацией с обеих сторон. Помимо того, что они видят общую картину, они также сталкиваются с некоторыми рисками, такими как обработка конфиденциальной информации. Очень важно найти тонкую грань между прозрачным руководителем и правильным обращением с конфиденциальной информацией.

В компаниях, где менеджеры проектов не считаются высшим руководством, они по-прежнему имеют доступ к большому количеству конфиденциальной информации. Иногда им не говорят конкретно, какая информация является конфиденциальной, и им приходится разбираться в этом самим. Конечная цель состоит в том, чтобы не скрывать информацию от команды, и вся информация, имеющая значение для реализации проекта, должна быть доступна всем в команде. Тем не менее, некоторые из них должны оставаться конфиденциальными по какой-то причине, так как это может подорвать мотивацию команды или вызвать ненужные споры. Например, если компания находится на грани подписания крупной сделки с инвесторами, есть возможность объявить новость команде или оставить ее для определенной группы людей, пока сделка не будет проверена. Второй вариант лучше, так как в любой момент сделка может пойти наперекосяк, а если ожидания команды не оправдаются, это может снизить мотивацию.

Есть несколько причин стремиться к максимальной прозрачности. Во-первых, удерживая других людей в цепочке общения, вы снижаете риск упустить что-то важное. Поскольку в рамках проекта ведется множество дискуссий, менеджеры нередко теряют некоторую информацию или просто забывают отреагировать. Во-вторых, чем больше людей участвует в цикле, тем меньше необходимости повторять одну и ту же информацию разным членам команды, поскольку они уже знают ее.

Отмечайте риски заранее

Менеджер проекта должен сформировать системный подход к устранению препятствий, чтобы члены команды могли решать все задачи проекта. Если менеджеры не обратятся к блокировщикам после спринтов, многие элементы могут оказаться помеченными как заблокированные в невыполненной работе. Существует тенденция снимать блокировщики только с самых важных задач, однако это потенциально приводит к катастрофе, так как может быть заблокировано значительное количество взаимозависимых задач.

Хорошей идеей будет создать список действий, посвященных исключительно устранению блокировщиков, и выполнить каждое из них с выделенным заинтересованным лицом. Не менее важно установить правильные связи между задачами, чтобы все знали, какие высокоприоритетные задачи будут заблокированы из-за блокировщиков на нижних уровнях. В конце концов, у руководителей проектов остается два варианта. Во-первых, они могут вести свой собственный список дел со своими приоритетами, которые сосредоточены на устранении блокировщиков. Во-вторых, они могут добавлять больше деталей к задачам и тщательно связывать их, добавляя зависимости, которые обеспечивают согласованность блокировщиков для всех связанных задач. Второй вариант становится слишком сложным, особенно в больших проектах; менеджеры часто в конечном итоге делают и то, и другое, чтобы продолжить работу и вовремя удалить блокираторы.

От неудач и трудных времен к маленьким победам

Если срыв дедлайна становится неизбежным, руководитель проекта не должен злиться на команду. Это именно те времена, которые требуют усилителей мотивации, а не обвинений. Шаг вперед и быть лидером; если необходимо, возьмите вину на себя и мотивируйте команду преодолеть и реализовать функциональность наилучшим образом. Запланируйте проверку, чтобы понять, что пошло не так и как ваша команда может работать лучше в будущем, чтобы предотвратить повторение этих неудач.

Не менее важно вместе отмечать маленькие победы. Запланируйте короткую встречу, чтобы похвалить команду, например, когда вы добьетесь результатов в установленные сроки. Совокупность небольших побед приводит к общему успеху проекта.

Документирование встреч

Согласованная документация — одна из самых важных привычек для каждого руководителя проекта. По моему опыту, управление совещаниями обычно недооценивают, и в результате я провел много часов на бесполезных совещаниях за свою карьеру менеджера проектов. Подготовка — это ключ к каждой успешной встрече, и она занимает примерно пять минут:

• Составьте повестку дня и определитесь с необходимыми участниками. Убедитесь, что все участники приглашены.
• Разошлите участникам повестку дня и уточните у них, нужно ли обсуждать что-то еще.
• Если у вас виртуальная встреча, проверьте, отправлена ​​ли ссылка.

Когда начинается собрание:

• Присоединяйтесь на пару минут раньше, поприветствуйте всех, поприветствуйте их и после короткого периода светской беседы погрузитесь непосредственно в повестку дня.
• Во время собрания делайте заметки, записывайте все действия, проверяйте наличие вопросов после того, как ознакомитесь с повесткой дня, и закройте собрание.
• После завершения встречи немедленно поделитесь заметками и планами действий с командой.

По моему опыту, 15 минут часто более продуктивны, чем одно- или двухчасовое совещание, потому что все придерживаются сути, и вы можете не дать участникам отклониться от повестки⁠, если только не нужно обсудить что-то важное.

Несколько бонусных советов, которые могут сэкономить много времени:

• Имейте шаблон для заметок о встрече.
• По возможности отправляйте повторяющиеся приглашения.
• Создайте шаблоны для последующих действий.
• Установите себе напоминания для последующих писем.

Правильные инструменты имеют значение

Выбор правильных программных инструментов является ключевой частью управления проектом. Руководители проектов часто вовлекаются в дискуссии о том, с какими конкретными инструментами должна работать команда. Такие обсуждения могут быть либо пустой тратой времени, либо продуктивными, в зависимости от понимания командой того, чего они хотят достичь с помощью конкретного инструмента. Есть несколько факторов, которые следует учитывать при выборе наиболее подходящих инструментов:

• Размер команды
• Состав команды
• Методология или структура проекта
• Насколько подробно должен содержаться отчет

Я организовал свой список инструментов по размеру команды. Для небольших команд, особенно если они только начинают проект, я использую Trello. Этот инструмент обладает большинством функций, необходимых для работы с канбан-фреймворком. Когда я работаю над проектом среднего размера с десятками людей, я думаю об использовании Asana. Он имеет некоторые достойные функции управления проектами, включая определенную степень отчетности. Однако, если в проекте задействовано более 20 человек и подробные уровни отчетности, я склонен использовать Jira. Он хорошо интегрируется с множеством других решений, доступных на рынке, что обеспечивает широкие возможности настройки. Я также использую Clubhouse в качестве основного инструмента для всех малых и средних проектов, и я нашел там отличный набор функций.

Регулировка — это ключ

Фреймворки, процессы и инструменты должны корректироваться в зависимости от потребностей и проблем команды, а не наоборот. По мере накопления опыта вы накапливаете кучу инструментов и методологий, которые вам нравятся, которые вы ненавидите, используете экономно или от которых отказались. С каждым годом будут появляться новые, а некоторые из старых устареют. Но навыки, которые вы разовьете в качестве лидера, позволят вам извлечь максимальную пользу из каждой среды.