Agile-менеджмент. Лидерство и управление командами

Я уверен, что для лучшей приспособляемости компании не надо ограничивать зону ответственности названием должности. Название должности должно подразумевать достаточно широкий круг обязанностей. Меняются они нечасто (иногда раз в несколько лет), поэтому связь между названием позиции и кругом повседневных обязанностей не должна быть слишком жесткой. Так, название должности «разработчик ПО» оставляет вам больше свободы для перераспределения обязанностей, чем «аналитик». Даже если кто-то из сотрудников будет просить вас, чтобы его позиция называлась «аналитик», скажите ему, что в его контракте должность будет называться «разработчик программного обеспечения», а его роль будет состоять в том, чтобы быть аналитиком. На данный момент.

Расширенные названия должностей могут использоваться для обозначения нескольких ролей. Позиция «разработчик программного обеспечения» может включать широкий диапазон функций, начиная с дизайна, разработки и тестирования и заканчивая проектным менеджментом и техподдержкой [Abran 2004]. Поэтому «разработчик» в вашей организации может выполнять, например, роль программиста, тестировщика, специалиста по техподдержке и бизнес-аналитика. При этом сотрудникам, определение должностей которых далеко выходит за рамки позиции «разработчик» (например, менеджерам по работе с клиентами или системным администраторам), данные роли никогда поручаться не будут.

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

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

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

Уже многие годы моя должность называется CIO. Это прекрасное название, потому что эти буквы могут означать почти все что угодно. (Например, в зависимости от контекста буква I может обозначать такие слова, как «информация», «интерактивность», «инновация», «иллюстрация», «идеализация», «итерация», «ирригация», «интонация», «имитация» и так далее.) Очень часто моя текущая деятельность или проекты, которыми я в данный момент занимаюсь, не имеют никакого отношения к этому названию. Просто есть некий объем работы, который должен быть выполнен, вот и все.

Культивируйте неформальное лидерство

Лидеров, которые появляются внутри команд, иногда называют лидами или ведущими специалистами. Например, они могут называться техлидами, ведущими разработчиками, ведущими программистами и ведущими архитекторами. Общее у таких людей то, что они не будут линейными менеджерами своих коллег по команде. Неформальными лидерами становятся благодаря своим заслугам или принятым на себя обязательствам. Это предполагает ответственность, не имеющую ничего общего с ответственностью линейных менеджеров [Testa 2009: 53]. Когда подобные лидеры возникают сразу в нескольких местах, такое неформальное лидерство называется распределенным. Его возникновение логически связано с наличием в командах специалистов со склонностью к генерализации и расширенной трактовкой названий должностей.

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