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

Специалист со склонностью к генерализации 1) имеет одну или две технические специализации… 2) обладает как минимум общими знаниями в области разработки ПО; 3) обладает как минимум общими знаниями индустрии, в которой данное ПО применяется; 4) стремится активно расширять свои знания как в области своей специализации, так и в других областях, включая технические и предметные [78].

Специалист со склонностью к генерализациивыполняет один вид работы очень хорошо и еще несколько с приемлемым качеством. Если у вас в команде есть такие люди, повышается ее эффективность и снижается риск возникновения узких мест. Специалистов со склонностью к генерализации иногда называют Т-специалистами. Их основная специализация выглядит как вертикальная палочка, но они также любознательны и готовы развиваться в других направлениях. Такие люди являются ценным приобретением, поскольку они видят проблему с нескольких точек зрения [Brown 2005].

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

Да, определенно существуют. Это люди, которые с приемлемым качеством решают многие задачи, но обычно у них лучше получается справляться с задачами одного или двух видов. Они похожи на специалистов со склонностью к генерализации, но все же они лишь во вторую очередь специалисты, а в целом остаются генералистами. Я их ценю почти столь же высоко, как специалистов со склонностью к генерализации.

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

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

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

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

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

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

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

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