Опыт руководителя проекта проявляется в том числе и в мелочах, которые позволяют ему работать эффективно. Особенно это важно в начале проекта, когда нужно быстро запустить все процессы. Опытный РП приходит на проект с чемоданчиком собственных инструментов и приемов, позволяющих стартовать без долгих обсуждений, как лучше организовать работу.
На тренингах иногда спрашивают о фишечках, приемах и технологиях. Когда долго чем-то занимаешься, то такие вещи становятся само собой разумеющимися, и сложно сразу ответить на вопрос. Тем не менее я попробую выделить некоторые, на первый взгляд незначительные моменты, которые помогают экономить время и силы. Маленькие лайфхаки.
Когда начинается проект, критически важно быстро стартовать работу участников проекта. Для этого лучше заранее определить процедуры, инструменты и правила, по которым будут работать проектная команда.
Быстро — ключевое слово, потому что разброд и шатания становятся самоподдерживающимся процессом, а ворох малопродуктивной плохо организованной деятельности растет как снежный ком.
Поэтому Лайфхак 1: приходя на проект, нужно иметь заготовки проектных процедур, документов, отработанных инструментов, которые нужно только развернуть, показать и убедить всех в том, что это пусть не единственный, зато проверенный вариант.
Что конкретно:
Имея это все в готовом виде, можно начинать с места в карьер.
Лайфхак 1 говорит о том, что проект начинается задолго до сбора проектной команды. Если удается заранее подготовить инфраструктуру, то организовать работу становится не в пример легче.
Чтобы еще оптимизировать процесс старта, хорошо подготовить страничку для новых членов проектной команды. Это позволит не тратить время на решение бытовых вопросов.
Что может быть в этом описании:
Чтобы вся эта информация была доступна, нужно сразу определить информационный центр проекта. Удобно делать это с помощью портала на wiki, где можно разместить и информацию для новых участников, и контактную карту, и всевозможные ссылки, проектные процедуры и объявления.
Один из регламентов, которые потом сильно облегчают жизнь — это правила наименования и стандарты написания документов.
Если вы зададите правило кодирования имени файла, то их потом будет легко найти и опознать, не открывая. Например:
<Код проекта>. <Код задачи>.<Название документа>.<версия>
Полезно ключевые задачи проекта обозначать кодами. В методологии внедрения Oracle, например, все проектные задачи заранее закодированы: «TA.030 — Техническая архитектура», «ТЕ.025 — Сценарии тестирования» и т.д. Через некоторое время все в проекте начинают этими кодами разговаривать, потому что это однозначно и экономично.
Правила оформления документов задаются шаблонами. Можно сделать шаблон титульного листа в виде отдельного файла и затем делать на его основе новые документы. При этом автоматически используются стили, которые определены в файле.
Однажды я пошел еще дальше и написал шпаргалку, в которой описал принципы написания текста проектных документов: правила использования стилей, заголовков шрифтов, сокращений и т.д. Однако эффективность этого была не очень высокой, к сожалению. Инструкций у нас никто не читает.
Бич больших проектов — это бесконечные совещания. Встреча длительностью больше часа становится неэффективной, потому что участники устают, теряют фокус внимания и начинают ходить по кругу.
Чтобы их сократить надо, как минимум а) готовиться к ним, б) поставить себе цель — укладываться в 30-40 мин, в) модерировать процесс. Об этом написано много книг, кто хочет стать профессионалом в этой области, тот прочитает.
На что хочу обратить внимание, так это на составление протоколов. Бывает, что после встречи еще дня три согласовывают протокол. На это тратится много времени и сил, а информация за это время «протухает».
В идеале, протокол должен быть готов к окончанию встречи. Можно делать это сразу в письме, которое рассылает ведущий, когда все остальные выходят из переговорной. Мы готовили протокол на страничке портала проекта, которую создавали по шаблону в начале каждого совещания и заполняли по ходу (см. JIRA и Confluence в управлении проектом). После любой участник мог дополнить или поправить формулировки, но протокол в любой момент времени считался актуальным. История всех изменений сохранялась, можно было посмотреть, кто какие изменения внес. Таким образом никакого дополнительного времени на согласования у нас не было.
Даже если этого никто не требует, лучше с самого начала проекта ввести практику еженедельных формальных отчетов.
Отчет должен быть на 1-2 страницы. Содержание отчета структурировано и единым от недели к недели. Как минимум в нем содержится:
Даже если вы рассылаете отчет ограниченной группе лиц, помните, что отчет может попасть кому угодно, начиная от любого участника проектной команды до акционеров компании. Поэтому тщательно выбирайте слова и информацию, которую в не показываете. Перед рассылкой необходимо его согласовать с кем-то кто будет защищать с вами этот статус проекта.
Еженедельный отчет создает ритмичность, которая дисциплинирует РП и создает у его руководителей и заказчика уверенность, что все под контролем, и они понимаю, что происходит в проекте. Светофор зеленый — все хорошо!
Самый дефицитный ресурс — это время. Все сделать невозможно. Поэтому самое полезное, что может предпринять руководитель проекта — это остановиться, некоторое время ничего не делать и подумать о приоритетах, отпустив мозг в свободное плавание минут на 10. Расслабление тела и короткая медитация помогает увидеть, что важно, а что нет; чем стоит заняться в первую очередь, а что можно отдать другим.
При этом есть вещи, которые нельзя откладывать. Например, если вы обещали в пятницу вечером рассылать отчет о ходе проекта, нужно сделать. Потому что в противном это займет внимание в момент, когда это совершенно недопустимо. Незаконченное дело пожирает энергию. Лучше не откладывать рутину, которая должна делаться по расписанию. Иначе потом она настигает как снежная лавина. Лучше напрячься, сделать, и спать спокойно.
Кроме процедур и регламентов всегда есть отношения. Отношения в проектной команде, отношения с заказчиком. Здесь играет роль и искреннее уважение к каждому; понимание, что все люди, а не только участники проекта. Если у РП нет этого внутри, то никакие тимбилдинги не помогут.
Если у вас есть сложившиеся конструктивные рабочие отношения, то вам простят много ошибок. А если их нет — могут не понять ваших достижений. Такова человеческая природа.
Понятно, что некоторые вещи, мы делаем на осознавая, поэтому всего не расскажешь. Всегда полезно понаблюдать за работой мастера, управляет ли он проектом, чинит ботинки или пишет книгу. Можно учиться у кого угодно, если видишь суть.
На тренингах иногда спрашивают о фишечках, приемах и технологиях. Когда долго чем-то занимаешься, то такие вещи становятся само собой разумеющимися, и сложно сразу ответить на вопрос. Тем не менее я попробую выделить некоторые, на первый взгляд незначительные моменты, которые помогают экономить время и силы. Маленькие лайфхаки.
Что в чемоданчике?
Когда начинается проект, критически важно быстро стартовать работу участников проекта. Для этого лучше заранее определить процедуры, инструменты и правила, по которым будут работать проектная команда.
Быстро — ключевое слово, потому что разброд и шатания становятся самоподдерживающимся процессом, а ворох малопродуктивной плохо организованной деятельности растет как снежный ком.
Поэтому Лайфхак 1: приходя на проект, нужно иметь заготовки проектных процедур, документов, отработанных инструментов, которые нужно только развернуть, показать и убедить всех в том, что это пусть не единственный, зато проверенный вариант.
Что конкретно:
- Структура проектной команды и распределение обязанностей.
- Набор проектных процедур. Если на одном из проектов вы их описали хорошо, то дальше идет только адаптация и совершенствование.
- Способ организация проектной библиотеки. В статье JIRA и Confluence в управлении проектом написано об одном из вариантов.
- Организацию управления задачами. В той же статье вы найдете описание варианта, который мы использовали.
- Типовой высокоуровневый план проекта и методология внедрения
- Набор типовых рисков
Имея это все в готовом виде, можно начинать с места в карьер.
Кто покупает печенки?
Лайфхак 1 говорит о том, что проект начинается задолго до сбора проектной команды. Если удается заранее подготовить инфраструктуру, то организовать работу становится не в пример легче.
Чтобы еще оптимизировать процесс старта, хорошо подготовить страничку для новых членов проектной команды. Это позволит не тратить время на решение бытовых вопросов.
Что может быть в этом описании:
- Где и как получить пропуск на вход, если работа идет на территории заказчика
- Каковы правила распорядка (рабочие дни, выходные)
- Как подключиться удаленно, если это возможно
- Как подключить принтер
- Где находится столовая, как лучше добраться до офиса
- Какие правила отчетности, если работа идет по таймшитам, как отчитываться по расходам
- Кто покупает печенки
Чтобы вся эта информация была доступна, нужно сразу определить информационный центр проекта. Удобно делать это с помощью портала на wiki, где можно разместить и информацию для новых участников, и контактную карту, и всевозможные ссылки, проектные процедуры и объявления.
Правила для документов
Один из регламентов, которые потом сильно облегчают жизнь — это правила наименования и стандарты написания документов.
Если вы зададите правило кодирования имени файла, то их потом будет легко найти и опознать, не открывая. Например:
<Код проекта>. <Код задачи>.<Название документа>.<версия>
Полезно ключевые задачи проекта обозначать кодами. В методологии внедрения Oracle, например, все проектные задачи заранее закодированы: «TA.030 — Техническая архитектура», «ТЕ.025 — Сценарии тестирования» и т.д. Через некоторое время все в проекте начинают этими кодами разговаривать, потому что это однозначно и экономично.
Правила оформления документов задаются шаблонами. Можно сделать шаблон титульного листа в виде отдельного файла и затем делать на его основе новые документы. При этом автоматически используются стили, которые определены в файле.
Однажды я пошел еще дальше и написал шпаргалку, в которой описал принципы написания текста проектных документов: правила использования стилей, заголовков шрифтов, сокращений и т.д. Однако эффективность этого была не очень высокой, к сожалению. Инструкций у нас никто не читает.
Совещания и протоколы
Бич больших проектов — это бесконечные совещания. Встреча длительностью больше часа становится неэффективной, потому что участники устают, теряют фокус внимания и начинают ходить по кругу.
Чтобы их сократить надо, как минимум а) готовиться к ним, б) поставить себе цель — укладываться в 30-40 мин, в) модерировать процесс. Об этом написано много книг, кто хочет стать профессионалом в этой области, тот прочитает.
На что хочу обратить внимание, так это на составление протоколов. Бывает, что после встречи еще дня три согласовывают протокол. На это тратится много времени и сил, а информация за это время «протухает».
В идеале, протокол должен быть готов к окончанию встречи. Можно делать это сразу в письме, которое рассылает ведущий, когда все остальные выходят из переговорной. Мы готовили протокол на страничке портала проекта, которую создавали по шаблону в начале каждого совещания и заполняли по ходу (см. JIRA и Confluence в управлении проектом). После любой участник мог дополнить или поправить формулировки, но протокол в любой момент времени считался актуальным. История всех изменений сохранялась, можно было посмотреть, кто какие изменения внес. Таким образом никакого дополнительного времени на согласования у нас не было.
Еженедельные отчеты
Даже если этого никто не требует, лучше с самого начала проекта ввести практику еженедельных формальных отчетов.
Отчет должен быть на 1-2 страницы. Содержание отчета структурировано и единым от недели к недели. Как минимум в нем содержится:
- Общая оценка проекта, например, светофором. И комментарии по этому поводу — где находимся, основные достижения и проблемы
- Выполненные задачи за предыдущую неделю
- План на следующую неделю
- Риски, проблемы, предложения
Даже если вы рассылаете отчет ограниченной группе лиц, помните, что отчет может попасть кому угодно, начиная от любого участника проектной команды до акционеров компании. Поэтому тщательно выбирайте слова и информацию, которую в не показываете. Перед рассылкой необходимо его согласовать с кем-то кто будет защищать с вами этот статус проекта.
Еженедельный отчет создает ритмичность, которая дисциплинирует РП и создает у его руководителей и заказчика уверенность, что все под контролем, и они понимаю, что происходит в проекте. Светофор зеленый — все хорошо!
Нехватка времени
Самый дефицитный ресурс — это время. Все сделать невозможно. Поэтому самое полезное, что может предпринять руководитель проекта — это остановиться, некоторое время ничего не делать и подумать о приоритетах, отпустив мозг в свободное плавание минут на 10. Расслабление тела и короткая медитация помогает увидеть, что важно, а что нет; чем стоит заняться в первую очередь, а что можно отдать другим.
При этом есть вещи, которые нельзя откладывать. Например, если вы обещали в пятницу вечером рассылать отчет о ходе проекта, нужно сделать. Потому что в противном это займет внимание в момент, когда это совершенно недопустимо. Незаконченное дело пожирает энергию. Лучше не откладывать рутину, которая должна делаться по расписанию. Иначе потом она настигает как снежная лавина. Лучше напрячься, сделать, и спать спокойно.
Отношения
Кроме процедур и регламентов всегда есть отношения. Отношения в проектной команде, отношения с заказчиком. Здесь играет роль и искреннее уважение к каждому; понимание, что все люди, а не только участники проекта. Если у РП нет этого внутри, то никакие тимбилдинги не помогут.
Если у вас есть сложившиеся конструктивные рабочие отношения, то вам простят много ошибок. А если их нет — могут не понять ваших достижений. Такова человеческая природа.
Понятно, что некоторые вещи, мы делаем на осознавая, поэтому всего не расскажешь. Всегда полезно понаблюдать за работой мастера, управляет ли он проектом, чинит ботинки или пишет книгу. Можно учиться у кого угодно, если видишь суть.
