У специализации свои проблемы. Порой она приводит к возникновению узких мест, если специалисты не справляются со свалившимся на них объемом работы, а заменить их некем. Однажды мне пришлось самому заниматься дизайном корпоративного сайта, включая интерактивный и графический дизайн, поскольку наши обычные дизайнеры были расписаны на недели вперед. Специализация также может приводить к застою, если специалисты не могут (или не хотят) браться за работу, с которой незнакомы. Например, однажды я был вынужден просить разработчика ПО помочь мне решить несколько маркетинговых задач. Просто повезло, что он охотно согласился, иначе бы проект застопорился.
Я не люблю, когда люди говорят мне, что они обладают «широким набором умений», имея в виду, что они никогда не специализировались в конкретной области. Я совершенно определенно предпочитаю специалистов генералистам. Но еще больше мне нравится, когда у специалиста есть еще парочка областей, в которых ему удалось набраться кое-какого опыта. К счастью, я не одинок в этом мнении.
Специалист со склонностью к генерализации 1) имеет одну или две технические специализации… 2) обладает как минимум общими знаниями в области разработки ПО; 3) обладает как минимум общими знаниями индустрии, в которой данное ПО применяется; 4) стремится активно расширять свои знания как в области своей специализации, так и в других областях, включая технические и предметные
[78].
Специалист со склонностью к генерализации выполняет один вид работы очень хорошо и еще несколько с приемлемым качеством. Если у вас в команде есть такие люди, повышается ее эффективность и снижается риск возникновения узких мест. Специалистов со склонностью к генерализации иногда называют Т-специалистами. Их основная специализация выглядит как вертикальная палочка, но они также любознательны и готовы развиваться в других направлениях. Такие люди являются ценным приобретением, поскольку они видят проблему с нескольких точек зрения [Brown 2005].
Нанимая людей и комплектуя команды, ищите Т-специалистов. Сначала всегда проверяйте, действительно ли они серьезные профессионалы в одной из нужных вам областей, а затем убедитесь, что они готовы брать на себя и другие виды работ. Если вам нужен разработчик ПО, удостоверьтесь, что он хороший специалист. Но также не забудьте задать ему несколько вопросов по компьютерной графике, дизайну, а может быть, даже и из области маркетинга.
А генералисты со склонностью к специализации? Они вообще существуют?
Да, определенно существуют. Это люди, которые с приемлемым качеством решают многие задачи, но обычно у них лучше получается справляться с задачами одного или двух видов. Они похожи на специалистов со склонностью к генерализации, но все же они лишь во вторую очередь специалисты, а в целом остаются генералистами. Я их ценю почти столь же высоко, как специалистов со склонностью к генерализации.
Расширьте названия должностей
Когда я работал директором по IT-технологиям, у меня бывали конфликты с HR-отделом по поводу хаоса, царящего в названиях должностей в некоторых подразделениях нашей компании. В командах, насчитывающих не более десяти человек, можно было обнаружить разработчиков контента, менеджеров контента, веб-редакторов, веб-дизайнеров, дизайнеров интерактивных интерфейсов, дизайнеров пользовательских интерфейсов, разработчиков пользовательских интерфейсов, веб-менеджеров и специалистов по пользовательским интерфейсам. В чем смысл всех этих названий? Не знаю. Так же как не знают и сами их носители. Я много раз всем говорил, что чем меньше названий должностей используется, тем лучше. И всех этих разработчиков и дизайнеров можно было бы назвать Восточные служащие, насколько я могу судить.
Команда, в которой я работал, когда писал эту главу, состояла из четырех отличных человек. Один из нас знал все об API, разработкой которого мы занимались. Он решал, как должен выглядеть этот интерфейс, как его деплоить и сохранять преемственность между разными релизами. Он был нашим лидером во всем, что касалось этой темы. Второй член команды был самым молодым. Но у него были явные способности в области системной архитектуры. Наш третий коллега знал все о социальных медиа и электронной коммерции. Он был нашим лидером, когда речь шла об онлайн-маркетинге и коммуникативных стратегиях. И наконец, я выполнял функции Владельца проекта и принимал решения, касающиеся функциональности, приоритетов и загрузки остальных работой, чтобы они не скучали и не начинали усложнять то, что в этом не нуждается.
Каждый из членов команды был лидером. Мы выполняли роли, соответствующие нашей специализации, но отнюдь не названиям наших должностей. У нас не было программиста интерфейсов, системного архитектора, консультанта по маркетингу или владельца продукта. При необходимости нам приходилось выполнять обязанности друг друга. (А такая необходимость возникала часто, поскольку я довольно много выступаю на конференциях по всему миру.)
Я уверен, что для лучшей приспособляемости компании не надо ограничивать зону ответственности названием должности. Название должности должно подразумевать достаточно широкий круг обязанностей. Меняются они нечасто (иногда раз в несколько лет), поэтому связь между названием позиции и кругом повседневных обязанностей не должна быть слишком жесткой. Так, название должности «разработчик ПО» оставляет вам больше свободы для перераспределения обязанностей, чем «аналитик». Даже если кто-то из сотрудников будет просить вас, чтобы его позиция называлась «аналитик», скажите ему, что в его контракте должность будет называться «разработчик программного обеспечения», а его роль будет состоять в том, чтобы быть аналитиком. На данный момент.
Расширенные названия должностей могут использоваться для обозначения нескольких ролей. Позиция «разработчик программного обеспечения» может включать широкий диапазон функций, начиная с дизайна, разработки и тестирования и заканчивая проектным менеджментом и техподдержкой [Abran 2004]. Поэтому «разработчик» в вашей организации может выполнять, например, роль программиста, тестировщика, специалиста по техподдержке и бизнес-аналитика. При этом сотрудникам, определение должностей которых далеко выходит за рамки позиции «разработчик» (например, менеджерам по работе с клиентами или системным администраторам), данные роли никогда поручаться не будут.
Гибкость людей – причина, почему в Scrum все сотрудники именуются просто «членами команды». Этим подчеркивается ответственность каждого человека за своевременное завершение проекта независимо от официального названия должности. Никто не может заявить: «Не буду это делать. Это не моя работа». Если для того, чтобы программный продукт вышел в срок, понадобится почистить клавиатуру, на которой работает клиент, значит, ваша работа в данный момент в этом и состоит. Некоторые организации заходят настолько далеко, что в них все позиции называются «партнеры». Это прививает привычку к гибкости и стремление работать на результат.
