Лучшие практики построения команды
Разработка ПО – это командная работа. Тем не менее вопросам формирования команды специализированная литература отдает гораздо меньше внимания, чем технологиям.
Проектным менеджерам известны методологии двух типов: по управлению знаниями и проектами. Методологий по управлению людьми еще не изобрели. Книги по менеджменту скорее учат тому, чего ни в коем случае нельзя допускать в управлении сотрудниками, чем тому, что предпринять, чтобы они стали одной командой. Ранее мой коллега писал статью на эту тему. Это, в свою очередь, вдохновило меня на описание своего видения данной проблемы.
За советом по образованию команды менеджеры проектов иногда обращаются к литературе по психологии. Но дело в том, что психологи пишут книги об общих проблемах межличностных отношений. Темы развития взаимопомощи и увеличения количества проявлений инициативы в них затрагиваются гораздо реже.
Возможно, за советом по командообразованию, есть смысл обратиться к другим, более изученным областям коллективной деятельности. Например, к театру.
Почему именно к нему? Как минимум в силу сходства. Театр тоже объединяет совсем разные сферы деятельности. Тем не менее на сцене все работает как единый организм. Вероятно, потому, что в театре существует ряд инструментов, которые позволяют самым разным людям работать на общий результат.
Рассмотрим некоторые из них:
- Застольный период;
- Сверхзадача;
- Амплуа актера;
- Роль «на сопротивление»;
- Рисунок роли;
- Построение мизансцены.
Застольный период
К сожалению, речь пойдет вовсе не о веселых застольях. Под застольным периодом принято понимать промежуток времени, когда проходит читка материала. До начала репетиций на сцене актеры проговаривают текст роли за столом. Без интонаций, ничего не играя. Это не заучивание текста и не знакомство с сюжетом. Актеры выявляют внутреннюю драматургию текста, делают пометки на полях сценария. На этом этапе определяются поворотные события пьесы.
Для менеджера поворотные события – это вехи проекта. Привлекайте разработчиков к планированию проекта. На первом этапе не обязательно определять все нюансы технологии, достаточно наметить направления и выявить потенциальные риски. Разработчики учатся думать и выражать экспертное мнение по поводу специфики проекта.
Сверхзадача
Сверхзадача – это индивидуальное толкование главной идеи произведения. Той цели, ради которой оно было написано. Режиссер диктует сверхзадачу актерам.
Какая сверхзадача у менеджера? Выполнить проект в срок? Нет, управлять ходом проекта – это работа менеджера. Цель всегда лежит за пределами работы. На этот вопрос лучше всех ответил Фредерик Брукс в своей книге «Мифический человеко-месяц»:
“Главная задача менеджера программного проекта – создать организационную структуру и рабочий процесс, способствующий творчеству и инициативе, а не подавляющие их.”
Какая сверхзадача у разработчика? Разработать функционал качественно и точно в срок? Нет, это его работа. К целям разработчика относятся:
- Освоение новой для него технологии;
- Желание стать архитектором проекта;
- Стремление обучить новичка и т.д.
Ситуация, когда у разработчика нет сверхзадачи, – провальная. Он приходит на работу только для того, чтобы отсидеть рабочее время.
Амплуа актера
Амплуа актера – это определенный род ролей, соответствующий внешним и внутренним данным актера. Говоря по-простому, есть актеры комики, есть актеры трагики.
Знание багажа каждого разработчика – это важная составляющая в процессе набора команды. Давайте людям проекты, отвечающие их внутреннему «я». Среди жалоб людей на условия работы встречается такая: «я выполнял кучу обязанностей, которые ко мне не относились». Это вопиющая вещь. Равносильная тому, что мастера спорта по плаванию заставят поднимать штангу.
Роль «на сопротивление»
Роль «на сопротивление» – это та роль, которая категорически не соответствует амплуа актера. Если справляется – значит, умеет выйти за рамки собственной «зоны комфорта». Если ломается, значит, режиссер неверно подобрал актера на роль, поставил ему не ту сверхзадачу.
Важность интереса разработчика к проекту, на котором он работает, трудно переоценить. Поэтому менеджер должен иногда давать разработчику проекты «на вырост». В этом смысле нужно уметь соотносить величие замысла и способности разработчика. Находить баланс между знаниями и потенциалом.
Рисунок роли
Рисунок роли – это диапазон, в котором действует актер, отступая от сверхзадачи или превосходя ее. В ходе репетиций режиссер четко фиксирует в какой ряд актер подает текст, в каком темпоритме работает, где просаживает или переигрывает.
Менеджер должен давать подчиненным право на ошибку, при этом признавая за ними способность превзойти ожидания. Создавайте в команде такие условия, при которых разработчик даже в своей худшей форме окажется не способным завалить проект. Для актера такие условия означают непереносимость фальши. Натренированный таким образом актер, безошибочно определяет переигрывание в фильмах и спектаклях, которые он смотрит. Вырабатывайте у разработчиков непереносимость плохого кода.
Построение мизансцены
Построение мизансцены – это условное разделение сцены и находящихся на ней актеров на первый, средний и дальний план. Мизансцены сиюминутны. Оттого, как они меняются, зависит то, насколько интересным получится смотреть спектакль.
Каждый менеджер хоть раз в жизни слышал от разработчика фразу: «я тянул проект на себе». Лидер не чувствовал поддержки других членов команды. Люди не работали сообща. Каждый варился в собственном соку. Система не приобрела новые черты. Менеджер должен: чувствовать, когда сотрудника стоит увести с передовой; понимать кто из участников команды подставит товарищу плечо. Даже опытный сотрудник не вытянет на себе проект в одиночку. Он надорвется.
it-команда
Убийцы команд
Проект – это своего рода спектакль. Некоторые постановки живут в сердцах зрителей годами. Иные проваливаются после нескольких показов. Вопреки всеобщему мнению, пьеса не главное. Главное то, как слаженно команда работает на результат.
Отсутствие в работе it-команды одного из перечисленных инструментов не критично. Отсутствие всех – гарантированно приведет проект к провалу. Прежде чем придумывать новые способы мотивации команды, посмотрите, используются ли в вашей команде эти приемы. Если не используются, это повод не просто задуматься, а забить тревогу.
Суммируем сказанное:
- Привлекайте разработчиков к планированию проекта;
- Четко ставьте цель;
- Изучайте сильные и слабые стороны участников команды, чтобы знать где их можно и нужно развивать;
- Объявите бойкот плохому коду;
- Не давайте лидеру шансов надорваться, а среднему специалисту предоставьте возможность проявить себя.
Конечно, в этой статье приведен далеко не полный перечень секретов театрального закулисья. Целью статьи было продемонстрировать, что учиться у представителей других отраслей можно и нужно. Изучение незнакомых областей, порой, позволяет сделать поразительные открытия.
В заключение добавлю: почаще ходите в театр. Там вы как минимум сможете отключить телефон и немного вздремнуть.
© Megamozg
