Проектная команда под контролем: Как достигать результатов вместе

Сергей Барамба

Проектная команда под контролем: Как достигать результатов вместе

Введение

Дорогой читатель, спасибо что выбрал мою книгу.

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

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

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

Особое внимание мной было уделено практике, кейсам и рекомендациям, сформировавшихся на личном опыте управления командами различных проектов более чем за 15 летний опыт.

Основные темы затронутые в книге:

– понимание что же такое проект и как в него вписывается команда;

– способы и методы эффективного формирование команды и определение ролей;

– способы работы со сложными подчинёнными;

– ошибки которые допускает руководитель проекта в вопросах создания и развития команды проекта;

– постановка задач и обеспечение своевременной обратной связи от членов команды проекта;

– о выстраивании эффективных коммуникаций между всеми участниками проекта.

– мотивация и развитие сотрудников;

– разрешение конфликтов;

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

Приятного чтения, ваш Сергей Барамба.

Глава 1. Проект и его команда

Понятие проектной деятельности.

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

Операционная деятельность

Наиболее лучшим образом сущности нашего мира понимаются в сравнении с чем-то другим. Для наилучшего понимания «Проекта» лучше всего подходит его антагонист – «Процессная деятельность», иногда её называют «Операционная деятельность».

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

Цель такого процесса – обеспечение «бесконечно» длительной и устойчивой работы организации. А значит у него нет конца, а качество может результата чётко описано регламенте и любые отклонения являются нарушением.

Проект

И вот мы постепенно подошли к понятию что такое проект.

«Проект – это временная попытка создать уникальный продукт, услугу или результат».

К основным свойствам проекта можно выделит следующее:

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

Управление рисками: Проектная деятельность требует активного управления рисками, так как каждый проект может столкнуться с уникальными вызовами и неопределенностями.

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

Стейкхолдеры: лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта. Термин на русский язык можно перевести, как «заинтересованная сторона».1 Кстати команда тоже подпадает под это определение и в целом воспринимается в двух разрезах – как ресурс для достижения целей проекта, и как стейкхолдер который определяет каким будет итоговый продукт.

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

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

Продукт

В определении «Проекта» выше встречается знакомый каждому термин «продукт», но что он обозначает в рамках управления проектами. Оказывается, это настолько важный термин, что в неизменном виде повторяется в PMBOK минимум 4 раза. «Продукт – это артефакт, который производится, поддается количественной оценке и может быть как самим конечным элементом, так и компонентом другого продукта».2 Собственно ради продукта и стартует проект, вся деятельность оказывается направленной что бы создать его и решить какую-то важную бизнес-задачу. В рамках проектного управления становится важным, как продукт будет восприниматься пользователями и как он будет соответствовать требованиям и ожиданиям заинтересованных сторон.

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

Продукт может создаваться как в процессе проектной деятельности, так и операционной. Команда проекта может более эффективно создавать продукт, внося в него на лету изменения, обеспечивая соответствие конечного продукта ожиданиям пользователей и требованиям рынка. Что, в свою очередь, способствует повышению результативности и успешности проектов.

Созданный в результате операционной деятельности продукт был определён ранее, задокументирован в регламенте и отклонения, т.е. внесения изменений в продукт на лету, является нарушением.

Разработка продукта – это путь от идеи до финальной версии, готовой к использованию.

Может состоять из проектов и фазы могут повторяться:

– формирование идеи;

– исследование;

– UX 3– «Путь клиента»;

– создание MVP

– тестирование

– разработка

– продвижение

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

Современные формы реализации ИТ проекта

В современной литературе по проектному управлению выделяют три основные формы – Традиционная, agile и гибридная. От выбранной формы реализации резко зависят роли, инструменты, права, полномочия и обязанности основных участников внутри проекта: Руководителя проекта и членов команды.

Традиционная

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

Рис.1.1. Водопадная модель управления проектами.

Это немножко не корректно, и, если детально изучить процессы и подходы, на самом деле в PMBOK говорит вовсе не про «водопад», а про «итеративный подход».

