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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О чёрной и белой магии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Внутри команды проекта возможны совместные активности двух типов:

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

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

4. Руководитель пакета работ – член команды, на которого целиком возложено полностью какое-нибудь одно направление. Например, Руководитель ИТ отдела отвечает за все вопросы про сервера. Он вводится в команду проекта один, а его подчинённые остаются за границами. Все задачи, в которых важную роль играет серверная группировка передаются для анализа, декомпозиции и оценки именно ему. Это может быть покупка оборудования, его монтаж, развёртывания программного обеспечения, выполнение задач по обслуживанию. У него есть власть над ресурсами – его подчинёнными и полномочия общаться напрямую с поставщиками и полномочия на координацию. Сотрудники функционального подразделения, возглавляемого членом команды, не несут прямой ответственности за результат проекта или фазы проекта, могут меняться волей руководителя отдела, поэтому вынесены за границы команды проекта.

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

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

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

Состав команды и когда кто нам может оказаться нужен.

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

Поэтому перед руководителем постоянно стоят вопросы «Кто» или «Что нужно сделать»? – в проект нужен человек с нужными навыками или для выполнения конкретной задачи или этапа. Например, сотрудник с навыками дизайнер UX/UI нужен только на начальном этапе, пока не сформировался интерфейс продукта. Но если помимо навыков в рисовании человек разбирается в смежных областях, например в Scrum и из него может получиться отличный Scrum Master, он может пригодиться для других этапов проекта. И вторая группа вопросов – «Искать или Готовить?». Мы хотим сразу готового специалиста и не готовы вкладываться в его развитие или же согласны взять сотрудника с «потенциалом», и довести его до необходимой «кондиции» за счёт различных форм обучения. На рынке почти невозможно сразу найти специалиста по узкоспециализированному ПО или оборудованию, которое может использоваться в техническом решении вашего проекта. Скорее всего придётся учитывать в плана проекта ранее заполнение потенциальными кандидатами вакансии, возможно даже несколькими. Обучать их, с прицелом что в нужный момент проекта они окажутся готовыми к выполнению запланированных операций.

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

Рис. 1.3. Таблица Должности – Задачи

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

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

В такие моменты нашим лучшим помощником становиться Excel и два вопроса: «Что делать?» и «Когда делать?». Для выполнения упражнения нам ещё понадобится план реализации проекта.

Шаг 1. Создайте новый файл и заполните первые 3 столбца названиями:

Рис. 1.4. Первый шаг заполнения состава команды.

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

Шаг 2. Заполните столбцы «Что делать» и «Когда делать». Возьмите за основу план проекта или иерархическую структуру работ. На забудьте указать задачи менеджмента, обучения пользователей, управление рисками и бюджетом, встречи с заказчиком. В когда делать можно указать, если известно конкретные даты начала и конца, или названия этапа жизненного цикла проекта, как на рис 1.5.

Рис.1.5. Заполненные столбцы «Что делать» и «Когда».

Шаг 3. «Кластеризуйте», по областям получившиеся задачи из столбца «Что делать. И отвечая на вопрос «Эти работы лучше подходят для…» и проставьте условные должности «Менеджер по…» или «Специалист по», «Главный по…». Например – «Специалист по видеонаблюдению», на рисунке 1.6. обобщённые задачи и должность выделены фиолетовым и оранжевым.

Рис. 1.6. Результаты кластеризации.

Часть схожих обязанностей, которые оказались запланированы в разные этапы проекта можно объединить под одной персоной. Например, можно попробовать совместить «Специалист по видеонаблюдению» и «Специалист за сервера и сеть» в одном специалисте, потому что очень схожая сфера работ и инструменты, которые они используют. У РП будет несколько опций поиска на рынке специалиста в зависимости что нужно раньше по времени – брать системного администратора и доучивать его видеотехнологиям, или искать готового спеца по видеонаблюдению и догнать навыки по серверам и прочему в процессе проекта.

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

Шаг 5. Возьмите существующие или придумайте должности членам команды. Самый творческий шаг, пусть и ограниченный правилами формирования штатного расписания в корпоративной культуре.

Шаг 6. Попробуйте определить количество требуемых штатных единиц внутри команды.

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

В результате РП получит более точное и качественное представление о членах команды. Уже будет точное понимание какую группу операций необходимо передать внешнему подрядчику, и внести своевременно корректировки в бюджет проекта. Таблицу можно использовать как график привлечения персонала в проект, ведь тут чётко видно на каком этапе проекта понадобится сотрудник с необходимыми в этот момент навыками и компетенциями. Для моментов, когда будут наращиваться внутренние компетенции, учесть необходимость поддержки продукта, понимая кто и для каких регламентных операций может оказаться нужным. А зная приблизительное число сотрудников, можно посчитать размер ФОТ и внести бюджет проекта. Моя практика показывает, используя такой инструмент удаётся состав команды проекта сократить на треть в отличии от приведённого в начале раздела способа.

