Сквозь измерения
Внешние стратегии команд - это сложная тема. Лидер команды или менеджер проекта может играть ключевую роль в урегулировании внешних отношений, однако эта тема сводится не только к тому, как ваш начальник ладит с ее начальником. Команды должны взаимодействовать и сотрудничать со множеством других подразделений организации. Эти взаимодействия происходят в нескольких измерениях: во властной структуре, в структуре задач и в информационной структуре.
Представим "властное" измерение как вертикаль. Важные внешние связи в этом измерении направлены вверх. Немногие команды могут достичь действительно высокой производительности, если они не умеют "ладить с руководством". Командам нужны "послы", политики, которые знают, как играть в политические игры в организации и как работать со властной структурой, чтобы команда и проект оказались в выгодном положении. Они способствуют хорошей репутации группы, представляя саму группу и ее преимущества. Связи с общественностью имеют большое значение для успеха команды, поскольку репутация команды может стать самоисполняющимся пророчеством. "Хорошие" команды получают самые лучшие проекты и первоочередной доступ к новому программному обеспечению и оборудованию. Часть успеха может быть связана с тем, что команда берется только за те задачи, которые ей по силам, а скучные или невыполнимые оставляет в стороне.
Вероятно, самой важной политической проблемой для команд является необходимость обрести и сохранить эффективную поддержку со стороны высшего руководства. Высокопоставленный руководитель или покровитель может сделать для команды больше, чем все CASE-инструменты и рабочие станции в Силиконовой долине. Энергичные политики с хорошими связями могут также служить буфером, ограждая команду от переменных ветров влияния и интересов, когда какие-то части компании продаются или поглощаются или когда руководители средней руки идут на повышение, или непрерывно меняются начальники отдела информатизации.
В основном координация задач проходит в горизонтальной плоскости с учетом боковых соединений, которые определяют взаимосвязи данной команды с другими организационными единицами. Хорошие координаторы договариваются с другими группами, выторговывая услуги или важные ресурсы. Они получают информацию о прогрессе других участников проекта, чьи продукты будут применяться совместно с продуктом, разрабатываемым командой. Они обеспечивают поступление работы и ее сдачу, отвечают за наличие соответствующих библиотек компонентов, направляют спецификации людям, разрабатывающим тестовые комплекты, или исправляют графические интерфейсы совместно с группой изучения человеческого фактора.
Информационное измерение тоже, главным образом, горизонтальное. Взаимодействие здесь подразумевает исследования, сбор информации, необходимой для успеха проекта, а также обмен данными между отделами. Командные исследователи могут эффективно служить в качестве информационных привратников, отбирая информацию таким образом, чтобы другим разработчикам не приходилось перекапывать горы документации, и отыскивая недостающие и необходимые данные.
В таких командах развиваются свои стили внутренней работы и специализация в разных областях. И точно так же в них разрабатываются характерные методы управления собственными границами и взаимодействия с остальной частью организации. Среди команд, исследованных Анконой, выделялось четыре варианта, которые мы назовем "политиками", "исследователями", "изоляционистами" и "универсалами".
"Политики" специализировались на "работе по вертикали", сосредотачивая свои усилия на создании хороших отношений с вышестоящим начальством. "Исследователи" занимались поиском и сбором информации. "Изоляционисты", в свою очередь, старались не выходить за свои плотно закрытые границы, защищая и охраняя их. Они не имели хороших связей с начальством, не полностью представляли задачи или владели не всей информацией.
"Универсалы" специализировались на всем. Они проявляли себя как команды, хорошо интегрированные в свою организацию благодаря эффективной управленческой деятельности. Они подключались к информационной структуре в ходе "исследовательской" и "поисковой" деятельности. Они сотрудничали с другими командами и ответственными лицами через инфраструктуру. У них были политические связи и защита со стороны властной структуры.
Как эти команды разных типов преуспевали на практике? Эффективность команд можно рассматривать как изнутри, так и снаружи, как с точки зрения членов команды, так и с точки зрения всей организации.
Члены "политических" и "изоляционистских" команд считали, что они самые лучшие, хотя для высшего руководства картина выглядела несколько иначе - при первоначальных оценках оно было склонно считать, что "политики" и "универсалы" эффективны больше всех, так как лучше других связаны с властной структурой.
Окончательный счет
Спустя время проявилось следующее. Согласно проведенному через полтора года исследованию, "политики" растеряли свое преимущество, получив самые низкие оценки производительности. Как оказалось, эти команды говорили разумно, но не достигали результата (что, впрочем, похоже на политиков вообще, не правда ли?).
Команды "исследователей", которые порой не занимались ничем, кроме сбора информации, зачастую оказывались расформированными по решению руководства. Команды "изоляционистов" проявляли себя неодинаково. Большинство из этих замкнутых групп приходили к полному провалу, однако некоторые из них достигали ощутимого успеха. Изоляция вашей команды первоклассных кракеров от остальной части компании может оказаться неплохим способом концентрации усилий на конечном продукте. Это один из тех шагов, которые связаны с высоким риском, но могут принести большую пользу.
Команды "универсалов", использующие гармоничные и разнообразные внешние стратегии, оказались корпоративными победителями. Такие команды способны уравновешивать внутреннюю производительность и внешние требования. Они получают нужную им информацию, но не застревают в бесконечных исследованиях. Для достижения своих целей они работают с системой через структуру власти и инфраструктуру. Другими словами, высокопроизводительная командная работа - это больше, чем умение хорошо работать вместе. Это также умение хорошо работать с другими.
Поэтому спрашивайте не о том, по ком звучит гонг. Если вам приходится спрашивать, ваша команда имеет неэффективную внешнюю стратегию. Значит, гонг звучит по вам.
Из журнала Software Development, том 1, № 8, август 1993 г.
16
Все сразу
Ни одна команда не может подходить для всех проектов. Одни группы больше подходят для рутинных разработок, другие превосходно разрабатывают самые сложные приложения, а третьи лучше всего осваивают новые области. Отчасти это зависит от того, как команда организована и скоординирована. Закрепите за членами команды постоянные обязанности и начните руководить "сверху вниз", применяя методы жесткого контроля и постоянного надзора, и, скорее всего, вы вряд ли получите какие-нибудь новые идеи. Свободно действующие команды, в которых поощряется индивидуальная инициатива, в большей степени способны нанести на карту новые территории. Традиционные команды с закрепленными ролями больше подходят для разработки обычных приложений. Команды, которые применяют открытое обсуждение и приходят к консенсусу, лучше справляются с решением сложных задач. В зависимости от сути задачи, с которой вы столкнулись, и технических целей проекта, тот или иной вид организации командной работы повышает шансы на достижение успеха.
Но все это вы и так знали. К сожалению, работа, которой вы занимаетесь, не очень хорошо вписывается в эти стандартные варианты. Ваши программные проекты не являются беспрецедентными, но, в то же время, и не совсем обычны. Задачи, которыми вы занимаетесь, - сложные и многоплановые, однако для того, чтобы решить их вовремя и в соответствии с поставленными условиями, высокий уровень производительности и надежности должен сочетаться с некоторой долей новаторства. Возможно, вы даже задумываетесь о применении элементов творческого сотрудничества, но начальник не понимает этих чувствительных и легкоранимых работников и поэтому собирается назначить ответственным вас и только вас.
Так обычно и происходит в мире, по крайней мере, в мире разработки программного обеспечения. Ни одна из моделей командной работы, представленных в главах 11–14, не отвечает всем требованиям типичных проектов. Необходима та или иная комбинация этих моделей, подходящая под непростые требования реальности.
Модели управления
В действительности реальные группы программистов прибегают к огромному множеству смешанных моделей. Однако, хотя некоторые из них могут быть более удачными, чем другие, большинство из них либо является мешаниной, собранной по методу проб и ошибок, либо основано на моделях управления, заимствованных из других отраслей. Мы хотим, чтобы модель командной работы над проектом подходила для разработки программного обеспечения. В такой модели предсказуемость принятой методологии и простота отчетности, достигаемые при назначении ответственным одного лица, должны сочетаться с высоким уровнем взаимопонимания между членами команды и возможностью достижения творческого консенсуса в процессе свободного сотрудничества.
Применяя разные подходы и работая независимо друг от друга на разных континентах, австралийский консультант Роб Томсет (Rob Thomsett) и я занимались этой проблемой и нашли одинаковые решения (Thomsett, 1990 [62]; Constantine, 1989 [11], 1991 [13]). Команды, разрабатывающие программное обеспечение, могут достичь наибольшей эффективности, если они хорошо структурированы. Тогда открытое сотрудничество будет более результативным, а достижением консенсуса будет легче управлять. Такой "структурно-открытый" подход сочетает в себе элементы традиционной "закрытой" модели командной работы и "открытой" модели коллективного принятия решений. Со стороны такая команда выглядит как традиционная иерархия (за проект отвечает руководитель), но внутри она функционирует как группа равноправных коллег, сотрудничающих друг с другом. Внутри команды существуют четкие роли, однако члены команды играют их поочередно. Существуют правила и формальные процедуры, однако они предназначены для того, чтобы способствовать свободным исследованиям и достижению консенсуса. Каждый аспект этого подхода продуман так, чтобы компенсировать недостатки одной модели с помощью элементов, взятых из другой. В модели Константина-Томсета нет ничего принципиально нового, но сама по себе такая комбинация является довольно интересной.
Например, в рамках этой модели руководитель проекта, который в конечном итоге несет ответственность за полученный результат, является равноправным активным участником обсуждений и работы, происходя-щей в команде. В частности, руководитель проекта никогда не ведет рабочие собрания - вместо него это делает нейтральный помощник. Открытый процесс достижения консенсуса может быть значительно эффективнее, если обсуждения будут проводиться не руководителем проекта, а с помощью нейтрального ведущего (см. главы 1–3). С другой стороны, процесс совместного принятия решений может легко застрять на второстепенных вопросах или в бесплодных спорах. В таких случаях в действие может вступить ответственный лидер проекта, который может отложить обсуждение данной темы или, в редких случаях, сыграть роль третейского судьи, если группа зашла в тупик.
Постоянное ведение записей о всех изгибах и поворотах в групповой разработке также позволяет сделать работу более надежной и управляемой. В структурированной "групповой памяти" могут фиксироваться решения, аргументы, рабочие продукты, отложенные решения, списки того, что нужно сделать или найти, и даже те подходы, которые были отклонены. Групповая память расширяет возможности контроля над рабочим процессом и делает обсуждения более эффективными. Ключевая информация и выводы находятся под рукой, а аргументы будут не так часто забываться и повторяться. Кроме того, групповая память может упростить или ускорить обсуждения, так как служит удобным местом для сохранения того, что сейчас отвлекает или не может быть решено сразу.
Как ведущие, так и секретари должны держаться в стороне от технических обсуждений для того, чтобы группа могла достичь наилучшего результата. Поскольку типичные группы разработки не могут приглашать специально подготовленных ведущих или секретарей, эти обязанности могут передаваться друг другу, а не входить в должностные инструкции. Человек, ведущий обсуждение, может сменяться при переходе к другой теме, а пополнение структурированной групповой памяти возлагается на всю команду, когда роль "информационного менеджера" (того самого "скромного и высокопоставленного писаря", упомянутого в главе 4) поочередно играют все сотрудники.
Управление обсуждениями
Команды с открытой структурой большую часть своей работы выполняют "лицом к лицу". Это не значит, что они тратят время на всякие встречи. Это означает участие в рабочих обсуждениях, совместное распределение функций и определение требований, анализ задач, планирование системной архитектуры, пересмотр дизайна и даже кодирование критических участков. Суть состоит в том, чтобы за счет открытости работы (см. главу 26) и применения разнообразных навыков и идей, привносимых членами команды, добиться сокращения ошибок и повышения качества работы.
Члены команды могут поочередно исполнять и другие функциональные роли. Это может быть обеспечение доступа к специальным знаниям по разработке приложений (что особенно важно в объектно-ориентированных методах разработки и для проектирования пользовательских интерфейсов), а также обеспечение связи с остальной частью организации (см. предыдущую главу о "командной политике"). Поскольку критические отзывы имеют важное значение для улучшения качества программ, роль "резидентного критика" формально считается неотъемлемой частью командной работы. "Резидентный критик" должен указывать на проблемы и предлагать альтернативные варианты, а также удерживать группу от соблазна остановиться на скороспелом, но неудовлетворительном решении. Однако ни один член команды не должен быть постоянным придирой; это временная роль, которая должна исполняться по очереди. На некоторое время вы становитесь скептически настроенным критиком, а потом моя очередь.
Основные особенности "структурно-открытой" модели - ведение рабочих обсуждений с помощью помощников, структурированная групповая память, поочередно исполняемые роли - оптимальны для разработки программного обеспечения и приложений. Поддерживая творческое равновесие между структурой и гибкостью, эта модель делает технический консенсус более эффективным, а техническую производительность более гибкой.
Разумеется, читатели, которые помнят классический роман Роберта Э. Хайнлайна "Луна - суровая хозяйка" (The Moon is a Harsh Mistress), могут подумать: "Tanstaafl". Да, в этой модели тоже есть недостатки. Для ее применения необходимо дополнительное обучение и приемлемые темпы работы. Кроме того, не все руководители с удовольствием расстаются с частью своей власти, чтобы работать наравне со всей командой. Формальное назначение ролей и строгая поочередность их исполнения может быть неудобной для небольших команд. Глупо, если один человек проводит обсуждение, другой ведет записи, а третий (и последний) программист произносит живой монолог по поводу дизайна иконок. Маленьким командам придется идти на слишком большие компромиссы или выбирать другую модель.
В любом случае, согласно духу этой модели, я открыт для всех идей, относящихся к улучшению структуры.
Из журнала Software Development, том 1, № 9, сентябрь 1993 г.
17
Заговор упрямцев
Новая Англия известна своими зимами и дорогами. В каждом регионе есть свои традиции разметки улиц и дорог. Например, дорожные знаки в Новой Англии обычно устанавливаются только на перекрестках, а не на главных улицах. По мнению самих янки, каждый должен и так знать, где находится Мэйн-стрит или Массачусетс-авеню. Какой смысл их обозначать? Знак на дороге, связывающей два штата, может предупреждать вас о том, что через одну милю будет поворот на Мидлборо, но на самом повороте будет знак с надписью: "Выезд на Шервуд и Бинвайл". Далее внизу, на выезде с магистрали, вам будет предложен выбор: либо повернуть налево в Мертон, либо направо в Честер! Пожалуй, если вы не знаете, куда поворачивать, вам и не нужно туда ехать. Уверен, что такой логике следуют и некоторые разработчики программного обеспечения. Они используют один термин в документации, другой в онлайновой помощи и непонятную иконку на панели. Ориентироваться в сделанных ими меню или диалоговых окнах - это все равно что ехать из Вест Роксбери в Фри-порт через Провиденс. Как говорят в штате Мэн: "Попасть отсюда туда вы не можете".
Некоторые из наших автомагистральных развязок - просто произведения искусства. Интенсивность движения на дорогах не такая, как, например, в Лос-Анджелесе, но это компенсируется самыми запутанными авторазвязками в мире. Эти асфальтовые крендельки способны привести к "пробкам" даже при движении небольшого количества транспорта. Стоит только появиться нескольким машинам с номерами других штатов или застрять какому-нибудь грузовику в будний день где-то после трех, как весь город превращается в сплошную автостоянку.