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

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

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

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

А генералисты со склонностью к специализации? Они вообще существуют?

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

Расширьте названия должностей

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

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

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