Глава 2. Управление разными типами сотрудников.

Естественный подход при управлении

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

Рис. 2.1 Естественный подход к управлению

Стартовой точкой для формирования становятся сильные врождённые стороны руководителя проекта, см. рис. 2.1. В основе их лежит его характер, тип личности и внутренней мотивации.

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

– построение логических схем в голове и на бумаге

– просчитывать на несколько шагов вперед;

– внимание к деталям;

– грамотная речь, устная или письменная;

– скорость принятия решений в условиях нехватки информации;

– критически настроенный ум;

– способность видеть суть проблемы;

– умение чувствовать эмоции и выявлять ложь.

Например, когда РП силен в письме – большая часть взаимодействия с командой пойдёт по пути email и задач в тикетной системе.

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

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

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

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

Важность ритуалов для создания системы

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

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

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

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

Ритуалы как правило дальше «утренней» летучки у руководителей проектов не идут. Такой рутинный процесс помогает участникам лучше организовать своё время и ресурсы.

Будет продуктивно, если руководитель проекта сформирует и для некоторых событий в проекте:

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

– Единообразное поведение РП когда есть повод отпраздновать празднования успехи или признание достижений способствует формированию позитивного климата в команде.

– Регулярный запрос обратной связи от стейкхолдеров по следующим вопросам:

*удовлетворенности информирования о проводимых мероприятиях командой проекта.

* Скорость и качество устранения неисправностей в продукте проекта.

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

Работа со сложными членами команды

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

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

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

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

Со временем правильные матрицы приходят у человека в привычку. Моя практика работы с такими сотрудниками свидетельствует, что или удастся это сделать за 2 месяца или мы расстаёмся.

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

Рис.2.2 Сетка координат «Добра» и «Зла»

Что бы инструмент работал хорошо необходимо выполнить несколько не сложных шагов:

Шаг 1. Обозначить проблему и график работы по ней. Необходимо объявить о том, что у члена команды фиксируются проблемы с продуктивностью. Кто и в чем не доволен его работой, и вы как руководитель будете с этим работать. В календарь прошиваются регулярные встречи, face-to-face, тайминг которых не более 20 минут. В этот момент не придумывайте дедлайны и сроки, когда вами будет принято решение о дальнейшей судьбе человека в проекте. Тайминг на данный шаг не больше 45 минут.

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

Например, для строки «Отсутствие жалоб от VIP стейкхолдеров» такими критериями могут быть:

– мне не звонят VIP и не жалуются на тебя.

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

– просим подтвердить, что все «ОК», и только после этого закрываем заявку от VIP.

– создать тикет в систему за VIP стейкхолдера не грех.

– хорошо, когда они звонят мне и хвалят тебя;

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

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

Шаг 3. Выставление оценок. Это упражнение обязательно делается до встречи с нашим «сложным» членом команды. Например, одну неделю, и в конце периода выставьте ваши исключительно субъективные оценки по 10 бальной шкале. Не пытайтесь быть объективными и вспоминать каждый факт. Ставим первое что пришло в голову, по внутренним ощущениям. Хорошо, если вы ведёте записи, тогда вам не потребуется тратить много энергии на воспоминания.

Тайминг не больше 10 минут.

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

Тайминг не больше 20 минут

Шаг 4. Принять итоговое решение. Соберите необходимую фактору после достаточно большого количества встреч. Что бы хорошо увидеть, насколько все меняется, достаточно пяти. Тут руководитель сам принимает решение -сколько времени он готов тратить время на сотрудника и вкладываться сам, повторяя шаг номер 3.

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

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

В целом такой инструмент не только первая, но последняя линия для принятия управленческих решений. Очень часто для увольнения сотрудника руководителю в первую очередь надо подготовить себя к неприятному разговору. Собрать факты, убедить самого себя, что по-другому никак. Любого руководителя можно понять, найти на замену специалиста не просто, на какой-то промежуток времени увеличится работа его самого. Да и сам руководитель со временем может просто остыть, неприятные моменты и ошибки совершенные членом команды уже не будут казаться такими острыми. Такая таблица как раз даст вам необходимый набор фактов и позволит убедить себя, что исправления не будет и не стоит давать самый последний шанс. И будет прекрасным аргументом для вас на встрече, где вы сообщите члену команды что он её должен покинуть. А ему крыть в ответ будет нечем.

Критерии хорошо сделанной работы членом команды

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

