№ 7: Используйте команду по особенностям

       В группе по Visual C++ компании Microsoft, мы использовали команду по особенностям. Я настойчиво проявляю энтузиазм по отношению команд по особенностям. Они производили поразительный эффект на нашу группу. 
       Если спросить специалиста по контролю качества из команды по Visual C++: “В чем заключается твоя работа?” Он ответит: “Моя работа — выпустить продукт”. Не тестировать продукт — это недальновидный взгляд. Работа КК состоит в разработке продукта. КК должен проектировать продукт и знать потребителей. Фактически, он обязан быть в курсе всего, что происходит в нашем технологическом плане, нашем продукте, нашем рынке, нашей отрасли. 
       Мы обычным образом организуем команду разработчиков — КК, разработчики, технические писатели, руководители проекта и, если нужно, маркетологи. Но мы берем представителей из каждой группы и создаем из них команду по особенностям в матричной организации. И они сами уточняют свое назначение. Они определяют себе контрольные точки и формируют график Они даже определяют свой собственный командный процесс, хотя мы всегда рекомендуем использовать стандартный рабочий процесс. 
       Команда по особенностям имеет отношение к наделению полномочиями, ответственности, идентификации, достижению согласия. Такая команда — лучший из всех существующих механизмов для исправления некоторых организационных глупостей, которые описывались ранее. 
       Наделение полномочиями. Трудно представить, что одна функциональная группа (например, разработчики) может осуществлять абсолютный контроль над всей (многодисциплинарной) технологической областью. Поэтому имеет смысл поручить управление такой областью сбалансированной команде, состоящей из представителей всех причастных дисциплин. Ведущие эксперты из отдельных дисциплин знают все о своей области, и почему бы ни дать им возможность управлять ей. Известно много случаев, когда некоторые плохие (и хорошие тоже) решения, сделанные одними менеджерами, были отменены другими менеджерами. Но я не помню ни одного случая, когда были отменены решения, принятые командой по особенностям. Я даже не представляю, чтобы, на текущей стадии развития нашей группы, такое было возможно. Это говорит об истинной власти, которой обладает такая командами о качестве принимаемых ею решений. (Это также говорит многое о важности хорошей практики найма работников. Мы рассмотрим этот вопрос в приложении к Части I.) 
       Ответственность. Одной из самых интересных дискуссий, связанных с разработкой ПО, в которых я принимал участие, была дискуссия с лидерами команды по особенностям на тему ответственности. Мы обсуждали вопрос “За что вы несете ответственность?” Моя теория состоит в том, что большинство лучших идей, возникших в любом человеческом коллективе, тратятся впустую или теряются. Разбазаривание идей происходит потому, что люди, не чувствующие себя ответственными, могут нервно реагировать на новые идеи. Я говорил об этом в разделе, посвященном правилу №4: Не устанавливай бит ничтожества. 
       Во-первых. Источник — автор идеи (лицо или группа) — чувствует, что это не его зона ответственности, и поэтому редко формулирует идею конструктивно. Если все-таки “неозвученная идея” принимается, то это может привести к различного рода недоразумениям, неоптимальному поведению членов команды и дополнительным расходам. Команда будет голосовать ногами, если в ней не разговаривают языком. 
       Во-вторых, если источник высказывает идею (что весьма рискованно), то адресат — лицо или группа, которой направлена идея — может реагировать оборонительно, применяя весь арсенал защитных стилей и средств. 
       Иногда оборонительное поведение даже трудно распознать, особенно в группах, где оно не поощряется. По иронии, именно в развитых группах, осуждающих оборонительное поведение, часто развиваются детально разработанные и элегантные методы обороны. 
       В-третьих, агрессивность распространена так же, как и оборонительное поведение. Обычно начальные попытки пробудить интерес к идее, обернуты во встроенную агрессию, свойственную человеческому существу. Это дает начало оборонительной реакции адресата. Адресат четко распознает агрессию и, обороняясь от нее, не замечает “благородный” компонент сообщения. В этот момент источник уступает своему агрессивному началу и отвергает адресата, как недостойного для ведения последующих обсуждений — то есть, устанавливает на нем бит ничтожества: НИЧТОЖЕСТВО = TRUE. 
       Таким образом, теряется много хороших конструктивных идей. Единственное лекарство, которое я знаю против данного синдрома, — это цеховая атмосфера. В цеховом окружении люди делают шаг вперед и требуют критического отзыва от своих коллег. Простым жестом запроса обратной связи можно погасить агрессивность в источнике идеи. Такая восприимчивость проходит долгий путь, но к ней следует стремиться. В цеховом окружении каждый сотрудник является потенциальным адресатом для всех остальных, поэтому ритуальное разоружение вознаграждает всех. Удивительно, почему мы не используем цеховые методы более часто и широко. 
       Я успешно применял цеховую идею к реальным проблемам разработки ПО, пропагандируя понятие “разбор конкретного случая” (case study) в нескольких командах. Работает это следующим образом. Человек добровольно сообщает о случае. Случай — это текущая (или недавняя) профессиональная и обычно межличностная ситуация, в которую вовлечен человек. Например, “Я не могу найти адресата для этой идеи”, или “Никто не читает мои электронные послания”, или “Разработчик X не обращает внимания на план”. Человек несколько минут рассказывает о случае, иногда изменяя имена, иногда — нет. Остальные члены команды задают ему вопросы для получения дополнительной информации и уточнения — например, какие шаги были предприняты. Затем происходит подробное обсуждение ситуации. 
       Меня не перестают изумлять два момента в этом простом методе. Первое, обилие возникающих идей. Не перечесть случаев, когда доброволец говорит что-то типа “Хорошая идея!” и записывает что-то в своей записной книжке. Второе, случай почти всегда получает обобщение. Остальные участники говорят приблизительно следующее: “Это похоже на проблему X, которая случилась у меня в прошлом месяце”, или “Ваша проблема является частным случаем ситуации Y”. Они будут формулировать общие принципы или общую ситуацию. Затем все записывают ее в блокнотах. 
       Ответственность дает много преимуществ и накладывает очень мало ограничений. Если сбалансированная группа людей является совместно ответственной за все аспекты проектирования, разработки, отладки, контроля качества, выпуска и т.д., то они придумают способы обмениваться критическими наблюдениями друг с другом. Они все ответственны, и если они понимают что-либо, то они владеют этим. Они должны передавать свое понимание остальным членам команды. 
       Идентификация. Наделение полномочиями и отчетность неминуемо ведут к идентификации. Люди отождествляются с тем, что они контролируют и на что влияют. Чем выше уровень контроля, тем точнее идент-фикация. Хотя такая идентификации полезна и служит предпосылкой создания качественного ПО, она может привести к ситуациям, когда индивидуальные патологии проявляются в продукте. Например, склонность члена команды к саморазрушению может проявиться в способе реализации функций программы. 
       С командой по особенностям, личности постепенно начинают идентифицироваться с частью продукта, а не с узко специализированной ролью. Винить больше некого, и успех или провал каждого становится болезненно очевидным. Невозможно обвинять менеджмент разного калибра, когда каждая ваша встреча с менеджером заканчивается его вопросом: “Ну что тебе еще нужно, чтобы достичь наших целей?” Вы не можете винить представителей других дисциплин, потому что они вместе с вами взаимно ответственны за все аспекты вашей деятельности. Остается один вопрос: “Что вам мешает?” В наделенной полномочиями среде ответ неизбежно лежит где-то внутри. 
       Консенсус. Согласие царит в атмосфере команд по особенностям. Так как элементом идентификации является особенность, а не функция, и так как ответственность за особенность общая, то определенная степень открытости безопасна, и даже необходима. Мне приходилось наблюдать команды, реорганизующие себя, создающие видение, изменяющие расписания — и все это без сложных конфликтов. Конфликты, которые случались, обычно не имели личностного характера и в основном разрешались без обращения за помощью к руководству. 
       Соотношение сил. Соотношение сил в команде по особенностям имеет отношение к различным специальностям, различным заданиям и различным точкам зрения. Команда составлена из людей представляющих различные функциональные дисциплины, и с первого взгляда понятно, что каждый специалист будет продвигать свои взгляды. Обычно люди, специализирующиеся в какой-либо дисциплине, имеют точку зрения принятую в этой дисциплине. Мы можем понять разнообразие заданий в команде, глядя на различные точки зрения людей, назначенных на эти задания. Точка зрения, характеризуется вопросами, которые беспокоят ту или иную группу. Сейчас мы переходим к вопросам основных групп. 
       Руководство проектом. Каково состояние команды? Как продвигается проект? Эффективно ли наше лидерство? На каком цикле мы находимся? Есть претензии к плану? Не подводят ли субподрядчики? Ясны ли наши цели? В чем мы обманываем себя сегодня? Что мы должны завершить в ближайшее время? Какова тема собрания группы на этой неделе? 
       Контроль качества. Какова вероятность получения следующего поступления от разработчиков? Что делать с обнаруженными ошибками? Какие типы дефектов обнаружены? Какие функции еще не реализованы? Каковы эксплуатационные характеристики этого фрагмента кода? Должен ли я поднимать красный флаг на этой неделе? Знает ли руководство проекта, как устойчив (неустойчив) этот фрагмент кода? Есть ли проблемы с общением? Все ли разделяют общую точку зрения относительно нашего состояния? Разумны ли наши объявленные цели на эту неделю? 
       Разработка. Какова вероятность того, что я успею выдать свою недельную поставку контролерам качества и техническим писателям? Хорошо ли спроектирован этот фрагмент? Будет ли им доволен пользователь? Ясно ли как его использовать? Код достаточно быстрый и компактный? Я отладил этот фрагмент? Блокирую ли я чью-нибудь работу? Выполнимы ли в цели этой недели? Эта работа плановая или лишняя? Она есть в технологическом плане или это работа на корзину? 
       Руководство продуктом/Маркетинг. Что подумают клиенты об этой особенности? Как мне живо и образно представить эту особенность клиентам в сообщениях? Какие эмоциональные ассоциации возбудит эта особенность? Как мы могли бы усилить эти ассоциации, изменив продукт? Что будут думать клиенты, когда услышат от меня об этой особенности? Где они в первый раз используют ее? Как новая особенность в таком виде улучшит наши отношения с клиентами? Что из этой особенности сделает пресса? Какая история стоит за этой особенностью? Полностью ли я представляю себе эту особенность и ее важность? Какова вероятность успешно выполнить план? Стоит ли мне бить тревогу в организации? Или не стоит? Держим ли мы руку на пульсе событий? 
       Технические писатели/Обучение пользователей. Могут эти особенности работать более просто? Полностью ли понятно мое объяснение, как использовать эту особенность? Можно ли сделать так, чтобы объяснений не требовалось? Как максимально раскрыть эту особенность? Думают ли контролеры качества, что особенность полностью реализована? Что я думаю об этой особенности? Можно ли улучшить эту особенность? Могу ли я выразить себя более четко? Согласна ли остальная часть команды с моим описанием? 
       Хотя команда по особенностям — это очень ценный механизм, собрать ее вместе нелегко. Переход от традиционной иерархической организации к успешному применению команды по особенностям может быть очень трудным. Некоторые трудности возникают внутри и извне команды по особенностям. Внутри команды будет большая неопределенность. Члены команды по особенностям не знают степени своей независимости. Они будут чувствовать, что должны лучше работать вместе. Но не знают, каким образом. Люди будут стараться сохранить свои прежние роли. На первых порах, естественно, будут доминировать разработчики. Будет казаться, что каждый член команды должен выполнять свою прежнюю роль, только с минимально улучшенным командным общением. На деле, затраты на сбор команды, организацию нескольких первых собраний, определение ролей в команде, реорганизация команды и т.п. будут непропорционально превышать выгоды от немного улучшенного общения. 
       Люди вначале не принимают команду по особенностям. Только после того, как неизбежные неудачи начнут расти, возможности для объединения станут очевидными. Команда будет чувствовать себя расстроенной и покинутой. “Руководство” оставляет команду по особенностям в одиночестве решать свою судьбу. Независимость будет доставлять значительные неудобства, потому что люди не привыкли сами обеспечивать себя властью. 
       Будет также много конфликтных ситуаций и это длительная проблема, потому, что у большого количества людей существует поверхностное мнение о команде. Они считают, что команда — это притворный консенсус и фальшивые одобрительные возгласы. 
       Единственный консенсус, который стоит иметь, — это творческий консенсус, достигнутый в борьбе полностью занятых интеллектов. Такой консенсус рождается ценой бессонных ночей, страха быть отвергнутым, и испытаний личной храбрости. Конфликт, обычно предшествующий росту, является признаком начала движения к согласию.. 
       Но вначале команда по особенностям представляет собой жалкое зрелище. Вопрос о мужестве не возникает, потому что основная задача — пережить последние причуды руководства. 
       В конце концов, до некоторых членов команды начнет доходить, что у них есть власть. Их никто не сдерживает. Ресурсы в наличии. Творчество приветствуется. Руководство только поддерживает их цели. Они могут достичь цели, ради которой начали заниматься разработкой ПО. 
       В этот пронзительный и потрясающий момент, они понимают, что могут действовать свободно и несут ответственность за свои действия. 
       Конечно, это сразу создает другой набор проблем. Многие творческие и замечательные люди бессознательно утверждают, что что-то удерживает их, что какая-то отрицательная сила мешает проявиться их таланту. Они несут в себе “управленческую” функцию, которая препятствует освобождению в полной мере их созидательной энергии. Такой самозапрет восходит от родительского непринятия красоты ребенка, переданного от родителя ребенку. В ребенке возникает внутренний страх: если я раскрою свою уникальность, ощущает ребенок, ты (родитель) бросишь меня. Поскольку родители явно не требуют, чтобы ребенок перестал расти, мы все имеем исключительно тонкую чувствительность, которая позволяет нам уловить эти негативные родительские требования. Возможно, существует некоторый здоровый импульс на генном уровне, стоящий за позывом быть “нормальным”, быть таким как все, получить широкое признание в заурядном среднем обществе, соответствовать однородной системе ценностей. Но этот импульс является вредным для интеллектуального лидерства и для создания качественного ПО. 
       Наша излишняя чувствительность, поиск отрицания и самооправдания, — здоровый в патологической среде, становится патологическим в среде здоровой. Мы настроили себя при каждом повороте получать сигнал от своего “управляющего” и других властных фигур. Мы не можем полностью отдаться работе. Наш разум может отключить эти сигналы, но обычно этого не делает. 
       Когда члены команды начинают осознавать тот факт, что никто им не мешает и что они сами несут ответственность за свой успех, они неизменно передают это чувство освобождения и наделения полномочиями своим коллегам. Персональное чувство освобождения будет пониматься в разной степени и проявляться разными способами, в зависимости от индивидуума. Это любопытно наблюдать. Каждого человека надо вдохновлять и подпитывать. От каждого требуется гибкость и терпение в то время, когда человек привыкает к осознанию себя. Этот процесс роста является предпосылкой высокого качества любых интеллектуальных усилий команды. 
       Замечено, что степень, в которой люди из функциональных дисциплин (например, технические писатели) полностью принимают участие в команде по особенностям, обратно пропорциональна степени их успеха при старом (менее наделенном полномочиями) режиме работы. Если функциональная команда была изолирована в предыдущем режиме и если она в результате была успешной, то члены этой старой команды будут с трудом расставаться со своим изолированным положением, в то время как остальная часть организации становится здоровее и чувствует себя безопаснее при новом режиме. 
       Функциональные менеджеры (по разработке, по контролю качества и т.д.) будут непосредственно вовлечены в их тайную борьбу. Несмотря на отсутствие творческой и интеллектуальной работы в целой команде, они достигли успеха как индивидуальные менеджеры до “этой идеи фикс с командой по особенностям”. Они будут обязательно препятствовать — по крайней мере, до некоторой степени — становлению команды. Ведь они достигли ответственной и властной позиции в нездоровом окружении. Они были выбраны из общего фонда имеющихся талантов, потому что смогли достичь хороших результатов, несмотря на препятствия, существующие в общей неразберихе. Сейчас они столкнулись с ненужностью их основной квалификации. Их способность добиться для себя полномочий в сумбурной бесправной обстановке больше не нужна в среде, где узаконено широкое делегирование полномочий. То, что раньше принесло им успех, сейчас считается плохой адаптацией. То, за что раньше награждали, становится тем, за что наказывают. 
       Эти менеджеры знают, как достичь успеха во враждебном мире, как делать дела в интеллектуальном и творческом гетто. Они наблюдают за первыми пробными шагами команды по особенностям с озабоченностью и даже тревогой: “Но они все делают неправильно. Я должен делать это. Я должен сказать им, что надо делать”. Эти реакции исходят от искренней озабоченности. Попытка взять на себя ответственность почти непреодолима. Первое время старшие менеджеры будут бояться, что сама идея команды по особенностям — сумасшествие, что разрешение людям с меньшим опытом и мудростью решать судьбу технологии и бизнеса — это абсурд, что они делают ошибки, на которых уже сами обжигали пальцы. 
       Пока менеджеры учатся ходить по линии между подбадриванием и обучением на одной стороне и приказаниями и контролем на другой, будут происходить странные разговоры о том, кто должен будет принимать решения, и роли менеджера в управлении. 
       Я испытывал сомнения. Некоторые ключевые менеджеры удивлялись, что, черт возьми, мы делаем с очень хорошей командой. Я просыпался по ночам, размышляя, зачем мы организовали этот джихад по вовлечению в дело каждой головы. Менеджеры называли этот период временем “страшного ожидания команды по особенностям”. Постепенно мы начали понимать, что наша роль в этом процессе — учить, вдохновлять, подбадривать и направлять, по мере наших возможностей. Если наши идеи были лучшими, они должны были выжить. В то время как власть оставалась в основном у команды по особенностям, мы оспаривали их предположения, давали им возможность проверить их мотивы и поведение, помогали им достичь консенсуса и улаживали конфликты, сообщали им наши формулировки того, что мы считали их видением. Мы могли давать им советы по эффективности их работы. Это было существенным, потому что мы хотели ответственности от команды, которую мы наделили властью решать и поступать так, как она считала нужным. 
       Конечно, сам процесс был постепенным, и он продолжал развиваться. Было много случаев, когда команда по особенностям неоправданно требовала!, чтобы руководство принимало некие решения или устанавливало некие цели. Аналогично, были времена, когда руководство неуместно давало те или иные поручения команде. Эксперимент не был чистым. Во время происходивших изменений, я, время от времени, размышлял об организационной стратегии по созданию интеллектуальной собственности. 
       В идеальном проекте, обычно имеются Создатели и Кураторы. Создатели специализируются в Разработке, Контроле качества, Маркетинге, Документировании и некоторых других, имеющих прямое отношение к ПО, дисциплинах. Кураторы специализируются в понимании группы, создании обстановки, в которой комфортно заниматься творческой работой и в которой есть все необходимые ресурсы, для того чтобы эффективно реа-лизовывать общие идеи. Кураторы обеспечивают ситуацию, при которой как можно большее количество идей оказывалось бы в “коробке” с программным продуктом. Кураторы вышли из числа сегодняшних менеджеров и руководителей проекта — людей, чья квалификация “видна в коробке” косвенным образом. 
       Кураторы, так же как и Создатели, несут ответственность за качество программного продукта. А Создатели, так же как и Кураторы, ответственны за состояние группы. Идея общей ответственности этих двух специализаций хороша тем, что каждая из них, в некотором роде, “присматривает” за другой. Важность старой иерархии исчезает. Единственная власть идет от знания и понимания, а не от занимаемой позиции. Это очень многообещающее видение.