Рис. 1.2. Итеративная модель управления проектами

В рамках этого подхода проект выполняется через последовательные циклы их называют «итерации», позволяющие постепенно развивать и улучшать продукт или услугу.

Сам итеративный подход обладает следующими свойствами:

– требования могут быть динамичны, в «водопаде» они фиксированы, и операции проходят

один раз, последовательно;

– планирование происходит методом набегающей волны4, в водопаде планирование выполняется только один раз;

– поставка продукта заказчику одна, в самом конце, как и в водопадной модели.

– цель применения такого подхода – корректное решение, в водопадной же модели – управление стоимостью за счёт сокращения или оптимизации этапов.

В традиционной модели описываются следующие фазы проекта:

Инициация: Формируется определяется цель проекта, его обоснование и основные заинтересованные стороны, проектная команда и разрабатывается предварительный план. В конце фазы – руководитель проекта должен получить «зелёный свет» на выполнения проекта что бы перейти на следующий этап. Выполняется один раз.

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

Исполнение: выполняются запланированные задачи силами команды проекта. Может повторяться множество раз. Следующий этап цикла, после планирования.

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

Закрытие: После завершения всех задач проекта, проводится финализация результатов и передача продукта заказчику. Выполняется один раз.

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

Использование такого подхода чётко определяет правила, методы и инструменты, которые должен применять руководитель проекта по отношению к команде – иерархия, распределение обязанностей, делегирование, чёткий контроль, планирование в обучении персонала, распределение ролей и исключение не нужных на данном этапе членов команды.

Agile

Обобщающий термин для целого ряда подходов и практик, которые акцентирует внимание на гибкости, сотрудничестве и быстром реагировании на изменения в проекте. Agile основывается на принципах, изложенных в Манифесте Agile5, который был разработан в 2001 году группой разработчиков программного обеспечения. В русскоязычной среде Agile – переводится как «гибкая» методология разработки.

Agile концентрируется вокруг ключевых практик:

–Очередь задач

–Доска

–Итерации

–Пользовательские истории

–Таймбоксинг (англ.Timeboxing)

–Ежедневные собрания

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

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

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

Для руководителя проекта необходимо последовательно воспитывать в членах команды открытость, сотрудничество и готовность к изменениям, менять своё мышление

Самыми популярными фрейморками6 является Scrum и Kanban. Свод знаний о данных подходах опубликован в двух канонических книгах:

– Scrum Guide, произносится как «Скрам гайд», последняя версия издана в Ноябрь 2020, объём 16 страниц7

– Kanban Guide, произносится как «Канбан гайд», последняя версия издана в Декабре 2020 , объем 9 страниц.

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

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

–Указывать что и как делать команде и Scrum Master;

–Контролировать все и вся. Особенно через отчеты;

–Включать «начальника» и вносить в спринт новые срочные задачи;

–Позволять стейкхолдерам не конструктивно коммуницировать с командой;

–Позволять отчитываться “себе” на Daily Scrum.

Руководитель проекта по отношению к команде в первую очередь должен принести описание проблемы и предоставляет возможность найти способы решения команде, доверившись ей в том, что они добьются результата самым лучшим способом. Управление командой в Scrum или Kanban резко ломает традиционные менеджерские методы, к которым вы привыкли. А сами фреймворки вводит серьёзные ограничения на способы воздействия на команду проекта отказавшись от привычных постановок задач. Например, в SCRUM руководитель проекта не имеет права по-своему хотения прийти в команду и заставить выполнить задачу, которой нет в беклоге спринта.

Гибридная модель

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

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

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

Определение роли руководителя проекта

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

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

Часто возникает вопрос – важны ли глубокие знания в предметной области для РП? В качестве ответа предлагаю придерживаться формулы – чем сложнее и масштабнее проект, тем менее важны компетенции руководителя как эксперта в предмете, например «ИТ-шника», но сильнее необходимы как «управленца». Наличие «hard skills» в предметной области продукта становится крайне полезным, но перестает быть необходимым.

