355 500 произведений, 25 200 авторов.

Электронная библиотека книг » Ларри Константин » Человеческий фактор в программировании » Текст книги (страница 6)
Человеческий фактор в программировании
  • Текст добавлен: 6 октября 2016, 04:26

Текст книги "Человеческий фактор в программировании"


Автор книги: Ларри Константин



сообщить о нарушении

Текущая страница: 6 (всего у книги 26 страниц) [доступный отрывок для чтения: 10 страниц]

12
Методы хаоса

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

Возможно, некоторые из программистов старой школы и бескомпромиссная молодежь будут шокированы, если узнают, что ни иерархия, ни власть не являются необходимыми для эффективного сотрудничества людей, работающих в одной группе. Действительно, сейчас в области управления происходит мировая революция. Все больше и больше компаний во многих отраслях открывают для себя преимущества самостоятельных команд, автономных рабочих групп и «управления без управляющих». Одна из главных проблем традиционной пирамиды управления заключается в том, что она очень плотна в середине (во многих смыслах этого выражения). Управление среднего уровня привносит дополнительные издержки – не только в денежном смысле, но и с точки зрения оперативности. Чем больше вы стремитесь быть на переднем крае в любой технологии, тем более неповоротливой становится «властная пирамида». Истинно новаторский подход требует такой стремительности, которая недостижима с помощью традиционной тактики вертикального управления.

Прорывы

Проектные команды скорее добьются настоящего успеха в развитии технологий, если обратятся к гибкости, которую дает независимость. Необходимо использовать всю силу самостоятельного творчества, не стесненного инструкциями и контролем. Суть состоит в том, чтобы извлечь все лучшее из изобретательской энергии вольнодумцев, поощряя дух свободных исследований и личной инициативы. Нужно поддерживать некоторый творческий беспорядок, граничащий с хаосом, – своего рода контролируемое безумие, которое позволяет отойти от шаблонов, ограничений и расширить представления о собственных возможностях. Все это противоречит закрытым шаблонам корпоративных пирамид, поскольку подрывает основы власти и выбрасывает традиционный подход на ветер. Это серьезно угрожает традиционным методам управления, однако это как раз то, что нужно для освоения новых земель.

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

Деятельность «команд прорыва» зависит от индивидуальной инициативы. Решения принимаются не централизованно, а самостоятельно, на рабочем месте – теми, кто обнаружил проблему и знает, как ее решить. Держать курс такой группе помогает своего рода дружеская соревновательность. Именно общий интерес и любовь к игре, а также взаимное уважение игроков друг к другу удерживает их от того, чтобы разбежаться в разные стороны.

Чаще всего эту модель можно обнаружить в небольших высокотехнологичных компаниях, недавно возникших предприятиях и в проектно-ис-следовательских отделах больших организаций. Все они могут быть довольно успешными. Действительно, многие мускулистые корпоративные бегемоты полагаются на «отделы скунсов».[18]18
  От англ. «skunk works» – маленький, часто изолированный исследовательский отдел какого-либо предприятия, функционирующий полусамостоятельно, практически без контроля начальства.


[Закрыть]
Именно оттуда исходят новые идеи и продукты, позволяющие сохранять мотор коллектива в работоспособном состоянии.

Работа и игра

Представьте такую сцену, действительно имевшую место в одной из крупных компаний западного побережья. Вы входите в вестибюль и видите, как бородатый человек средних лет, который потом оказывается вице-президентом научно-исследовательского отдела, отвечает на телефонные звонки. Вы говорите ему, что вы консультант по графическим пользовательским интерфейсам, и в ответ он машет вам рукой – «по коридору налево…». Едва уклонившись от «летающей тарелки», пронесшейся на околозвуковой скорости, вы отправляетесь на поиски какого-нибудь начальника. Безуспешно. Увидев мерцающий экран монитора в одной из комнат, вы подходите к сотруднику, занятому просматриванием библиотеки классов. Этот человек оказывается офис-менеджером. Но разговор с ним становится все более трудным, так как игра в «летающую тарелку», происходящая в коридоре, набирает обороты. Два программиста, занятые отладкой кода с целью устранения ошибки в операционной системе, орут, чтобы было потише, но, в конце концов, сами втягиваются в состязание. Через некоторое время весь отдел переходит на соседнюю парковку и устраивает там целый турнир, в котором участвуют пять «летающих тарелок».

Для случайного наблюдателя все это может показаться бедламом или детским садом, однако игра «в тарелку», в которой множество «летающих тарелок» не сталкивались друг с другом, натолкнула пару программистов на неожиданные идеи. Они придумали новое решение одной сложной проблемы в многопользовательском программном продукте, разработкой которого сейчас занимается их отдел. Была ли это простая случайность? Было ли это простым валянием дурака на работе? Трудно сказать. Работа – это игра, а игра – это работа. Был ли встреченный офис-менеджер инженером по разработке программного обеспечения? Вы никогда не догадаетесь.

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

Конечно, такая модель не всегда работает, и даже когда она работает, оригинальность может иметь и обратную сторону. Чрезвычайно трудно вести собрание по планированию или разбор кода, если сотрудники постоянно заходят и выходят, а те, кто сидят в комнате, заняты написанием писем на лэптопе или играют в шахматы на карманной доске. В лучшем случае коммуникации внутри «команды прорыва» могут быть случайными, даже если все находятся в одной комнате. Дело не в том, что эти творческие индивидуалисты необщительны – просто в таком хаосе информация очень легко пропадает. («Да-да, этот клиент на прошлой неделе писал нам об изменении в интерфейсном протоколе. Это письмо где-то сохранили. Наверное.»)

Блестящий и совершенно беспристрастный психолог Дэвид Кантор (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 Seu-rat): «Белая, чистая страница или холст – вот что он любит; в них есть так много возможностей».

Могу сказать то же самое.

Из журнала Software Development, том 1, № 6, июнь 1993 г.


    Ваша оценка произведения:

Популярные книги за неделю