Принципы работы руководителя проекта
Статья о принципах организации работы над проектами разработки и внедрения ПО со стороны РП организации-исполнителя контракта с фиксированной стоимостью, плохо определенными требованиями и сжатыми сроками.
Это не пересказ учебника, а обобщение личного опыта, накопленного в ходе участия в руководстве и курировании 50+ подобных проектов. Предлагаемые подходы не являются исчерпывающими или окончательными, критика приветствуется :-)
Молодец, бери новый проект
Теория управления проектами
PMBOK — это свод знаний по управлению проектами, но его редко читают, уж слишком много букв. Кроме того, PMBOK не совсем подходит для Agile-подходов.
Правила Ашманова — рекомендуются к изучению. Они делятся на две части: одна посвящена управлению программистами, а другая — управлению проектами.
Критическая цепь — книга Голдратта, описывающая подход к управлению проектами.
Scrum Guide — важный документ, который стоит прочитать. Он небольшой, но информативный.
Много еще есть всяких теорий, учебников, но ближе к делу –, а что же делаем на практике?
Роль и значение РП
Руководитель проекта (РП) отвечает за достижение запланированных результатов и принимает необходимые меры для их достижения. В контексте Agile проект можно сравнить с путешествием без карты, когда нам неизвестны все потенциальные препятствия. Мы ориентируемся на удаленную, не до конца определенную цель и решаем возникающие по пути проблемы, все лучше понимая истинные очертания цели.
Ситуация осложняется тем, что к цели надо придти уложившись в ограничения: с фиксированной стоимостью контракта, фиксированными сроками и ресурсами.
РП сталкивается с трудностями и определяет методы их преодоления, следовательно, ему необходимы ресурсы и полномочия для этого. При этом просто разработать план и ожидать его выполнения недостаточно. Способность эффективно решать возникающие в процессе реализации проекта проблемы показывает уровень профессионализма РП.
Примером проблемы может послужить ситуация, когда заказчик хочет получить результат, отличающийся от первоначального технического задания (ТЗ) — возможно, он что-то упустил или изменил свои ожидания в процессе. Именно в таких случаях РП должен принимать решение о том, какие действия предпринимать, а какие — нет.
РП должен управлять и ожиданиями заказчика, и работами внутри исполнителя.
Как выбрать РП
Выбирать РП нужно с учетом потенциальных проблем, которые могут возникнуть в проекте: разные РП лучше справляются с различными задачами — одни умеют налаживать отношения с заказчиком, другие более эффективно работают с командой или лучше понимают технические и бизнес-проблемы.
Важно, чтобы РП обладал опытом, сходным с требованиями проекта, включая понимание сферы деятельности, технические навыки и объем предстоящих работ.
Если же РП на примете нет, и его надо искать на рынке — ситуация усложняется. Квалифицированного РП трудно найти; на вакансию приходит множество откликов, надо как-то выбрать того, кто приведет проект к успеху.
Кто не подходит:
РП, который управлял проектом со стороны заказчика.
Проблемы, с которыми сталкивается в проекте заказчик, значительно отличаются от тех, что возникают у исполнителей.РП, управлявший внутренним проектом.
Внутренние проекты компании часто характеризуются сниженными требованиями к качеству работы из-за отсутствия жесткого контроля сроков и бюджета, сниженных требований к качеству работ в отсутствие конкуренции и т.д., так как исполнители и заказчики находятся в одной команде.РП, работавший по схеме «times&materials».
В данном формате у РП нет мотивации активно управлять процессом, и он может использовать подход «любой каприз за ваши деньги». Требования к нему невысоки.РП, оформитель проектов.
Оформители часто концентрируются на передаче требований от заказчика команде и оформлении связанной документации, не углубляясь в решение возникающих проблем. Эти проекты, как правило, имеют неопределенные сроки и недостаточно строгие требования со стороны заказчика.
Таким образом, на одну вакансию может придти 400 откликов, из них хочется провести беседу лишь с пятью потенциальными кандидатами, а в конечном итоге выбор сводится к выбору из 2-х наиболее подходящих вариантов.
План проекта
Естественно, наличие даже плохого плана проекта лучше его отсутствия.
Важно планировать деятельность, сроки и ресурсы, исходя из конечного результата, обратным счетом.
Выделение ключевых результатов проекта
В рамках крупных проектов одновременно осуществляется множество активностей, все нужны, важны и срочны. А сил на всё не хватает.
Поэтому важно определить ключевые результаты проекта и сосредоточиться на их достижении. Смотреть надо на цель, а не под ноги.
Следует выделить подпроекты и назначить ответственных за ключевые результаты (РП подпроектов). Необходимо сформировать команды, способные достигнуть поставленных целей, а также четко распределить зоны ответственности.
Важно избегать распыления усилий участников проекта, сосредоточиться на главном.
Живой план проекта
Каждый проект требует наличия плана, разработанного РП. Аналогично, для каждого из подпроектов (ключевых результатов) необходимо составление отдельного плана.
Несмотря на значимость планирования, РП часто уклоняются от его составления, это нормально. Процесс требует определённых компетенций, опыта, информации от заказчика и смелости в формулировании предположений, которые могут быть подвергнуты критике.
Важно договориться, что план может изменяться по мере необходимости, обсуждение плана нормально и без плана жить нельзя.
Наличие даже недостаточно качественного плана предпочтительнее отсутствия такового. План должен содержать описание состава и последовательности работ, сроков и необходимых ресурсов.
Регулярное обновление плана является обязательным, как для контроля за соблюдением сроков, так и для учета изменяющейся ситуации в проекте. Следует пересматривать план проекта примерно раз в месяц с акцентом на задачи, сроки и ресурсы.
План это живой документ, требующий периодической проработки и актуализации.
Защита плана проекта
Защита плана представляет собой событие, на котором РП обосновывает реальность решения задач проекта. Цель состоит в том, чтобы помочь РП провести проверку логики своих идей и обосновать предлагаемое решение.
Защита плана осуществляется путем обратного отсчета от конечного результата: указывая, что именно необходимо получить, в какие сроки и какие ресурсы для этого потребуются.
Ключевым компонентом защиты является критическая цепь работ. Для каждой задачи следует определить возможные последствия ее невыполнения, а также выявить влияние своевременного выполнения на конечный результат — можем ли подвинуть задачу, на какие задачи влияет ее результат, какие задачи влияют на нее.
На основании плана и установленных сроков можно формировать запросы на необходимые ресурсы.
Защита плана означает передачу ответственности за проект на РП при предоставлении необходимых ресурсов и согласовании планируемых результатов.
Заказчик
Успех проекта зависит не только от исполнителя. Заказчику также необходимо вложить усилия в достижение успеха проекта: ставить разумные цели, собирать материалы для работы исполнителя, решать организационные вопросы, в общем тратить время и силы.
Более того, успешно сданный исполнителем проект может оказаться провалом для заказчика: по результатам проекта за рамками проекта на стороне заказчика должны пройти изменения процессов, оргструктуры, подходов. Эту работу часто недооценивают.
Отношения с заказчиком
Надо понимать заказчика.
Заказчик ведет важное дело, в рамках которого наш проект является вспомогательным инструментом. У него множество забот, а проект нужен для более эффективного решения его задач, которые всегда находятся в приоритете. Цель проекта — помочь заказчику, для этого понимать его проблемы, его логику, его пользу от проекта.Ключевые компетенции заказчика часто не связаны с ИТ.
Если бы это было иначе, он бы не обращался к сторонним организациям. Заказчик не всегда способен оценить ход проекта или осознавать ограничения. Договариваться с ним — это отдельная важная работа, и не следует углублять его в детали исполнения проекта. С ним важно заранее согласовать ключевые результаты.Заказчиком должен быть назначен со своей стороны ответственный РП.
Он отвечает перед лицом, принимающим решения (ЛПР), бюджетодержателем и функциональным заказчиком за результат проекта со стороны заказчика и координирует активности на его стороне.Презентация проекта для заказчика не обязана полностью отражать реальности внутри организации-исполнителя.
Например, внутренний план проекта и план для заказчика могут быть различными документами. Заказчику следует предоставить план с контрольными точками, чтобы он мог отслеживать ход проекта и убеждаться, что он движется в нужном направлении. Подробный план у заказчика может навредить проекту, ведь это ограничивает возможности РП по маневрированию ресурсами и порождает необходимость пересогласования. План для заказчика может быть несколько приукрашен по сравнению с внутренним — лишь бы результат соответствовал ожиданиям.Необходимо осознавать, какие задачи просты и сложны для исполнителя, а какие задачи ценны для заказчика.
Понимание этих моментов позволит РП эффективно согласовывать результаты проекта с заказчиком, максимизируя пользу для него и минимизируя затраты проекта.Нужен куратор проекта со стороны исполнителя.
Куратор и РП — это разные роли; куратор — это руководитель РП, с которым заказчик должен быть знаком. Куратор необходим, чтобы заказчик мог обратиться к нему с жалобами на РП, а РП мог ссылаться на «руководство», если у него возникнут вопросы. Совместная работа РП и куратора позволяет выработать общую позицию перед заказчиком.Все аспекты проекта должны быть корректно юридически оформлены.
Важно помнить, что заказчик представляет собой организацию с политическими течениями, внутренней логикой и жизнью. Независимо от отношений между людьми, обстоятельства могут измениться, например, произойти смена ЛПР, изменения мнений функционального заказчика или действия РП. Работы проекта необходимо правильно оформлять, чтобы:
1. Работы были впоследствии оплачены
2. Документы могли быть использованы в случае конфликта.
Управление заказчиком
Заказчика необходимо знакомить с механикой работы исполнителя с самого начала проекта, в дружелюбной благоприятной обстановке.
Конфликты интересов заказчика и исполнителя в проекте неизбежны и нормальны, поэтому следует заранее показать методы их спокойного преодоления. Например, грамотный заказчик будет стремиться выжать максимальную пользу из исполнителя как в рамках технического задания, так и сверх его. А исполнителю нужно вписаться в рамки фиксированной стоимости контракта.
При этом прямое управление заказчиком невозможно, зато существуют непрямые способы управления:
Еженедельный статус для заказчика
Еженедельно РП предоставляет заказчику статус по проекту, который:
Должен быть кратким и понятным для посторонних, детали следует передавать по ссылкам.
Должен содержать актуальные вопросы к заказчику с указанием дат и ссылками на историю («нужно то-то и то-то, запрашиваем в третий раз, первый был месяц назад»).
Должен отражать полную текущую ситуацию по проекту: что было сделано за неделю, что планируется, какие вопросы и проблемы актуальны. Вся картина отражена в статусе, дополнительных активностей нет.
Размещен в доступном для заказчика месте (общий канал, общее письмо), обеспечив доступ к кураторов со стороны исполнителя и заказчика.
Нужно использовать в обсуждениях, чтобы заказчик понимал, что это основа для работы.
Встречи с заказчиком
Каждая встреча должна иметь подготовленную повестку и материалы.
Их необходимо отправить заранее, не нужно устраивать сюрпризов.Важно вести запись встреч.
Записи должны сохраняться в доступном месте для обоих сторон. Заметки и указания по повестке не должен делать РП; его задача — договариваться и активно слушать.После каждой встречи должен быть составлен протокол.
Протоколы пишутся исполнителем, это выгодно исполнителю для акцентирования внимания на определенных аспектах и фиксации договоренностей. Рекомендуется составить юридически корректный документ; если нет — отправить его так же как и статус по проекту, чтобы заказчик мог дополнить или исправить при необходимости.
Тикеты между исполнителем и заказчиком
Грамотный заказчик заинтересован в фиксации задач и комментариев, эффективности работы с ними. Трекер позволяет ускорить процесс работы и легко фиксировать договоренности. Тикеты ведутся в отдельном проекте «для заказчика», внутренние задачи ведутся отдельно.
Фиксация каналов взаимодействий с заказчиком
Все задачи принимаются исключительно через РП, который должен участвовать в коммуникациях с заказчиком.
Все обещания дает только РП.
Команда проекта должна быть в курсе предыдущих пунктов.
Это предотвращает избыточность коммуникаций и обеспечивает управляемость проекта, иначе при увеличении общения членов команды с заказчиком становится непонятно, кто, когда и что обсуждал, и что кому пообещал.
Качество заказчика
Грамотный заказчик это большое везение, с ним будет приятно работать, а результаты проекта будут вызывать гордость за проделанную работу.
Случается, однако, что заказчик некомпетентен:
Считает, что проект может быть реализован исполнителем без участия заказчика.
Например: «Мы вам платим за результат, делайте сами, иначе зачем вы нужны».Ожидает от исполнителя глубоких знаний своего бизнеса.
Похожие задачи в похожих компания могут сильно различаться по сути: процессы в различных компаниях развиваются по-разному. Глубокое изучение задач заказчика должно рассматриваться как консалтинг, а не просто как внедрение ПО. И даже для консалтинга нужно первоначальное погружение в реалии заказчика.Уделяет мало внимания изменениям в своей организации.
Результатом проекта должны стать изменения в рабочем процессе заказчика — новые регламенты, правила работы, изменение оргструктуры и т.д. Эти изменения должны внедряться и во время и после завершения проекта.Занимается микроменеджментом.
Вместо того чтобы устанавливать высокоуровневые цели команде проекта, самостоятельно занимается управлением проектом вместо РП.Плохо организует рабочие процессы.
Отказывается фиксировать договоренности, не обозначает ответственных, тратит время и ресурсы на непродуктивные совещания и т.д. и т.п.Добавляет личные эмоции в рабочие вопросы.
Хамит, кричит, ругается матом и т.д. Использует финансовые отношения с исполнителем и лояльность команды проекта к своей компании для удовлетворения своих личных комплексов.
Случается и наоборот, что заказчик компетентней исполнителя в работе над проектом. Например, требует от исполнителя использования трекера для работы с тикетами.
Что тут делать? Краснеть, читать эту статью и начинать работать как следует :-)
Команда
Расстановка
В рамках проекта планируется разработка и внедрение программного обеспечения, что подразумевает наличие определенных активностей и ролей.
Руководитель проекта (РП)
ответственный перед заказчиком за выполнение всего проекта.Архитектор
ответственный за интеграцию проекта в инфраструктуру заказчика и за применение единых подходов к решению аналогичных задач и технологий на проекте.Ведущий бизнес-аналитик
отвечающий за анализ проблем, стоящих перед заказчиком в рамках проекта.Ведущий системный аналитик
ответственный за настройку ПО и реализацию задач по его доработке.Менеджер
который будет отвечать за коммуникацию между разработчиками и внедренцами.Ведущий разработчик/тимлид
отвечающий за процессы разработки в проекте.Менеджер по организационным вопросам
ответственный за координацию команды (подключение участников, проведение встреч, ведение протоколов).Тестировщик
который будет ответственен за обеспечение качества работы разработчиков и корректности настроек системы.DevOps
отвечающий за работу внутренних стендов в процессе разработки и за запуск итогового продукта на стороне заказчика.Куратор проекта
который контролирует качество выполнения работ и обеспечивает эскалацию проблем для заказчика.Администратор проекта
ответственный за правильное оформление документации.И, конечно, необходимое количество аналитиков, разработчиков, тестировщиков для выполнения задач проекта.
На эти роли необходимо четко определить ответственных и сформировать команду проекта, разделив ее на группы по 5–9 человек для повышения эффективности работы.
Отношения с командой
Совместное дело
Результаты проекта являются совместным достижением. РП несет основную ответственность за эффективность работы всей команды, он не представитель заказчика на стороне исполнителя, а работает над проектом вместе с командой.
Нельзя придумывать дедлайны.
РП не должен самостоятельно устанавливать необоснованные сроки, обманывая команду, так как это может привести к недоверию, а потом и саботажу со стороны коллег.Нужно отвечать за все результаты всех работ перед заказчиком.
Критику со стороны заказчика надо принимать на свой счет в первую очередь, а не сваливать на исполнителей.
Самодисциплина
Управление проектом (как и любое управление) требует самодисциплины, например:
Подумать самому, потом спрашивать
Писать и читать тикеты самостоятельно. Прежде чем обращаться к коллегам, стоит задать себе вопрос «где найти ответ?» и попытаться найти его самостоятельно.Планировать встречи заранее
Избегать спонтанности, чтобы все стороны могли подготовиться.Исключать переход на личности.
и т.д.
Переработки
Переработки свидетельствуют о плохом управлении проектом и являются показателем качества работы руководителя проекта. Переработки — это простой дешевый краткосрочный способ решения проблем, который может привести к выгоранию и распаду команды. Отсюда выводы:
Переработки должны быть оформлены.
Переработки должны быть оплачены (минимально в двойном размере, по ТК).
Переработки должны быть согласованы РП до начала переработки.
Качество РП и качество команды
В некоторых случаях сотрудники, активно заинтересованные в результате проекта, могут не желать видеть РП в команде. Потому что плохой РП повышает риск неудачи проекта, например:
Принимает нереалистичные обязательства перед заказчиком
Мешает диалогу с заказчиком
Создает бесполезную суету внутри проекта
В конечном итоге, такой РП может и сбежать перед началом сдачи проекта.
Рассмотрим два варианта:
Эффективный РП и неэффективная команда: РП идентифицирует проблемы и предлагает куратору необходимые меры для достижения результатов.
Неэффективный РП и эффективная команда: Команда справляется с трудностями, несмотря на недостаточную поддержку. Проблемы в проекте накапливаются, а информация о них не выходит из команды, что повышает риски провала проекта.
Выводы для куратора:
Необходимо периодически отслеживать ситуацию в проекте через голову РП.
Уютная тишина со стороны РП может свидетельствовать о наличии серьезных проблем.
Организация работы
Обсуждение организации работы, применительно к нашему проекту.
Совещания
Длительность совещаний не должна превышать 30 минут, а количество участников — 10 человек.
Все встречи должны назначаться через календарь и назначаться заблаговременно.
Каждое совещание должно иметь четкую повестку, протокол и фиксацию принятых решений с назначением ответственных.
Участники обязаны готовиться к совещаниям.
С результатами совещаний необходимо активно работать. Важно не только договариваться, но и отслеживать выполнение принятых решений.
На совещаниях определяются ответственные за решение конкретных задач, вместо их непосредственного решения. Для обсуждения сложных вопросов следует выделять специальное время и организовывать соответствующие встречи с адекватной повесткой.
Встречи
Нужны ежедневные митинги команды по 15 минут в фиксированное время. Каждый участник отвечает на вопросы: что делал, что планирует делать, какие возникли проблемы.
Еженедельное планирование: РП представляет план на неделю.
Оптимально проводить планирование по понедельникам, чтобы настроиться на полноценный рабочий режим.
Все задачи должны соответствовать принципам SMART.
Итоги планирования нужно отправить заказчику (возможно, в трансформированном виде — см выше)
Нужно подвести итоги прошедшей недели и коротко обсудить текущий статус проекта.
Планирование с заказчиком — по понедельникам.
Предметные встречи с заказчиком — в середине недели.
Ежемесячные пересмотры плана проекта и ретроспективные совещания — по пятницам.
Учет задач
Учет задач является важнейшим аспектом работы. Однако не все это понимают.
У каждой задачи есть процесс выполнения, в котором задействованы разные участники. Важно обеспечить удобный обмен постановкой, материалами и историей задачи.
Всегда существует риск пропажи участника, поэтому необходимо фиксировать его задачи и статус работ.
В учете задач необходимо фиксировать достигнутые договоренности, а не всю историю переговоров. Обсуждения могут проходить устно или в чатах, а результаты следует фиксировать в трекере.
Учет задач позволяет узнать статус выполнения задачи не отвлекая исполнителя.
Учет задач позволяет вести учет затрат времени и дальнейший анализ по задачам.
ПО
Чаты:
Внутренние чаты должны иметь возможность обсуждения в тредах (например, Slack, Mattermost). Использование Telegram не рекомендуется.
Внешние чаты должны выбираться на основе удобства для заказчика (часто это, к сожалению, Telegram).
Трекер задач:
Подойдет практически любой трекер, например, Redmine. Основные поля: описание задачи, комментарии (включая вложения), автор, исполнитель, срок — есть в любой системе.
Внутренний трекер обязателен, внешний — желателен.
Идеальная ситуация — все задачи зафиксированы в трекере. На практике это может быть сложно, но к этому нужно стремиться.
Простая схема работы: исполнителем назначается тот, кто должен выполнить следующее действие, а закрывает задачу автор.
Инструмент планирования:
Без MS Project можно обойтись, Excel будет достаточно. Сложные инструменты могут отвлекать от понимания сути работы: MS Project позволяет играть задачами как кубиками, и либо кубики получатся слишком высокоуровневые, либо Project начнет дублировать трекер и требовать колоссальных усилий для ведения связей между задачами.
Стенды
Необходимы три проектных стенда на стороне исполнителя:
Внутренний стенд для разработки: предназначен для тестирования и ознакомления командой внедрения с протестированными функциями.
Внутренний стенд для настройки: для работы внедренцев и консультантов по настройке системы под заказчика.
Демонстрационный стенд для заказчика: используется для презентаций, например, по результатам спринтов или контрольным точкам.
Необходимо установить четкие процедуры переноса данных между стендами с недопущением доступа разработчиков к данным стендов настройки и демонстрации.
Стенды на стороне заказчика тут не упоминаем, они должны учитываться отдельно и могут также включать внутреннее тестирование, демонстрацию и продуктивную среду.
Таймшиты
Ведение таймшитов обязательно. Они необходимы для контроля бюджета проекта, анализа узких мест и планирования затрат на основе анализа.
Если участники проекта не готовы заполнять таймшиты, это должен делать менеджер на основе планов и итогов недели. Таймшиты должны отражать реальное положение дел, а не являться инструментом давления на сотрудников. Попытки манипулировать командой на их основе могут привести к искажению отчетности.
Риски
Необходимо учитывать риски, такие как bus factor, задержки со стороны соисполнителей, сроки поставки оборудования, процесс принятия решений заказчиком и другие факторы — с этим понятно.
Хочется отметить два важных момента:
В случае недостижимости результата проекта, важно управлять проектом таким образом, чтобы ответственность за срыв не легла на исполнителя. Как говорится:»Не обязательно бежать быстрее медведя, надо бежать быстрее соисполнителя.» А если все соисполнители молодцы — прекрасно, результат проекта будет достигнут.
Существует риск недопонимания между исполнителем и заказчиком: заказчик, не обладая специальными знаниями в сфере исполнения проектов, может иметь собственное восприятие ситуации. Это может привести к тому, что он испугается, остановит проект, откажется от него или кардинально изменит подход. В итоге возможен парадоксальный выбор: «успех проекта при встревоженном заказчике» или «срыв проекта при успокоенном заказчике». Окончательное решение зависит от конкретной ситуации.
Как понять, что все хорошо?
Заказчик, как правило, не будет открыто хвалить исполнителя в процессе работы над проектом. Благодарственное письмо, рекомендации и положительные отзывы будут после завершения проекта.
Поэтому главный признак успешного хода проекта в том, что во время встреч Заказчик занимается решением своих проектных вопросов, а не проблемами исполнителя.
Примеры таких вопросов:
Определение участников обучения;
Договоренности с соседними департаментами;
Актуализация регламентов работы;
Получение необходимых материалов для успешной реализации проекта.
Вывод
Качественное управление проектом — тяжелый труд, на который нужно много сил и нервов, и который тяжело оценить ведь в результате будет «все хорошо, проблем нет».