Жизненный цикл взглядов РП на команду проекта.

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

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

На рис. 1.4. приведён типовой жизненный цикл проекта в водопадной модели. И на каждом из этапов руководителя проекта поджидают интересные вопросы, к решению которых было бы неплохо подготовиться на ранних этапах и вшить это в планы и расписания. Многие вопросы взаимосвязаны между собой и разными этапами, словно создают целую экосистему из событий и действий, которые направляют РП и команду, держать под контролем человеческий фактор.

Рис. 1.4. Взгляд на команду проекта с точки зрения жизненного цикла проекта.

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

Планирование, ключевой вопрос «Когда?»: Даже в начале проекта думая о планировании необходимо ответить на такие вопросы, которые лягут в планы и расписания проекта. Ведь необходимо учесть обучение сотрудников, без которого будет не возможно создание продукта, включая и обучение основам в выбранной методологии, а это время и бюджет. Не забудьте продумать названия должностей, подчинённость, уровень заработных плат и формат премирований. На этапе планирования РП должен чувствовать текущее состояние рынка, и заранее запланировать открытие вакансии что бы сотрудник оказался в штате в момент, когда его компетенции понадобятся. Если об этом не задуматься ещё в стадии инициирования, на планировании могут оказаться упущено внесение в календарь необходимых мероприятий.

Разработка и Внедрение ключевой вопрос «Как?»:

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

Завершение, ключевой вопрос «А дальше?»

В последние минуты перед стартом проекта нужно задуматься о последнем дне проекта. Попробуйте оценить, как вы привели свою «Команду Мечты» сюда, сколько энергии это вам стоило. Много ли сотрудников покинуло команду, какие компетенции вы и ваши коллеги нарастили в этом проекте. Знают ли ваши сотрудники что они будут делать.

Первая мысль, которая приходит к начинающим руководителям длинных проектов – «Это так долго, у меня ещё куча времени. Ближе к концу будем думать о завершении». Время летит очень быстро, РП подхватывает вихрь рутинных операций, проблем, бед, и задумать о таких вещах уже нет времени. А ведь после проекта жизнь не заканчивается, есть этап «Сопровождения, а в ИТ проектах часто это делает таже команда что и создавала продукт. Все мы помним сказу Пушкина «Про золотую рыбку». Ведь если бы дед в первый момент задумался о всем жизненном цикле проекта по улучшению жизненных условий, возможно где-то раньше остановился бы и не оказался снова у разбитого корыта. В примере из реальной жизнь – можно построить менеджмент таким образом что половина компетентных сотрудников разбегутся по пути, а в конце некому будет обеспечить качественное сопровождение. И все потому, что не задумывались о конце и перегибали палку там, где можно было бы этого не делать.

Границы команды проекта, иерархия.

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

К Организационным единицам в проекте относится – Проектный комитет, Куратор проекта, Руководитель проекта, Команда управления проектом, Проектная команда. При этом в границы команды проекта подпадают только последние три.

Команда управления проектом, в английской литературе – «project team management», бывает централизованная и распределённая

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

В распределённой команде управления права, обязанности и ответственность распределяется между некоторым количеством членов команды проекта.

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

Иерархическая схема команды проекта приведена на рисунке 1.3

Рис. 1.3. Иерархическая структура команды проекта.

Несколько тезисов по этому рисунку:

1. Подрядчики или партнёры в зависимости от уставных документов проекта могут оказаться внутри границ или вне их. От этого зависит скорость взаимодействия и количество необходимых документов для согласования выполнения ими работ.

2. По умолчанию команда управления проектом не создаётся, и РП по умолчанию осуществляет несёт ответственность за все процессы внутри проекта – управление рисками, бюджетирование и прочие. В случае введения в состав – эти обязанности делегируются специальсно ответственным лицам внутри команды, например риск менеджмент полностью передаётся отдельному специалисту.