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

Когда я работал директором по IT-технологиям, у меня бывали конфликты с HR-отделом по поводу хаоса, царящего в названиях должностей в некоторых подразделениях нашей компании. В командах, насчитывающих не более десяти человек, можно было обнаружить разработчиков контента, менеджеров контента, веб-редакторов, веб-дизайнеров, дизайнеров интерактивных интерфейсов, дизайнеров пользовательских интерфейсов, разработчиков пользовательских интерфейсов, веб-менеджеров и специалистов по пользовательским интерфейсам. В чем смысл всех этих названий? Не знаю. Так же как не знают и сами их носители. Я много раз всем говорил, что чем меньше названий должностей используется, тем лучше. И всех этих разработчиков и дизайнеров можно было бы назвать Восточные служащие, насколько я могу судить.

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

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

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

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

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