Идеальная команда проекта способна выполнить его полностью самостоятельно, вообще не прибегая к помощи ПМ (и такие команды существуют). Чтобы приблизить реальную команду к идеальной, ее необходимо «интегрировать» (сплотить), то есть развить неформальные связи, позволяющие быстро и с минимальными конфликтами менять структуру взаимодействия разработчиков под каждую новую задачу.
Неформальные связи потому и неформальные, что их нельзя установить приказом по проекту («Васе дружить с Петей, Коле игнорировать Машу»), – они формируются стихийно, исходя из личных особенностей каждого разработчика. Поэтому для правильной интеграции команды необходимо управлять процессом (опять процессом, а не результатом!) формирования таких связей.
1. «Варка супа». Как вообще возможно управлять формированием связей, если они определяются непредсказуемыми личными симпатиями? Если собрать пять – восемь человек в одну комнату и сразу начать работать, отношения в такой команде действительно сложатся стихийно (а следовательно, неуправляемо). Но если начать только с двух, причем отобранных таким образом, чтобы изначально «стыковаться» друг с другом по ценностям, совпадающим с ценностями самого ПМ (см. «Карточки аффилянтов»), – то в этом случае они наверняка сработаются и между собой, и с ПМ. Следующий разработчик будет выстраивать отношения уже не с людьми по отдельности, а с людьми, объединенными в команду, и подстраиваться придется ему, а не всем остальным.
ПМ на основе карточек аффилянтов определяет порядок формирования команды, начиная с наиболее подходящих (по ценностям) разработчиков и заканчивая самыми проблемными. Учитывается только комплементарность с проектом – например, ценности «хорошо заработать» или «сделать классный продукт». Квалификация на этом этапе в расчет не берется. Начальная команда формируется на основе стопроцентно лояльных и прогнозируемых кандидатов, остальные добавляются постепенно, по мере формирования и укрепления корпоративной культуры.
2. Быстрая притирка. Интеграция – развитие неформальных отношений, которое в условиях загруженности основной работой может идти слишком медленно. Чтобы ускорить интеграцию, команду проекта следует занять необременительной, но продолжительной деятельностью, оставляющей паузы на общение (заполнение анкет, собрание с длительными паузами между выступлениями докладчиков и даже какой-нибудь тренинг). В перерывах разработчики неизбежно перезнакомятся и гораздо быстрее сформируют устойчивую структуру контактов, чем в случае полной погруженности в основную работу. У интроверта в этих условиях будет больше шансов найти какого-то симпатизанта, через которого в дальнейшем получится поддерживать контакт со всей командой.
3. Формирование субкультуры. Групповая субкультура складывается из стереотипов, определяющих «своих – чужих», норм поведения в отношении «своих», ощущения «мы вместе». Конечно, существуют и другие компоненты, но для управления достаточно и первых трех.
ПМ обращает внимание на всякие мелочи, способные стать командной традицией (крылатые выражения, ритуальные действия, жесты и т. д.), и поддерживает те из них, которые создают позитивный настрой (то есть на работу, а не на прокрастинацию). Как только такие мелочи подхватят еще два человека, не реагировать на них станет неприлично; с этого момента «мелочи» станут частью командной субкультуры. Многие потенциальные конфликты могут быть пресечены в зародыше с помощью мемов («У тебя не будет багов, если ты не будешь кодить»).
Внутри команды ПМ способствует возникновению неформальных запретов типа «это нормально, но у нас не принято, потому что мы не такие, как все». Соблюдение таких запретов повышает самооценку (конечно, при условии, что членство в команде воспринимается позитивно, см. «Управление репутацией»).
ПМ поддерживает атмосферу «социализма-уравниловки». Любой сотрудник независимо от квалификации и реального вклада должен чувствовать себя важным и ценным; все формы поощрения по итогам работы распространяются на всю команду (потому что реально работали все, и даже если работал только один, то ему, по крайней мере, не мешали). Нормы общения со «своими» должны защищать разработчиков: например, попытки кого-то обидеть должны быть неприемлемыми или попросту неприличными. Субкультура должна подразумевать, что люди важны не только из-за квалификации, но и благодаря другим качествам, например важно создание эмоционального фона для команды в целом.
Как уже было сказано, если какой-то разработчик не вписывается в командную субкультуру и об этом сигнализирует больше одного человека, – он убирается из команды (см. «Увольнение»).
4. Поддержка неформальных контактов. Регулярные корпоративы и совместные пикники давно стали рутиной в любом бизнесе, однако их тоже нужно проводить правильно. Во-первых, неформальные мероприятия должны быть неформальными: общение в команде не должно быть самоцелью, оно должно возникать на фоне какого-то другого и при этом достаточно интересного занятия: не пьянка, а дегустация, не пикник, а прогулка по достопримечательностям, не корпоратив, а просмотр фильма с дискуссией. Во-вторых, неформальные мероприятия – место, где ПМ явно становится «таким же, как все» (это ведь уже не проект!) и имеет возможность показать, что он «свой» не за счет полномочий, а за счет приверженности субкультуре. Этой возможностью и надо пользоваться, не стоит пытаться командовать неформальным мероприятием.
Если часть команды работает на удаленке, ПМ должен обеспечить не только первичную притирку (пригласив удаленщиков на первое собрание команды), но и регулярные личные встречи всей команды в неформальной обстановке (разумеется, с обязательной «фоновой» деятельностью, чтобы не создавать атмосферу принудительного общения). Кроме того, полезно периодически переводить на удаленку и офисных сотрудников, чтобы они на себе почувствовали возникающие при этом проблемы и увидели возможности.
Результат. Команда с позитивной, настраивающей на работу субкультурой, лояльный ПМ, поскольку он лучший носитель этой субкультуры, а значит, «неформальный лидер».