Города берет пехота

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

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

И еще одно важное направление деятельности руководителя проекта – это управление персоналом, выстраивание команды и ее мотивация.

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

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

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

Обратите внимание, что доклад называется «Города берет пехота» - что такое «пехота», и как называть тех, кто «не пехота»?

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

• на «звезд», которые прошли определенный карьерный рост, все могут и умеют, сами могут реализовать сложную задачу.

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

И со «звездами», и с «пехотой» есть определенная специфика работы.

Цель доклада – понять, как выстроить работу с сотрудниками команды на проекте.

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

Мы рассмотрим следующие темы:

• какие бывают команды на проектах;

• рассмотрим команду с позиции «черного ящика» – что мы можем от нее ожидать, как воздействовать;

• сравним «звезд» и «пехоту»;

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

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

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

В целом проекты 1С можно разделить на градацию:

• Небольшой проект – в нем участвует до 5 сотрудников, выполняется в рамках полугода. Например, внедрение ДО.

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

• Есть крупные проекты – я здесь субъективно поставил планку 15+ сотрудников в команде. Это такие проекты, которые растянуты по времени, где команда уже не умещается за одним обеденным столом. Крупные проекты меньше года не делаются.

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

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

Если мы говорим про небольшие проекты:

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

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

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

• Чтобы правильно выполнить работу, сотрудник должен четко понимать приоритеты и располагать своей компетенцией. Немаловажный навык на небольших проектах у сотрудников – способность достигать результата (не у всех сотрудников эти скилы есть).

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

А в небольшом проекте это все оголяется, и если у сотрудников такой способности нет, все шишки полетят в руководителя проекта. Если сотрудник по какой-то причине результата не достиг – это делает руководитель проекта.

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

В среднем проекте:

• Состав сотрудников более разнородный: допускает наличие и стажеров, и «звезд». В основном мы ориентируемся на то, что работу на среднем проекте могут выполнять середнячки.

• У них появляются группы по интересам, тусовки. Управление таким коллективом переходит в плоскость эмоционального интеллекта. Если мы будем руководствоваться только директивными указаниями, писать на листочке задачу под подпись, требовать результата… До какого-то момента времени это может иметь эффект, и на каких-то этапах это полезно. Но если мы хотим, чтобы люди выкладывались, мы должны с ними эмоционально соединяться. Мы должны понимать, зачем человек вообще пришел на проект, ради чего он здесь, что он ожидает дальше. Насколько ему комфортно? Или его, наоборот, нужно выводить из зоны комфорта, чтобы его позиция сдвинулась.

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

• На первое место в работе сотрудника выходит понятие культуры проекта. Носителем культуры проекта является тусовка.

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

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

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

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

Если рассматривать пример крупного проекта:

• Там состав коллег будет совсем разнородный.

• Характер коммуникаций будет иметь некую структуру.

• Руководитель проекта здесь не имеет возможности часто общаться с сотрудниками – это разовые взаимодействия, элемент поощрения или наказания. Общение руководителя проекта и воздействие на команду должно быть выверенным, точечным и носить характер плановости: работа с рисками, планирование изменений культуры проекта.

• Среда, через которую руководитель доносит информацию до команды: культура проекта и то, что мы проговорили для среднего проекта. Здесь структура влияния на результат сотрудника остается той же.

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

Жизненный цикл крупного проекта автоматизации

Если мы говорим о большом проекте, он состоит из многих этапов:

• моделирование;

• проектирование;

• разработка;

• опытная эксплуатация;

• опытно-промышленная эксплуатация.

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

Ключевые потребительские свойства команд

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

• Главное потребительское свойство команды – компетенции сотрудников. Я бы рекомендовал поделить компетенции на три части:

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

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

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

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

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

• Ремонтопригодность – еще одно важное качество для команды. Например, если сотрудник заболел, ему нужно в отпуск и т.д. В этом случае у команды возникает сбой – часть работы, которая была распределена на сотрудника, выполнить некому. Один из способ решения – остановить работу, перенести ее. Но более желательное воздействие на проект – замена сотрудника. Этим и определяется ремонтопригодность.

• Еще одно качество – потенциал мобилизации сотрудников. Это значит, что для достижения каких-то целей при определенных условиях сотрудники способны сосредоточиться и пойти навстречу – когда один человек с задачей не справляется, команда должна прийти на помощь. Руководитель проекта должен одним из критериев своей работы ставить понимание сотрудниками команды «общего камня», потому что команда начинается с «поднятия общего камня». Иногда команда может дать отбой и не согласиться работать больше, чем с 9 до 18 в будни – сказать, что по вечерам и в выходные мы работать не будем. Но когда вы всех членов команды вовлекаете в решение задачи последовательно или параллельно, они понимают, что если что-то происходит не так, то проекция переходит на них. В этом случае есть возможность попросить сотрудников с соответствующей компенсацией выйти на выходных или задержаться вечером, чтобы что-то доделать. Если понимание «общего камня» у команды отсутствует, то и потенциал мобилизации крайне низкий. В этом случае, конечно, можно столкнуться с ситуацией, когда на вашу разумную просьбу, которая нацелена на общее благо, сотрудники отреагируют отказом.

Звезды и пехота, культура команд

Мы дошли до момента – почему города берет пехота?

Я подготовил в виде таблицы зарисовки анализа, как работает «звезда» на проекте и как работает «пехота».

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

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

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

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

Но характеристики «звезды» менее управляемы, чем характеристики тех людей, которых мы условно называем «пехотой».

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

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

Что это означает для нас, как для руководителей проекта?

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

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

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

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

Куда можно приглашать «звезд»? Звезд можно приглашать именно на роль функционального архитектора или на роль системного архитектора. С одной стороны, это курирующие роли, с другой стороны, они имеют валидирующий характер.

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

Инструменты руководителя

Хочу подвести итог и порекомендовать вам несколько инструментов.

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

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

• Вы должны четко проработать регламенты на проекте и потребовать их жесткого исполнения.

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

• Обязательно – с привлечением «звезд» построить такой момент, как вовлечение, обучение на примере.

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

Единственное, чего хочу вам пожелать, - чтобы вы избегали подхода «одноразового стаканчика». Нельзя человека «выжать» и заменить. Так делать не рекомендую. Люди этот прием быстро раскусывают, и в этом случае «одноразовым стаканчиком» рискуете стать именно вы.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Оценка компетенций специалистов".