III. Организация работы
Введение
Хотя я приступил к работе в компьютерной отрасли, получив степень по менеджменту в Массачусетском технологическом институте, сначала мне была более интересна техническая сторона программирования. Впервые организацией командной работы и вопросами организационного развития я серьезно занялся во время моей работы с семейными системами. Несмотря на то что моя деятельность в области вычислительной техники и программного обеспечения продолжается уже более тридцати лет, случилось так, что в середине карьеры я отклонился от нее лет на двенадцать. В те годы мне посчастливилось быть теоретиком в области прикладных систем. Мой переход к деятельности, связанной с семьей, произошел в то время, когда семейная социология и семейная терапия двигались по направлению к теории систем (Whitchurch и Constantine, 1992 [67]). В исследованиях супружества и семьи, в социологии и социальной психологии появилось понимание того, что группы людей функционируют как системы. В результате к человеческим системам стали применяться общая теория систем и системный подход.
Мне посчастливилось учиться и работать под руководством психолога Дэвида Кантора (David Kantor), одного из самых талантливых исследователей и самых творческих мыслителей в данной области. Кантор изучал семьи с помощью непосредственного наблюдения и документирования, описывая непростой танец повседневной жизни, в котором семьи согласовывают и поддерживают свою деятельность и внутренние отношения. Его необычайно богатые наблюдения привели к пониманию того, что даже беспроблемные семьи не похожи друг на друга. Кантор разработал схему, позволяющую понять разнообразные и отличные друг от друга модели функционирования семьи. Его книга «Inside the Family» (Семья изнутри) (Kantor и Lehr, 1975 [45]) является одной из самых примечательных работ в области современных социологических исследований и считается классическим трудом.
Дэвид - хороший исследователь, однако я, как мне кажется, хороший теоретик, и поэтому я задался целью выяснить и восполнить некоторые пробелы в его теоретическом подходе. Результатом этого стало расширение упомянутой структуры с целью охватить все множество человеческих систем - от семей до неформальных групп, от проектных команд до международных организаций. В конце концов, я написал свою собственную книгу о «семейных парадигмах» (Constantine, 1986 [10]), и, к моему удивлению и удовольствию, ее стали использовать в учебных курсах по менеджменту и организационному развитию. В итоге возникло свободное международное сообщество, в котором объединились консультанты по вопросам управления, интересующиеся применением работы Дэвида и моих идей на практике. Некоторые из этих людей помогли мне понять, что в компьютерной области происходят удивительные вещи, и поэтому я должен туда вернуться, захватив с собой багаж знаний, накопленный при изучении семей и работе с ними.
11. Традиционная тактика
Ок, ребята, теперь давайте организовываться! Вопрос только - как? Работая самостоятельно, вы можете работать как угодно. Вам не нужно координировать свою работу с тем, что делают другие, и вам не придется подлаживаться к кому-либо. Вы можете в навязчиво-маниакальной манере аккуратно класть все вещи на свои места и в точности выполнять инструкции в соответствии с моделью жизненного цикла, принятой в разработке стандартного программного обеспечения. Или вы можете оставить все разбросанным по всему офису в полном беспорядке и кодировать по вдохновению или просто когда вздумается. Однако если вместе работают два человека или более, то ключевым словом здесь является слово «вместе». Работа, которую они выполняют, и способ ее выполнения требуют координации.
В этой главе начинается исследование вопросов организации и управления работой людей: как работа организована и как люди, работающие вместе, координируют свои действия (Constantine, 1990 [12], 1991 [15], 1993 [21]). Рассмотрим организацию как человеческий эквивалент архитектуры программного обеспечения, соотнося руководство с динамическим управлением программными компонентами. И снова мы придем к знакомым понятиям структуры и динамики систем управления. Когда вы хотите организовать новую компанию по разработке программного обеспечения или очередной программный проект, возникают все те же вопросы и проблемы.
Каким же образом их решать? Как можно наладить совместную работу группы людей - будь это проектная команда или целая корпорация? Как организовать группу, структурировать работу и управлять процессом? Какой способ является правильным? Самое время вспомнить один из стандартных «ответов консультантов»: «Это как посмотреть!» Поиск правильного способа организации проекта похож на поиск правильного способа кодирования подпрограммы. Нужно исходить из того, что вы собираетесь получить в результате (Constantine, 1993 [21]).
Обычная работа по созданию еще одного набора драйверов для принтера или еще одного варианта традиционного генератора растровой развертки может потребовать совсем иной модели организации и руководства, чем работа над новейшим CASE-инструментом, поддерживающим процесс параллельного проектирования программного обеспечения и проектирование объектно-ориентированного ПО на основе консенсуса. В своей небольшой, но превосходной книге, посвященной командной работе, Ларсон и ЛаФасто (Larson и LaFasto, 1989 [47]) определили несколько основных вариантов такой работы, каждый из которых имеет свои преимущества. Здесь мы рассмотрим четыре отдельных и очень различных модели организации командной работы, их преимущества и недостатки.
Создание организации
Итак, давайте организовываться! Самый простой и надежный вариант основан на проверенной временем стандартной процедуре. Координирование работы более чем одного человека заключается в наделении кого-либо полномочиями руководителя. Функция руководителя состоит в том, чтобы управлять и следить за работой других. Эта структура может быть расширена с помощью рекурсии. В результате появится иерархия руководителей, где высшие чины руководят низшими. Это простая, устойчивая и знакомая всем форма организации: традиционная пирамида, основанная на иерархии власти. В проектах по разработке программного обеспечения, ведущихся согласно этой модели, в иерархии может не быть много уровней, но это все равно иерархия. В принципе, такая структура может быть очень эффективной, однако на практике она может разрастись до огромной бюрократической машины, не способной ни к чему, кроме сохранения собственной бюрократической неэффективности.
Такая модель является не просто способом работы. Она может быть образом жизни. Недавно я занимался реорганизацией своей коллекции записей, чтобы освободить место для новых компакт-дисков, и обнаружил настоящее сокровище - старинную запись «Paean» из корпоративного альбома компании IBM1. Слушая, как Ассоциация британских секретарей в Америке (на самом деле!) энергично исполняет «Песню деревенского клуба IBM», я стал думать о корпоративной культуре и о том, как способ нашей работы определяет наше видение мира, и наоборот.
Традиционный взгляд с вершины пирамиды рассматривает организацию как основу устойчивого функционирования, а контроль - как ключ к поддержанию целостности. Лидерство опирается на власть. Руководители принимают решения, а подчиненные должны выполнять их, демонстрировать лояльность и следовать инструкциям начальства. Предсказуемое и надежное исполнение достигается за счет стандартов, процедур и правил работы. У каждого есть своя работа, своя роль, свои обязанности и свое место в иерархии. Корпоративные интересы, или интересы отдела, или интересы проекта стоят превыше всего, а работники получают вознаграждение за добросовестное исполнение своей части в большой работе.
В общем виде эта модель довольно проста. Ответственность возлагается на кого-либо, кто может принимать решения и отдавать приказы (желательно, чтобы этот человек разбирался в деталях и тонкостях дела). В традиционных иерархиях подразумевается, что решения принимаются строго сверху вниз. На то, чтобы необходимые данные поступили к ответственному лицу, может потребоваться время, но как только это произошло, процесс принятия решения может быть довольно эффективным. Решение принимается, когда руководитель готов его принять. Не требуется никаких консультаций. Не нужны ни обсуждения, ни дискуссии, ни исследования. Очевидно, что это может быть как силой, так и слабостью, поскольку многое начинает зависеть от того, кто находится на вершине пирамиды. Правильные решения могут приниматься так же быстро, как и неправильные, а если руководитель обдумывает решение слишком медленно или с ним трудно выйти на связь, то это может привести к краху всей пирамиды.
Властная пирамида
Когда речь идет о проектах по разработке программного обеспечения и командной работе, традиционная модель лучше всего подходит для того, что называется тактической работой. В тактических проектах территория знакома, а параметры известны. Самое главное - это выполнить работу. Я заточил свои «программистские зубы» на тактических проектах, в которых разрабатывались стандартные бизнес-приложения, например платежные ведомости, исчисление себестоимости и кадровые архивы. После того как вы сделаете пару систем ведения платежных ведомостей, они все начинают казаться одинаковыми. Даже если это не так, такой взгляд позволяет упростить работу и дает возможность применять стандартные подходы. В итоге вы знаете каждый свой шаг и сможете сделать их даже во сне.
Ясность имеет решающее значение для тактической командной работы - ясность требований, ясность инструкций, ясность ролей. В этом мире методы разработки становятся более эффективными, если они хорошо определены и опираются на ясные стандарты и нормативы. При разработке программного обеспечения необходимо тщательно продумать жизненный цикл проекта и последовательность его этапов. Работа должна быть выполнена аккуратно и эффективно. В такой команде внимание группы акцентировано на текущей задаче. Точка. Члены команды больше всего нуждаются в ясных инструкциях от лидеров проекта и руководства. Каждому члену команды назначается конкретная часть хорошо понимаемой работы, и все выполняют то, что должны делать.
Традиционная иерархия работает. Многие компании в нашей отрасли и бесчисленные проекты по разработке программ организованы по этому принципу, в том числе и некоторые из наиболее успешных. Корпоративные песенники, восхваляющие бесстрашных лидеров компаний и их верных последователей, - лучшие тому свидетельства.
Такая ясно определенная и предсказуемая среда может быть комфортной, однако не каждый может чувствовать себя уютно в таком мире. Те, кому это удается, чаще всего лояльны, преданны и исполнительны. Они придают большее значение работе, чем самим себе, и всегда готовы к выполнению указаний лидеров. Такие люди предпочитают обращать большее внимание на программы, чем на людей. Тактические команды - это рай для конформистов и одержимых, для тех программистов, которые занимаются базовым программированием и о которых можно сказать, что они «соль земли». Тактическая командная работа подходит для тех, кто хочет знать, что делать, и делает это.
Обратной стороной медали является то, что любая группа, организованная по принципу традиционной иерархии, может очень легко застрять на месте. Сопротивляясь полезным инновациям в интересах устойчивости власти, такая группа тратит силы на строгое следование стандартам и процедурам, а не на решение задач и производство продукта. В лучшем случае такие группы эффективны и продуктивны, однако они не проявляют должной творческой активности. Их новаторство может выражаться не более чем в частичных улучшениях уже существующих технологий, то есть в эволюционных изменениях, а не в революционных. Если посмотреть на лидеров отрасли, полагающихся на традиционную иерархию, то зачастую можно увидеть, что их главные новшества были либо заимствованы извне, либо приобретены через внутренний обмен опытом. Компании или группы разработчиков, организованные по этому принципу, вероятнее всего будут иметь особые трудности с кодирующими ковбоями (см. главы 7, 8 и 10). Независимые индивидуалисты и традиционная иерархия - это несовместимые понятия. Разработчики, которые сопротивляются власти или подвергают ее сомнению, а также стремятся идти своей дорогой или предпочитают отходить от стандартов, могут остаться без надбавки к зарплате или обнаружить себя в списке сокращения расходов.
С вершины пирамиды или изнутри может показаться, что другого способа организации и управления не существует. В конце концов, кто-то ведь должен быть ответственным, правильно? Либо вы руководите, либо выполняете указания, либо уходите с дороги. Некоторые люди до сих пор не видят никакой альтернативы иерархии. Но мы также когда-то думали, что вложенные подпрограммы, вызываемые из управляющей программы, - это единственный способ компоновки программ. Теперь мы используем множества связанных объектов и одноранговые сети с распределенными базами данных.
Что касается людей, то они всегда намного более гибки, чем программы. По крайней мере, некоторые люди.
Из журнала Software Development, том 1, № 3, март 1993 г.
12. Методы хаоса
Для всех кодирующих ковбоев у меня есть хорошие новости. Существует такой тип организации, который не только выносит настоящих индивидуалистов, но и опирается на их таланты.
Возможно, некоторые из программистов старой школы и бескомпромиссная молодежь будут шокированы, если узнают, что ни иерархия, ни власть не являются необходимыми для эффективного сотрудничества людей, работающих в одной группе. Действительно, сейчас в области управления происходит мировая революция. Все больше и больше компаний во многих отраслях открывают для себя преимущества самостоятельных команд, автономных рабочих групп и «управления без управляющих». Одна из главных проблем традиционной пирамиды управления заключается в том, что она очень плотна в середине (во многих смыслах этого выражения). Управление среднего уровня привносит дополнительные издержки - не только в денежном смысле, но и с точки зрения оперативности. Чем больше вы стремитесь быть на переднем крае в любой технологии, тем более неповоротливой становится «властная пирамида». Истинно новаторский подход требует такой стремительности, которая недостижима с помощью традиционной тактики вертикального управления.
Прорывы
Проектные команды скорее добьются настоящего успеха в развитии технологий, если обратятся к гибкости, которую дает независимость. Необходимо использовать всю силу самостоятельного творчества, не стесненного инструкциями и контролем. Суть состоит в том, чтобы извлечь все лучшее из изобретательской энергии вольнодумцев, поощряя дух свободных исследований и личной инициативы. Нужно поддерживать некоторый творческий беспорядок, граничащий с хаосом, - своего рода контролируемое безумие, которое позволяет отойти от шаблонов, ограничений и расширить представления о собственных возможностях. Все это противоречит закрытым шаблонам корпоративных пирамид, поскольку подрывает основы власти и выбрасывает традиционный подход на ветер. Это серьезно угрожает традиционным методам управления, однако это как раз то, что нужно для освоения новых земель.
По существу, ключевые ингредиенты для инициативы прорыва несовместимы с традиционной иерархической моделью. Вместо стабильности, превалирующей над изменениями, поощряется нестабильность как движущая сила для преодоления слепо принимаемых правил и не подвергаемых сомнению понятий. Вместо корпоративных и коллективных интересов, главенствующих над индивидуальными, на первое место ставится индивидуальная свобода самовыражения и действия. Если традиционная пирамида старается приструнить строптивых кодирующих ковбоев, то «команды прорыва» охотно их принимают и дают им возможность скакать свободно. Такая атмосфера общей свободы стимулирует творчество и способствует «наивысшей личной» производительности, приводящей к крупным достижениям.
Деятельность «команд прорыва» зависит от индивидуальной инициативы. Решения принимаются не централизованно, а самостоятельно, на рабочем месте - теми, кто обнаружил проблему и знает, как ее решить. Держать курс такой группе помогает своего рода дружеская соревновательность. Именно общий интерес и любовь к игре, а также взаимное уважение игроков друг к другу удерживает их от того, чтобы разбежаться в разные стороны.
Чаще всего эту модель можно обнаружить в небольших высокотехнологичных компаниях, недавно возникших предприятиях и в проектно-исследовательских отделах больших организаций. Все они могут быть довольно успешными. Действительно, многие мускулистые корпоративные бегемоты полагаются на «отделы скунсов»2. Именно оттуда исходят новые идеи и продукты, позволяющие сохранять мотор коллектива в работоспособном состоянии.
Работа и игра
Представьте такую сцену, действительно имевшую место в одной из крупных компаний западного побережья. Вы входите в вестибюль и видите, как бородатый человек средних лет, который потом оказывается вице-президентом научно-исследовательского отдела, отвечает на телефонные звонки. Вы говорите ему, что вы консультант по графическим пользовательским интерфейсам, и в ответ он машет вам рукой - «по коридору налево...». Едва уклонившись от «летающей тарелки», пронесшейся на околозвуковой скорости, вы отправляетесь на поиски какого-нибудь начальника. Безуспешно. Увидев мерцающий экран монитора в одной из комнат, вы подходите к сотруднику, занятому просматриванием библиотеки классов. Этот человек оказывается офис-менеджером. Но разговор с ним становится все более трудным, так как игра в «летающую тарелку», происходящая в коридоре, набирает обороты. Два программиста, занятые отладкой кода с целью устранения ошибки в операционной системе, орут, чтобы было потише, но, в конце концов, сами втягиваются в состязание. Через некоторое время весь отдел переходит на соседнюю парковку и устраивает там целый турнир, в котором участвуют пять «летающих тарелок».
Для случайного наблюдателя все это может показаться бедламом или детским садом, однако игра «в тарелку», в которой множество «летающих тарелок» не сталкивались друг с другом, натолкнула пару программистов на неожиданные идеи. Они придумали новое решение одной сложной проблемы в многопользовательском программном продукте, разработкой которого сейчас занимается их отдел. Была ли это простая случайность? Было ли это простым валянием дурака на работе? Трудно сказать. Работа - это игра, а игра - это работа. Был ли встреченный офис-менеджер инженером по разработке программного обеспечения? Вы никогда не догадаетесь.
А как насчет вице-президента научно-исследовательского отдела? Он что, входит в состав службы поддержки? Наверное, это так, раз он с этим так хорошо справляется. Руководители, которые эффективно управляют таким творческим хаосом, знают, что их задача заключается в том, чтобы обеспечивать ресурсы и поддержку, ограждать группу от внешних помех, а самим оставаться в стороне. Самые лучшие из таких менеджеров чаще всего сами являются технарями и пользуются особым уважением за свою удаль в программировании или другие технические таланты.
Конечно, такая модель не всегда работает, и даже когда она работает, оригинальность может иметь и обратную сторону. Чрезвычайно трудно вести собрание по планированию или разбор кода, если сотрудники постоянно заходят и выходят, а те, кто сидят в комнате, заняты написанием писем на лэптопе или играют в шахматы на карманной доске. В лучшем случае коммуникации внутри «команды прорыва» могут быть случайными, далее если все находятся в одной комнате. Дело не в том, что эти творческие индивидуалисты необщительны - просто в таком хаосе информация очень легко пропадает. («Да-да, этот клиент на прошлой неделе писал нам об изменении в интерфейсном протоколе. Это письмо где-то сохранили. Наверное.»)
Блестящий и совершенно беспристрастный психолог Дэвид Кантор (David Kantor) одним из первых заметил, что в человеческих группах под внешней случайностью скрывается лежащая в ее основе сложно организованная логика (Kantor и Lehr, 1975 [45]). В этом отношении его работы предвосхитили последние исследования по применению теории хаоса в группах. Кантор выделил два варианта кажущейся случайности: одну он назвал творческой, а другую - хаотичной (в старом и более традиционном понимании слова «хаос»). Разница между «случайным творческим» и «случайным хаотичным» имеет решающее значение - это разница между успехом и провалом в достижении прорыва при разработке программного обеспечения.
В крайних случаях «команда прорыва» может стать «командой провала». Без наличия правильных ингредиентов дружеская соревновательность может стать недружеской, непродуктивной или даже бесперспективной. Специалисты, которые должны были сотрудничать, стремятся к противоположным целям и борются за ресурсы. В конце концов, люди могут полностью выйти из-под контроля, оставив организацию и проект в полной неразберихе.
Первый необходимый элемент, позволяющий избежать хаотического провала, - это хорошие люди с хорошей подготовкой, владеющие хорошими приемами. Члены команды должны обладать способностями и навыками, которые отвечают уровню сложности проекта и признаются другими членами команды. Взаимное уважение к уровню технической компетентности и полная вера в способность других членов команды внести свой вклад в общее дело являются важнейшими связующими звеньями, которые сохраняют единство «команды прорыва».
Вторым необходимым элементом, ведущим к успеху, являются достаточные и даже избыточные ресурсы. «Броуновское движение» в команде новаторов может способствовать появлению блестящих решений. Однако такие решения не всегда являются самыми эффективными. Новые алгоритмы следует испытывать, нестандартные структуры данных нужно применять, а оригинальные варианты разбивки экрана должны быть макетированы. Процесс свободного создания и проверки новых идей имеет важнейшее значение. Даже тупиковые идеи, от которых следует отказаться, часто являются важной частью процесса группового обучения. Творчество имеет свою цену и требует определенного риска.
Против управления
Как можно управлять кучей индивидуалистов-изобретателей? Не нужно заниматься руководством. Управление «командой прорыва» - это особая роль, которая принципиально отличается от руководства традиционной тактической командой. Самые эффективные лидеры команд и проектов считаются равными среди равных и пользуются большим уважением как программисты и специалисты. Они является харизматическими лидерами, на которых равняются остальные. Чаще всего такие лидеры руководят своим личным примером, а не приказом, которому почти всегда будут сопротивляться. Они способны создать атмосферу глубокого взаимного уважения членов команды друг к другу. Они знают, как обеспечить команду необходимыми ресурсами - рабочими станциями, программным обеспечением, учебными курсами, временем. Они поддерживают заряженность команды и предотвращают неконструктивную конкуренцию за ограниченные ресурсы.
Для достижения успеха такие команды также нуждаются в автономности. Должна быть обеспечена свобода от вмешательства извне, свобода исследовать неожиданные повороты и подходы. Хорошие лидеры таких команд говорят: «Итак, игра начинается!», а затем отходят в сторонку. А самые лучшие лидеры еще и следят, чтобы никто другой не смог этой игре помешать.
Проектная команда, организованная и направляемая на достижение прорыва, может стать веселой и интересной компанией для работы, однако не каждый сможет хорошо работать в таких условиях. Люди, которые нуждаются в ясных указаниях, четко поставленных целях, а также в ясном понимании того, что от них ожидают, скорее всего, будут лучше себя чувствовать в традиционной иерархии. Разработчики, которые продуктивнее всего работают в «командах прорыва», могут быть артистичны либо быть интеллектуалами, но прежде всего они проявляют себя как свободомыслящие люди. Они активны, они не ожидают инструкций. Более того, самые производительные из них могут быть не в меру упрямы. Хорошими членами тактических команд часто становятся люди, которые особенно чутко реагируют на указания лидеров, но хорошие новаторы в большей степени являются индивидуалистами или даже могут сопротивляться власти и инструкциям.
Вряд ли есть смысл спускать с цепи целую команду творчески мыслящих ковбоев для работы над обычной базой данных, необходимой для бухгалтерского отдела. Полученный продукт может привести к бегству бедных бухгалтеров. С другой стороны, масштабные проекты со множеством компонентов и сложными взаимосвязями - например, программное обеспечение для научно-исследовательской космической станции - также не подходят для «команд прорыва», даже когда ясно, что новые подходы необходимы. По очевидным причинам команды, состоящие из творческих индивидуалистов, больше подходят для менее масштабных и сложных проектов, которые не требуют согласованности множества частей, в сильной степени зависящих друг от друга.
Во многих сложных современных проектах по разработке программного обеспечения следует применять другие подходы, которые будут рассмотрены далее. Что касается компаний типа Nanomush Corporation и International Behemoth Management, Inc., то им придется плутать со своими хаотичными ковбоями среди мегапирамид.
Из журнала Software Development, том 1, № 5, май 1993 г.
13. Открытая архитектура
Многие думают, что есть только два типа людей: мы, знающие все лучше других, и остальные, отличные от нас. То же самое можно сказать о работе в организациях. Некоторые люди думают, что есть только два выбора: приказная власть или необузданная анархия. Другими словами, свобода или подавление - и все! Остальные понимают, что не все так просто. Что бы ни предпринимали менеджеры и консультанты по управлению, реальные люди в реальных организациях не поддаются ограничениям примитивной дихотомии и выпрыгивают из одномерных концептуальных коробок, в которые мы стараемся их втиснуть.
С одной стороны, есть иерархическая модель организации работы, обсужденная в главе 11, а с другой стороны - ее полная противоположность, творческая анархия, рассмотренная в главе 12. Между этими двумя крайностями в виде упорядоченного традиционализма и свободного новаторства размещается столько вариантов, сколько существует проектов и людей, в них участвующих.
Впрочем, не всякой рабочей группе найдется место в данном ряду. Некоторые группы, находящиеся далеко в левой части диапазона, не рассматривают основные вопросы организации работы как компромиссы. Это те люди, которые мыслят в терминах «и то, и это», а не в терминах «или-или». Они говорят: «Мы можем это». Как в традиционном, так и в «свободном» подходе есть тенденция обязательно противопоставлять «я» и «мы». В традиционной иерархии интересы индивидуумов подчинены интересам команды, или группы, или организации. В новаторском индивидуализме верховодят индивидуумы, а коллективные интересы отодвинуты на задний план.
Однако другие исследователи считают, что между целым и его частями нет принципиального конфликта - так же как нет необходимости выбирать между изменением и стабильностью. Такой подход к совместной работе, так называемая «открытая парадигма», является гибкой моделью, основанной на равноправном сотрудничестве и взаимодействии. Для краткости мы можем назвать эту модель «адаптивным сотрудничеством», открытой архитектурой построения человеческих организаций.
Работаем спокойно, работаем вместе
Адаптивное сотрудничество идеально подходит для решения технических задач. В этом подходе сами по себе не ценятся ни традиция и стабильность, ни новаторство и изменение. При таком взгляде на проекты и прогресс важным становится адаптивное соответствие между тем, как команда работает, и тем, над чем она работает. Сегодня мы разрабатываем независимые друг от друга программы, поэтому мы работаем по отдельности. Завтра мы будем думать над общим протоколом обмена данными, поэтому мы соберемся все вместе. У каждого есть свои мысли об архитектуре базы данных, так давайте обсудим все эти идеи.
Целью в такой группе является спокойствие и обсуждение вопросов таким образом, чтобы конкурирующие идеи можно было объединить, а различные подходы синтезировать. В некотором смысле такие группы непрерывно перестраиваются, изменяя способы работы в соответствии с текущими потребностями и долгосрочными задачами. Кто становится «ответственным» и что это подразумевает, зависит от того, чем занята группа в данный момент.
Группы разработчиков, организованные в таком духе, напоминают скорее плоский круг, чем пирамиду. Члены команды работают как коллеги, меняясь ролями. В отличие от свободных радикалов в «командах прорыва», которые могут работать независимо и даже соревнуются между собой, члены такой команды тщательно согласовывают свои действия. Решения принимаются коллективно в процессе обсуждений, переговоров и построения консенсуса. Это не значит, что все во всем соглашаются, однако они приходят к техническому консенсусу. При техническом консенсусе все члены команды поддерживают действия и решения, выработанные группой по всем главным вопросам. Для этого требуется, чтобы каждый мог внести свой вклад в важные решения. Такой подход позволяет каждому сотруднику «вложиться» в совместное усилие и гордиться своим личным участием в коллективном продукте.
Обсуждая вопросы совместно, группы могут блестяще решать сложные задачи, особенно в тех случаях, когда нужно получить и проверить значительный объем информации (звучит так, как будто требуется большой объем разработок). На самом деле, чем больше в задаче факторов, граней и деталей, тем больше относительное преимущество открытых команд в сравнении с тактическими командами, где информация может контролироваться слишком жестко, или с «командами прорыва», в которых информация может быть потеряна в конкуренции и хаосе.
«Команды прорыва», отдающие предпочтение оригинальности свободного мышления, могут также приходить к блестящим решениям, которые, тем не менее, не вполне практичны. Невозмутимые представители тактических команд могут производить надежные рутинные программы, но с трудом находят творческие решения для структур данных, алгоритмов, или пользовательских интерфейсов. Команды, в которых предпочтение отдается совместному решению задач, лучше всех способны объединять разные идеи, предлагаемые всеми членами команды, и принимать такие решения, которые одновременно и практичны, и прогрессивны.
Для настоящего сотрудничества требуются правильные методы руководства, которые поощряли бы свободное обсуждение и помогали достигать технического консенсуса. Самые лучшие менеджеры в проектах открытого типа являются коллегами, компетентными профессионалами, которые играют активную техническую роль в процессе анализа, проектирования и разработки. Обычно они не ведут собрания или обсуждения технических вопросов, поскольку не хотят оказывать влияния на результат. Вместо этого они предлагают другим участвовать в обсуждении, чтобы получить от каждого члена команды наибольшую отдачу. Это требует определенной веры, убежденности в том, что группа как целое знает больше и может достичь лучшего решения, чем кто-либо в отдельности (в том числе и начальник!). Руководители, которые уверены в том, что они самые умные, самые способные и могут разметить программу лучше, чем кто-либо другой в проекте, скорее всего, не смогут достигать такого же успеха, как сотрудничающие друг с другом коллеги. Будет лучше, если они станут работать в одиночку или руководить традиционной тактической командой.
Естественно, упор на полное согласие при адаптивном сотрудничестве может быть и препятствием. Эти люди способны уговорить даже ураган. Если обсуждение, которое продлилось час, не помогло решить вопрос, они будут готовы потратить на это еще пару часов. Они пререкаются не только по поводу технических проблем, но и по поводу философии, которая за ними стоит; они подвергают сомнению не только методы разработки, но и те предположения, на которых они основаны. Может обсуждаться даже работа самой группы, когда она рассматривает свои методы и структуры и пытается адаптировать их к решению задачи. («Послушайте, может быть, сейчас нам нужно разбиться на небольшие группы и поработать так несколько дней, а потом вновь соединиться и попытаться собрать все это вместе?»)
Есть способы уменьшить пробуксовку в работе такого рода команд. Дискуссии могут быть ограничены по времени. Если технический консенсус не достигнут по истечении какого-то установленного времени, то вопрос может быть отложен или сведен к некоторому стандартному решению, или передан руководителю для арбитражного вердикта. Каждый из этих вариантов в некоторой степени нарушает правила совместного принятия решений. Однако если такие варианты являются нечастыми исключениями из правил, то эффективность может перекрыть некоторую потерю в виде чувства принадлежности к конечному результату.
Однако здесь не может быть простой формулы. Для того чтобы оставаться открытой, каждая группа должна искать свой собственный путь и договариваться о собственных процедурах и исключениях.
Оставляя дверь открытой
Одна из лучших команд, построенных на сотрудничестве, которые я когда-либо знал, была известна как Цех построения теорий (Theory Construction Workshop). Это независимая рабочая группа, слабо связанная с профессиональным сообществом. Ее члены общались друг с другом как коллеги, стараясь продвигать создание теорий в атмосфере свободного обсуждения и взаимопомощи. Эти собрания были открыты для всякого, кто разделял интерес к построению более правильной теории. Содержание и формат собраний обсуждался в соответствии с традицией тесного сотрудничества и взаимодействия. Почти на каждом ежегодном деловом собрании обязательно находился новичок, который в порыве радости от присутствия в такой замечательной и приятной компании предлагал ввести какой-нибудь формальный порядок в виде регистрации, членских билетов, устава, публикации протоколов и т. п. Каждый год мы исправно рассматривали и обсуждали эти предложения и каждый год их отклоняли, по общему согласию оставляя наше собрание открытым, неформальным и гибким.
Однажды на одном из ежегодных собраний я, не подумав, выдвинул радикальное предложение: «Отныне, для того чтобы избежать траты времени на обсуждение этих бесконечных предложений, давайте запретим все попытки установить жесткие и формальные правила или структуры». Еще не успев закончить своей фразы, я рассмеялся над своим внутренне противоречивым предложением. Наше искреннее и серьезное рассмотрение даже самых необдуманных предложений, вносимых рядовыми новичками, было именно тем, что заставляло групповой процесс работать. Все заулыбались, я сел, и мы вернулись к обсуждению очередного предложения по публикации протоколов наших собраний. Для того чтобы оставаться открытым, любой открытый процесс должен быть открыт для альтернативных вариантов.
Свою блестящую пьесу «Sunday in the Park with George» (В парке с Джорджем в воскресенье) Стивен Сондхейм (Steven Sondheim) заканчивает чудесными словами, приписываемыми Джорджу Сера (Georges Seurat): «Белая, чистая страница или холст - вот что он любит; в них есть так много возможностей».
Могу сказать то же самое.
Из журнала Software Development, том 1, № 6, июнь 1993 г.
14. Синхронное плавание
Хотите увидеть, как по-настоящему быстро разрабатывать приложение? Возьмите фильм Гаррисона Форда (Harrison Ford) «Свидетель» («Witness») и найдите в нем сцену, когда общество Амиш строит сарай за один день. Самое интересное в этой проектной команде - не ее поразительная эффективность, а отсутствие руководителя и даже необходимости в руководителях или руководстве. Они почти не разговаривают и им уж точно не приходится спорить по поводу конструкции сарая или договариваться о том, кто и что должен делать для того, чтобы его построить. Они просто взялись за работу и стали ее выполнять быстро и эффективно, почти в полной гармонии, пока не закончили.
Конечно, это мечта менеджера, своего рода управленческая утопия. Слово «утопия» буквально означает «место, которого нет», а сцена из фильма «Свидетель» исправно происходит в округе Ланкастер, штат Пенсильвания. Более подходящим, наверное, является слово «эутопия», означающее «хорошее место». Таким образом, эутопия - это то идеальное место, где вы хотите быть. Поэтому мы можем назвать такую модель организации эутопической командной работой.
Быть руководителем эутопической группы, разрабатывающей программное обеспечение, очень просто - настолько просто, что для осуществления руководства вам вряд ли придется что-либо делать. Люди вокруг вас делают все, что должно быть сделано. Не нужно стоять над душой у каждого или разъяснять что-либо на пальцах. Все идет гладко потому, что люди, которые работают для вас и вместе с вами, разделяют ваши представления о работе команды - о том, что нужно делать и каким образом. Это люди, которые вам подходят; они думают так же, как и вы, и во многом смотрят на мир вашими глазами. Едва вы успеваете сказать слово, как они уже принимаются разрабатывать следующий набор модулей или кодировать расширения для графического пользовательского интерфейса, или делать еще что-нибудь нужное. Все - люди, программное обеспечение, программирование - подходит друг другу так точно, как будто вы все придумали сами, не прилагая к этому никаких усилий. В команде не существует конфликтов и не нарушается дисциплина. Подобно команде по синхронному плаванию, это само воплощение идеального совершенства и гармонии.
Такая эутопическая фантазия является последней из наших четырех основных моделей организации проектов - синхронная парадигма, модель эутопической командной работы. Традиционные тактические команды координируются иерархической властью, «команды прорыва» - индивидуальной инициативой, а команды совместного решения задач - взаимодействием сотрудников. Эутопические команды зависят от выбора направления. Члены такой команды следуют направлению, заданному общим пониманием и общими ценностями. Поскольку все члены команды понимают друг друга и разделяют общее представление о том, куда движется команда и каким образом она будет достигать своих целей, они могут работать совместно без какой-либо заметной координации. Подобная направленность обычно не становится доминирующим объединяющим принципом для всей организации в течение длительного периода времени. Однако многие группы, большие и маленькие, зависят от некоторой степени направленности или функционируют синхронно в течение более коротких периодов.
Где находится место, которого нет
Случай, который произошел с моим коллегой несколько лет назад, поможет проиллюстрировать этот режим работы. Консультант по организационному развитию встречалась с клиентами в конференц-зале госпиталя. Во время этой встречи одна из ножек массивного дубового стола подломилась. Стол придавил ее ногу. Нога оказалась вывернута, а движения скованы. В то же мгновение все вскочили со своих мест, чтобы помочь. Двое стали приподнимать тяжелый стол с ее ноги, а третий взял за руку, чтобы успокоить. Кто-то побежал в рентгенологию. Еще один выскочил в холл, чтобы принести носилки. Между членами этой медицинской команды не проскочило ни единого слова. Они все точно знали, что нужно делать, и каждый просто стал выполнять какую-то часть. Никто не назначался руководителем, не требовались ни обсуждения, ни переговоры, и, тем не менее, все занимались одним делом, не противореча друг другу.
В подобном синхронном взаимодействии нет ничего магического. Если посмотреть на этих людей внимательно, то можно заметить, что взаимодействие между ними главным образом невербальное. В существенной степени оно основано на молчаливом согласии и предварительном знании. Так как каждый член команды видит, что делают другие, он может подстраивать свои действия под общее дело. Поэтому не все сразу бросаются к телефону, а носилки появляются в нужный момент.
При условии, что все члены эутопической команды хорошо понимают стоящую задачу, такая команда может достигать высокой эффективности в сложных или критических условиях (подобно ситуации в конференц-зале госпиталя) или при выполнении предсказуемых и ясных задач в течение более длительных периодов (как, например, построение сарая). Понимание задачи и наличие представления о том, как она может быть выполнена лучше всего, имеет важнейшее значение. Каждый работник в обществе Амиш видел, как строят сараи, и, вероятно, когда-нибудь участвовал в этом. Каждый, кто находился в конференц-зале госпиталя, имел более чем достаточный опыт в оказании медицинской помощи. Почти наверняка никому из них не приходилось иметь дело с падающими столами переговоров, но это не имело значения; их профессиональный медицинский опыт и знания позволили им быстро понять новую ситуацию и действовать как обычно.
Ключом к эффективности эутопических команд является полная приверженность всех членов команды довольно сложной, но четко определенной концепции того, что является задачей и методами группы. Если эта направленность является слабой или частичной или концепция является неадекватной, группа не сможет выполнять свою работу без консультаций или без конфликтов или же не сможет отвечать требованиям изменяющихся условий; в этом случае либо потребуется более жесткое управление, либо трудности команды станут возрастать.
Люди, изучающие менеджмент и организации, хорошо понимают первые три из наших основных моделей команд и лежащих в их основе механизмов. В то же время о проектных командах, основанных на направленности, известно меньше. Хотя полностью синхронные команды на практике встречаются нечасто, сочетание высокой синхронизации с традиционной иерархией является менее редким. Такое сочетание можно встретить в крепких компаниях, которые работают в давно существующих отраслях, имеющих давние традиции. Консультант Роб Томсет (Rob Thomsett) и я обнаружили ряд довольно синхронных групп по разработке программного обеспечения в австралийском банковском доме, функционирующем по британской модели. В Японии, где корпоративный мир свято чтит традиции преемственности и единообразия, даже высокотехнологичные фирмы могут широко применять синхронную направленность.
Тихие воды
Эутопическая командная работа является полной противоположностью модели, основанной на сотрудничестве. Вместо обсуждений и переговоров нормой здесь является их отсутствие. Зачем нужны переговоры, если люди думают настолько одинаково, что почти с самого начала согласны друг с другом? Обратной стороной такой эутопической гармонии является то, что в обычной, повседневной работе все это безоблачное и спокойное сотрудничество может стать несколько скучным. Поскольку члены такой команды привыкли работать без особых дискуссий или вообще без обсуждений, они могут не общаться даже тогда, когда это им нужно. Если условия на рынке или базовая технология неожиданно или радикально изменяются, команда может оказаться неспособной среагировать или адаптироваться к этому так же хорошо, как группы, построенные на индивидуальной инициативе или на совместном взаимодействии. В худшем случае члены команды могут продолжить действовать привычным способом и не обращать внимание на изменяющийся вокруг них мир. Если что-то не соответствует их общим представлениям, они могут посчитать это не заслуживающим внимания или ответа.
Согласно общепринятым представлениям, современные руководители должны учиться выживать в бурлящей воде, плавать в компании с акулами и при этом добиваться успеха. Выжить, плавая в окружении акул, конечно, возможно, но большинство пловцов, наверное, предпочтет теплые, тихие воды. Естественно, команде по синхронному плаванию лучше держаться в стороне от бурлящих вод и подальше от водоемов, населенных акулами. Точно так же и эутопические команды лучше приспособлены к стабильным, постоянным и невраждебным условиям.
Однако небольшая степень синхронности может быть полезной даже для команд, построенных на других базовых моделях. Более узкая направленность и более четкое взаимопонимание уменьшают потребность в жестком контроле и расширяют границы, в которых усилия одних членов команды могут подкрепить или поддержать усилия других, а не свести их на нет или помешать им.
Эффективные руководители эутопических команд являются харизматическими гуру, способными формировать и применять сложные концепции, а также вызывать к ним доверие других людей. Для длительных проектов особую важность имеет их способность изменять и расширять эти концепции для того, чтобы учесть новые требования и изменить направленность в соответствии с ними.
Естественно, вы понимаете, о чем идет речь. Мы хорошо понимаем друг друга, верно? Поэтому здесь нечего больше говорить (даже то, что эта эутопическая направленность просто отлична!).
Из журнала Software Development, том 1, № 17, июль 1993 г.
15. Командная политика
Этот проект по разработке программного обеспечения был чрезвычайно успешным. Команда разработчиков приобрела известность созданием потрясающей системы с усовершенствованными сервисами и отличным графическим интерфейсом. По каким-то причинам руководство отказалось от этого продукта.
Команда - не остров. Группы, которые хорошо работают вместе в комнате для обсуждений, могут не иметь успеха при выходе на уровень корпоративной политики. Неудача есть неудача. Знать интерфейс программирования приложений и библиотеку классов так же недостаточно, как недостаточно знать способы прихода к консенсусу или процессы параллельного проектирования. Если вы не знаете правила игры, вы проигрываете. Название этой игры - «внешняя среда».
Команды по разработке программного обеспечения должны сторожить свои границы, защищая свою территорию. Однако нужно и наводить мосты. Новый компилятор является частью набора инструментов. Система поддержки принятия решений должна согласовываться с системой бухгалтерского учета, но также она должна быть пригодной и полезной для руководителей. Репутация компании неуправляемых приверед может способствовать попаданию команды в список на сокращение. С другой стороны, репутация супергероев C++ может привести к необоснованным ожиданиям при создании очередной объектно-ориентированной чепухи, начатой зятем президента компании.
Мы рассматриваем командную деятельность по созданию программного обеспечения с точки зрения моделей, определяющих стиль внутренней работы. В свою очередь, Дебора Анкона (Deborah Ancona) из школы управления Sloan при Массачусетсом технологическом институте исследует функционирование команды в реальной корпоративной среде, а также то, как внешние стратегии и стили команд влияют на производительность (Ancona и Caldwell, 1992 [1]). Анкона изучала консалтинговые команды, команды разработки новых продуктов, а также команды по сбыту товаров и управленческие команды. Данные, полученные ею в течение многих лет, совпадают с моим опытом изучения команд по программированию.
Сквозь измерения
Внешние стратегии команд - это сложная тема. Лидер команды или менеджер проекта может играть ключевую роль в урегулировании внешних отношений, однако эта тема сводится не только к тому, как ваш начальник ладит с ее начальником. Команды должны взаимодействовать и coтрудничать со множеством других подразделений организации. Эти взаимодействия происходят в нескольких измерениях: во властной структуре, в структуре задач и в информационной структуре.
Представим «властное» измерение как вертикаль. Важные внешние связи в этом измерении направлены вверх. Немногие команды могут достичь действительно высокой производительности, если они не умеют «ладить с руководством». Командам нужны «послы», политики, которые знают, как играть в политические игры в организации и как работать со властной структурой, чтобы команда и проект оказались в выгодном положении. Они способствуют хорошей репутации группы, представляя саму группу и ее преимущества. Связи с общественностью имеют большое значение для успеха команды, поскольку репутация команды может стать самоисполняющимся пророчеством. «Хорошие» команды получают самые лучшие проекты и первоочередной доступ к новому программному обеспечению и оборудованию. Часть успеха может быть связана с тем, что команда берется только за те задачи, которые ей по силам, а скучные или невыполнимые оставляет в стороне.
Вероятно, самой важной политической проблемой для команд является необходимость обрести и сохранить эффективную поддержку со стороны высшего руководства. Высокопоставленный руководитель или покровитель может сделать для команды больше, чем все 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»3. Да, в этой модели тоже есть недостатки. Для ее применения необходимо дополнительное обучение и приемлемые темпы работы. Кроме того, не все руководители с удовольствием расстаются с частью своей власти, чтобы работать наравне со всей командой. Формальное назначение ролей и строгая поочередность их исполнения может быть неудобной для небольших команд. Глупо, если один человек проводит обсуждение, другой ведет записи, а третий (и последний) программист произносит живой монолог по поводу дизайна иконок. Маленьким командам придется идти на слишком большие компромиссы или выбирать другую модель.
В любом случае, согласно духу этой модели, я открыт для всех идей, относящихся к улучшению структуры.
Из журнала Software Development, том 1, № 9, сентябрь 1993 г.
17. Заговор упрямцев
Новая Англия известна своими зимами и дорогами. В каждом регионе есть свои традиции разметки улиц и дорог. Например, дорожные знаки в Новой Англии обычно устанавливаются только на перекрестках, а не на главных улицах. По мнению самих янки, каждый должен и так знать, где находится Мэйн-стрит или Массачусетс-авеню. Какой смысл их обозначать? Знак на дороге, связывающей два штата, может предупреждать вас о том, что через одну милю будет поворот на Мидлборо, но на самом повороте будет знак с надписью: «Выезд на Шервуд и Бинвайл». Далее внизу, на выезде с магистрали, вам будет предложен выбор: либо повернуть налево в Мертон, либо направо в Честер! Пожалуй, если вы не знаете, куда поворачивать, вам и не нужно туда ехать. Уверен, что такой логике следуют и некоторые разработчики программного обеспечения. Они используют один термин в документации, другой в онлайновой помощи и непонятную иконку на панели. Ориентироваться в сделанных ими меню или диалоговых окнах - это все равно что ехать из Вест Роксбери в Фрипорт через Провиденс. Как говорят в штате Мэн: «Попасть отсюда туда вы не можете».
Некоторые из наших автомагистральных развязок - просто произведения искусства. Интенсивность движения на дорогах не такая, как, например, в Лос-Анджелесе, но это компенсируется самыми запутанными авторазвязками в мире. Эти асфальтовые крендельки способны привести к «пробкам» даже при движении небольшого количества транспорта. Стоит только появиться нескольким машинам с номерами других штатов или застрять какому-нибудь грузовику в будний день где-то после трех, как весь город превращается в сплошную автостоянку.
Как я убедился, самые ошеломляющие из запутанных развязок в Большом Бостоне были спроектированы подрядчиками с узкой специализацией. Такие монументы творческой комплексификации требуют особого инженерного таланта и склонности к упрямству. Например, автомобилю, направляющемуся на запад и съезжающему с платной дороги, для выезда на северную дорогу нужно сделать поворот налево, проехать под эстакадой с движением на восток, затем выехать на кольцо, проехать три четверти круга, держась правой стороны, остановиться для оплаты, потом опять проехать под восточной и западной дорогами, потом над дорогой с уличным движением, потом выехать на северный подъем, переходящий в другой подъем на протяжении одной мили, и затем, наконец, слева влиться в общий поток. Понятно? Не напоминает ли вам это какую-нибудь любимую программу для Windows?
Самое лучшее из Массачусетских дорожных чудовищ никогда не могло быть спроектировано командой в привычном понимании этого слова. Команды традиционного типа неспособны на такие высоты многоуровневой маниакальности. Нет, для построения таких конструкций требуется особая модель организации, которая обязательно должна встречаться и в области разработки программного обеспечения. Вероятно, они были спроектированы и построены группой инженеров, организованной на основе совершенно иной парадигмы, а именно «Заговор Упрямцев!».
«Заговор Упрямцев» - это международное тайное сообщество инженеров, технических специалистов и руководителей из различных отраслей. Их тайной эмблемой является гордиев узел. Их цель - окончательная комплексификация всего на свете. Их кредо: «Или по-другому, или никак». Важно не то, чтобы система была удобной или хотя бы приемлемой, а только то, чтобы она была другой, чтобы в ней было побольше «безделушек», Выглядите и чувствуйте себя über alles4.
Пользуйтесь или выбросьте
Дух Сирила Норткота Паркинсона5 (Cyril Northcote Parkinson) является божком этого заговора. Их самый священный рабочий принцип - никакие ресурсы не должны остаться неиспользованными. На каждый выезд с автомагистрали должна найтись своя эстакада. Каждый неясный вызов API должен найти свое применение, а действительно хорошая программа использует все вызовы. Если архивированная система не поставляется на десяти гибких дисках и более или, еще лучше, на CD, то она вряд ли может стоить тех денег, за которые вы ее купили. В инсталлированном состоянии программа должна занимать не менее 25 мегабайт. В процессе инсталляции должно быть создано множество каталогов. По крайней мере, некоторые из них должны быть подкаталогами в каталоге \WINDOWS, в который будут скинуты различные файлы с непонятными именами вместе с собственными .INI файлами нового продукта. И, естественно, инсталляцию вряд ли можно считать надежной, если основательно не переделать содержание WIN.INI, CONFIG.SYS, AUTOEXEC.BAT и даже SYSTEM.INI. Иначе какой-нибудь несчастный пользователь сможет деинсталлировать эту программу, просто удалив несколько файлов или каталогов.
«Заговор Упрямцев» имеет корни в области гражданского проектирования и городских подрядов, где суть игры заключается в том, чтобы применить как можно больше кирпича и строительного раствора, потому что дядюшка Берт владеет кирпичной фабрикой, а племянник Финис имеет цементный завод. Что касается программирования, то и здесь кому-то приходится искать способ, как использовать все эти мегабайты оперативной памяти и гигабайты дискового пространства. Мы терпеть не можем, когда мощности Pentium остаются незадействованными.
В любом случае конечные пользователи могут испытывать неудобства от слишком больших компьютерных мощностей. Их ослепляет ослепительная скорость. Ведь на самом деле пользователи хотят видеть события: сверкающие изображения, прыгающие значки, мигающие вспышки. Образ действия более важен, чем его выполнение. Именно здесь «Заговор Упрямцев» как раз и старается «уважить» закон Паркинсона с помощью поиска изощренных и излишне сложных решений. Проектные команды специально организуются таким образом, чтобы их участники работали с противоположными целями, так как это обеспечивает увеличение количества элементов в системе и их внутреннюю несовместимость, приводя к высокой степени бесполезной сложности.
Дорогой читатель, не относитесь с сомнением к моим словам. Не забывайте их как параноидальную болтовню сумасшедшего методиста! Доказательство этой дьявольщины как раз перед вами. В окнах вашей чудесной машины, в значках сворачивания и разворачивания, в панелях управления, в мельницах состояний ожидания можно увидеть тайные символы их программной извращенности.
Какого черта
Вы просите доказательств - вы их получите. Мой коллега по офису и я проверяли Персональные Информационные Менеджеры (Personal Information Managers), функционирующие в среде Windows. Один из них был снабжен вычурным имитатором времени DayTimer™ и очень расточительно использовал свободное пространство экрана. Он был просто чертовски умным, настолько, что было ясно: только «Заговор Упрямцев» мог создать такое.
Все становится понятно уже по одной операции удаления: для удаления чего-либо из блокнота вам нужно перенести этот элемент к иконке с изображением проволочной (да-да, именно проволочной!) мусорной корзины. После чего корзина воспламеняется! Пиктографическое жертвоприношение! На создание модуля этой корзины были затрачены немалые программистские ресурсы. Но она такая замечательная! Она обязательно произведет впечатление на начальников, агентов по материально-техническому снабжению и других людей с умственными недостатками. Однако мало кто заметил, что на машине с быстрым 486 процессором, ускоренной видеокартой и большим монитором эти языки пламени очень напоминали шоу Лоренса Уэлка (Lawrence Welk6)! Что еще здесь нужно говорить?
Методы разработки, которые применяет «Заговор», отражают его цели и служат им. Лучшие профессионалы объявляют о создании продукта, потом придумывают к нему упаковку и затем начинают кодировать. Составление схем разработки - это довольно трудное дело. Намного проще их составлять на основе уже существующего кода, поэтому упрямые команды, разрабатывающие программное обеспечение, действуют так. Они начинают с кодирования модулей низкого уровня, например драйверов экрана или пылающих корзин, а на их основе строят все остальное и составляют схему разработки в целом. При проведении бета-тестирования могут быть написаны и системные требования - в качестве предисловия к руководству пользователя.
Будьте внимательны, поскольку «Заговор упрямцев» может маскироваться под обычные научно-исследовательские группы или проектные команды, однако на тайных совещаниях, проводимых вечером после десяти, они замышляют противоестественные сценарии разработки. Вы когда-нибудь задумывались о том, почему некоторые из ваших приятелей допоздна задерживаются на работе? Очень может быть, что они оказались втянуты в тайные церемонии, проводимые 1 апреля 1993 года7 ознаменование 666-й годовщины создания «Заговора упрямцев».
Из журнала Software Development, том 1, № 4, апрель 1993 г.
1 Этот альбом был выпущен в качестве шутки по случаю большой компьютерной конференции, однако он дает верное представление о корпоративной культуре и политике IBM.
2 От англ. «skunk works» - маленький, часто изолированный исследовательский отдел какого-либо предприятия, функционирующий полусамостоятельно, практически без контроля начальства. – Прим. перев.
3 Аббревиатура от английской фразы из этого романа: «There ain't no such thing as a free lunch!» (В природе не существует таких вещей, как бесплатные завтраки). - Примеч. перев.
4 Над всем (нем.) - Примеч. науч. ред.
5 Сирил Норткот Паркинсон (1909-1993) - английский писатель, публицист и историк, прославившийся сборником трактатов под заглавием «Закон Паркинсона». - Примеч. ред.
6 Lawrence Welk (1903-1992) - создатель и ведущий музыкальных программ на американском телевидении (Lawrence Welk Show). - Примеч. ред.
7 Из писем, пришедших по электронной почте, стало ясно, что не все читатели этой заметки поняли, что в день выхода заметки из печати отмечался День дураков.
уход за кожей лица
Пользователь, раз уж ты добрался до этой строки, ты нашёл тут что-то интересное или полезное для себя. Надеюсь, ты просматривал сайт в браузере Firefox, который один правильно отражает формулы, встречающиеся на страницах. Если тебе понравился контент, помоги сайту материально. Отключи, пожалуйста, блокираторы рекламы и нажми на пару баннеров вверху страницы. Это тебе ничего не будет стоить, увидишь ты только то, что уже искал или ищешь, а сайту ты поможешь оставаться на плаву.