Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 28)

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

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

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

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

3. Делиться ресурсом с командой. ПМ отслеживает ход выполнения заданий и приходит на помощь в критических ситуациях. Критическими являются ситуации, в которых разработчики «зависают», не понимая, куда двигаться дальше. С простыми заданиями, которые «делать проще, чем не делать», таких проблем не возникает. Более сложные нуждаются в декомпозиции до состояния «вот теперь можно и делать»; это сложно и требует затрат некой «психической энергии», которой у разработчиков не хватает. В такой ситуации ПМ делится своей энергией: заметив затык, подходит к разработчику и помогает ему наводящими вопросами, демонстрацией важности задания (раз уж сам ПМ им озаботился), готовностью сидеть рядом до решения проблемы и, самое главное, разделением ответственности. Если что-то пойдет не так – виноват будет лидер, поскольку решение принималось с его участием. Разделение ответственности снижает психологическую сложность задания и позволяет разработчику преодолеть затруднения.

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

3.3.2. Интеграция команды

Идеальная команда проекта способна выполнить его полностью самостоятельно, вообще не прибегая к помощи ПМ (и такие команды существуют). Чтобы приблизить реальную команду к идеальной, ее необходимо «интегрировать» (сплотить), то есть развить неформальные связи, позволяющие быстро и с минимальными конфликтами менять структуру взаимодействия разработчиков под каждую новую задачу.

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

1. «Варка супа». Как вообще возможно управлять формированием связей, если они определяются непредсказуемыми личными симпатиями? Если собрать пять – восемь человек в одну комнату и сразу начать работать, отношения в такой команде действительно сложатся стихийно (а следовательно, неуправляемо). Но если начать только с двух, причем отобранных таким образом, чтобы изначально «стыковаться» друг с другом по ценностям, совпадающим с ценностями самого ПМ (см. «Карточки аффилянтов»), – то в этом случае они наверняка сработаются и между собой, и с ПМ. Следующий разработчик будет выстраивать отношения уже не с людьми по отдельности, а с людьми, объединенными в команду, и подстраиваться придется ему, а не всем остальным.

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

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

3. Формирование субкультуры. Групповая субкультура складывается из стереотипов, определяющих «своих – чужих», норм поведения в отношении «своих», ощущения «мы вместе». Конечно, существуют и другие компоненты, но для управления достаточно и первых трех.

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

Внутри команды ПМ способствует возникновению неформальных запретов типа «это нормально, но у нас не принято, потому что мы не такие, как все». Соблюдение таких запретов повышает самооценку (конечно, при условии, что членство в команде воспринимается позитивно, см. «Управление репутацией»).

ПМ поддерживает атмосферу «социализма-уравниловки». Любой сотрудник независимо от квалификации и реального вклада должен чувствовать себя важным и ценным; все формы поощрения по итогам работы распространяются на всю команду (потому что реально работали все, и даже если работал только один, то ему, по крайней мере, не мешали). Нормы общения со «своими» должны защищать разработчиков: например, попытки кого-то обидеть должны быть неприемлемыми или попросту неприличными. Субкультура должна подразумевать, что люди важны не только из-за квалификации, но и благодаря другим качествам, например важно создание эмоционального фона для команды в целом.

Как уже было сказано, если какой-то разработчик не вписывается в командную субкультуру и об этом сигнализирует больше одного человека, – он убирается из команды (см. «Увольнение»).

4. Поддержка неформальных контактов. Регулярные корпоративы и совместные пикники давно стали рутиной в любом бизнесе, однако их тоже нужно проводить правильно. Во-первых, неформальные мероприятия должны быть неформальными: общение в команде не должно быть самоцелью, оно должно возникать на фоне какого-то другого и при этом достаточно интересного занятия: не пьянка, а дегустация, не пикник, а прогулка по достопримечательностям, не корпоратив, а просмотр фильма с дискуссией. Во-вторых, неформальные мероприятия – место, где ПМ явно становится «таким же, как все» (это ведь уже не проект!) и имеет возможность показать, что он «свой» не за счет полномочий, а за счет приверженности субкультуре. Этой возможностью и надо пользоваться, не стоит пытаться командовать неформальным мероприятием.