В первую очередь надо договорится о том, что есть «задача готова», чётко определить точку, когда мы понимаем, что мы работы завершили, заказчик понимает это точно также как и мы. В Scrum, например, это и называется «Критерии готовности» (англ. definition of done).

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

Время

– работа выполнена в оговоренный с Заказчиком срок или раньше;

– во время работы Заказчика информировали заранее о изменении срока;

– согласованное окно «downtime»³ не было превышено.

Деньги 

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

– превышение Финансовых или трудовых расходов своевременно было согласовано с Заказчиком; 

Качество

– жалобы на результат работы не поступали;

– "сущность" надо которой работали не стала хуже. Соблюдение принципа «0/+»;

– проверяю результат "со стороны заказчика" (в том числе вместе с заказчиком);

– во время работы Заказчика информировали заранее о изменении качества;

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

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

– работа была выполнена без нарушений требований регламентов, ГОСТов, закона;

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

Информация о членах команды всегда под рукой

Мы все любим чёткие факты, точное время. Но как эту всю информацию о сотрудниках удержать в голове. Когда сотрудник пришёл в проект, когда и как изменялась его зарплата, когда хвалили или жаловалось на сотрудника. Для ключевых сотрудников, кто мне как руководителю проекта важен в этот момент времени, я завожу отдельную папочку на каждого. Это прямо «аналоговая», все документы в ней существуют одном экземпляре. Мне не нужны электронные копии, я работаю по старинке с бумагой. Я называю это «личное дело» и постепенно наполняю информацией. Так как это документы только внутреннего пользования, только для моих глаз, я пишу туда всю информацию без прикрас. Например, даже такие эмоциональные замечания, что мне пришлось за действия сотрудника извиняться перед стейкхолдерами и что я испытывал в этот момент, что именно мне сообщил человек в ответ на мои сожаления. Такая информация полезна в дальнейшем, когда на регулярной основе, я провожу анализ личных дел всех сотрудников. После увольнения члена команды на папку ставится отметка «Уволен, дата» и убирается в архив. Несколько раз мне звонили с другие работодатели и просили дать характеристику на сотрудника. И я мог дать её, основываясь на зафиксированных мной фактах, а не на нечётких воспоминаниях.

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

За годы практики состав такого дела меняется, но в основном носит следующий состав:

– Первое резюме по приходу на работу, также ответы на опросники если такое есть

– Обновленное резюме, по результатам последнего полугода работы в Компании

– Фотография

– Сертификаты (выданные до и во время работы, информация о внутреннем обучении)

– План на испытательный срок

– Анкета адаптации сотрудника по результатам испытательного срока

– Информация об изменении зарплаты

– Благодарности от коллег

– Информация о жалобах, обратной связи о работе сотрудников от руководителей смежных подразделений

–Результаты прохождения экзаменов и получения внутрикорпоративных званий. Грамоты

– Отчеты о инцидентах и любые другие отчеты, рапорты

– Лист поручений и взятых обязательств.

О нескольких нюансах, почему именно такие документы кладутся в дело:

Обновленное резюме, по результатам последнего полугода работы в Компании – Раз в полгода⁴ сотрудник принудительно обновляет своё резюме по моему поручению. Это больше «рефлексивная» практика. Чтобы сотрудник мог проанализировать полгода

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

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

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

Немножко «Чёрной магии» – иногда, чтобы поддержать коллегу я сам выискиваю повод, даже бывает пишу текст благодарности, и прошу стейкхолдера написать мне или опубликовать на общем ресурсе.

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

Команда проекта в кризисные моменты

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

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

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

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

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

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

– Первичный срок мобилизации. Конечно, сразу не понятно, на сколько может затянуться процесс устранения аварийной ситуации или исправления сложной ситуации. Но обозначить какой-то срок в часах или днях сотрудникам необходимо. Даже если обстоятельства изменятся, лучше будет обсудить новый график, чем держать людей в неведении. Это может быть максимальное время привлечения к работе на сегодня, например до 22:00, чтобы исправить кусок кода, приводящий к ошибке, или до конца недели работаем до 20:00, чтобы нагнать отставание.

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

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

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

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Перевод автора, цитата из первоисточника «A set of individuals performing the work of the project to achieve its objectives ». PMBOK® GUIDE Seventh Edition, Project Management Institute, 2021.

Вернуться

2

Капслок , от англ. слова "caps", обозначающего "заглавные буквы". В переписке написанное заглавными буквами приравнивается к крику или повышенному тону и злоупотреблять этим считается неприличным.

Вернуться

3

Время недоступности сервиса

Вернуться

4

Про это в офисах ходит шутка – "Что это пролетело?" – "Это полгода, они тут часто пролетают."

Вернуться