Abeunt studia in mores
На старших курсах у нас был предмет «Управление проектами», на котором мы рисовали в майкрософт прожекте ганты по строительству каких-то всратых домиков. И я тогда подумал, что вот этим точно никогда в жизни не буду заниматься.
И вот, уже больше 12 лет управляю проектами. И на самом деле, предметная область управления проектами крайне важна, каким бы менеджментом вы ни занимались. Можно пытаться управлять происходящим движением бровями, но будет уходить много сил и результаты будут с минимальным выхлопом.
Лучше освоить хотя бы три базовых инструмента проектного менеджмента, вам сразу станет сильно проще работать. Изрядную часть управленческой работы занимают именно различные проекты.
Паспорт (устав) проекта
Прочтите статью о паспорте (уставе) проекта, написанную мной ранее, узнаете много нового.
Паспорт в проекте должен быть обязательно, он очень сильно помогает избежать проблем. Есть некий дефолтный набор полей, которые в нём должны быть, пробежимся по ним:
Название. Одно время меня здорово задалбывало по десять раз на дню произносить аббревиатуру, типа СГУК РВИ РВ и РАО. Придумайте краткое и ёмкое название проекта, тогда с ним и работать будет приятнее. Помните заветы капитана Врунгеля — как яхту назовёте, так на ней и напишите.
Руководитель. Очень плохая идея управлять проектом коллективно. Пусть это будет один человек, по совместительству — единая точка входа и единый ответственный за проект, с полнотой власти этим проектом распоряжаться.
Спонсор. Кто предоставляет ресурсы для проекта.
Ролевая модель. Есть такая сущность, «ресурсный план». Она более низкоуровневая, её в паспорт добавлять не надо. Но расписать, какие будут роли на проекте, очень полезно. Будет ли руководитель рулить исполнителями напрямую или будут лиды? Будет ли тимлид-техлид-лид куа?
Цели, деньги и KPI. Проект по определению, ограниченное по времени мероприятие. Значит, надо на старте чётко представлять, зачем мы его делаем и каковы критерии успешности, чтобы проект не стал вечным и не превратился в операционку.
Стратегия коммуникаций. Вообще, есть такая штука как коммуникационный план, но можно обойти и разделом в паспорте. Опишите, как часто и в каком формате будете общаться с заказчиком и стейкхолдерами, какие будут собрания внутри команды, избежите большого количества проблем, которые могут возникнуть в случае беспорядочных коммуникаций.
Риски. Крупноуровневые риски, штуки четыре-пять, всё остальное для реестра рисков.
Конечно же, вы можете придумать свой формат паспорта, но примите как данность — этот документ должен создаваться обязательно.
Диаграмма Ганта
Несмотря на все разговоры о том, что с приходом аджайла, умерла, на самом деле, живее всех живых. Скорее всего, даже на аджайл-проекте с вас будут требовать ответы на вопросы: «Сколько это всё в итоге будет стоить?» и «Когда всё это закончится?» Ответить на эти вопросы проще всего при помощи диаграммы Ганта.
Чаще всего, она рисуется достаточно верхнеуровнево, а на низовых уровнях царит аджайл. В целом, норм. Но проект с небольшим количеством изменений и устойчивой средой, вполне реально провести по Ганту.
Концепция такая. Сначала создаём главный календарь со всеми праздниками. Потом создаём лист ресурсов, потом индивидуальные календари с отпусками. Клеим календари к ресурсам. Потом заносим в софтину ИСР, ставим оценку каждой работы, распараллеливаем работы, назначаем ресурсы задачам. Получается что-то вроде проектного расписания, более-менее близкого к реальности.
Потом можно заносить в диаграмму фактические трудозатраты по задачам и актуализировать оценки, это всё не очень сложно, хоть поначалу и геморройно. Тогда будет видно, опережаем мы график или опаздываем. Софтина сама покрасит таски в светофор1.
Важная штука, которую автоматически рассчитает ваша софтина — критический путь.
Критический путь в управлении проектами — это самая длинная последовательность задач, от которой зависит весь проект. Это цепочка действий: к следующей задаче нельзя приступить, не закончив предыдущую. Если не пройти эту цепочку, выполнить работу не получится.
В целом, невеликая наука.
Базовое управление коммуникациями
Попугай научился спрашивать «Какой статус?» и был повышен до прожект-менеджера. Если не хотите стать таким попугаем, надо выстраивать коммуникации. Нужна система с вехами, повесткой, составом участников.
Парой абзацев выше было описание паспорта проектов. Верхнеуровневый план коммуникаций может быть в нём, низкоуровневый в отдельном доке.
Вам не нужно собираться без цели, просто, чтобы поболтать, это непродуктивно2. Встречи должны быть сфокусированы на конкретных проектных манипуляциях и должны заканчиваться письменным резюме. Если трудно писать самому — нейронки в помощь, только наводите итоговый блеск самостоятельно. Резюме обязательно нужно слать сразу после встречи.
Совершенно необязательно писать в стиле: «Слушали → Постановили». Можно в виде чистого плана действий.
У вас должен быть операционный план. То, что вы и команда должны сделать в ближайшие пару дней. Действие, ответственный, срок, статус.
Обязательно указывайте ответственных и сроки. Иногда берите ответственность сами. Спрашивайте за сроки, делайте напоминания.
Чем меньше файлов и таблиц, тем лучше.
И не забывайте праздновать промежуточные достижения.
- По крайней мере, Merlin Project такое умеет. Думаю, что в MS Project тоже можно. ↩︎
- Хотя, в одной компании мы проводили раз в пару недель «нытинги». Это такие митинги, на которые мы собирались чисто деструктивно поныть и пожаловаться на жизнь, без конкретной цели. Здорово помогало психологически разгрузиться. ↩︎
