Текст книги "Человеческий фактор в программировании"
Автор книги: Ларри Константин
сообщить о нарушении
Текущая страница: 7 (всего у книги 26 страниц) [доступный отрывок для чтения: 10 страниц]
14
Синхронное плавание
Хотите увидеть, как по-настоящему быстро разрабатывать приложение? Возьмите фильм Гаррисона Форда (Harrison Ford) «Свидетель» («Witness») и найдите в нем сцену, когда общество Амиш строит сарай за один день. Самое интересное в этой проектной команде – не ее поразительная эффективность, а отсутствие руководителя и даже необходимости в руководителях или руководстве. Они почти не разговаривают и им уж точно не приводится спорить по поводу конструкции сарая или договариваться о том, кто и что должен делать для того, чтобы его построить. Они просто взялись за работу и стали ее выполнять быстро и эффективно, почти в полной гармонии, пока не закончили.
Конечно, это мечта менеджера, своего рода управленческая утопия. Слово «утопия» буквально означает «место, которого нет», а сцена из фильма «Свидетель» исправно происходит в округе Ланкастер, штат Пенсильвания. Более подходящим, наверное, является слово «эутопия», означающее «хорошее место». Таким образом, эутопия – это то идеальное место, где вы хотите быть. Поэтому мы можем назвать такую модель организации эутопической командной работой.
Быть руководителем эутопической группы, разрабатывающей программное обеспечение, очень просто – настолько просто, что для осуществления руководства вам вряд ли придется что-либо делать. Люди вокруг вас делают все, что должно быть сделано. Не нужно стоять над душой у каждого или разъяснять что-либо на пальцах. Все идет гладко потому, что люди, которые работают для вас и вместе с вами, разделяют ваши представления о работе команды – о том, что нужно делать и каким образом. Это люди, которые вам подходят; они думают так же, как и вы, и во многом смотрят на мир вашими глазами. Едва вы успеваете сказать слово, как они уже принимаются разрабатывать следующий набор модулей или кодировать расширения для графического пользовательского интерфейса, или делать еще что-нибудь нужное. Все – люди, программное обеспечение, программирование – подходит друг другу так точно, как будто вы все придумали сами, не прилагая к этому никаких усилий. В команде не существует конфликтов и не нарушается дисциплина. Подобно команде по синхронному плаванию, это само воплощение идеального совершенства и гармонии.
Такая эутопическая фантазия является последней из наших четырех основных моделей организации проектов – синхронная парадигма, модель эутопической командной работы. Традиционные тактические команды координируются иерархической властью, «команды прорыва» – индивидуальной инициативой, а команды совместного решения задач – взаимодействием сотрудников. Эутопические команды зависят от выбора направления. Члены такой команды следуют направлению, заданному общим пониманием и общими ценностями. Поскольку все члены команды понимают друг друга и разделяют общее представление о том, куда движется команда и каким образом она будет достигать своих целей, они могут работать совместно без какой-либо заметной координации. Подобная направленность обычно не становится доминирующим объединяющим принципом для всей организации в течение длительного периода времени. Однако многие группы, большие и маленькие, зависят от некоторой степени направленности или функционируют синхронно в течение более коротких периодов.
Где находится место, которого нет
Случай, который произошел с моим коллегой несколько лет назад, поможет проиллюстрировать этот режим работы. Консультант по организационному развитию встречалась с клиентами в конференц-зале госпиталя. Во время этой встречи одна из ножек массивного дубового стола подломилась. Стол придавил ее ногу. Нога оказалась вывернута, а движения скованы. В то же мгновение все вскочили со своих мест, чтобы помочь. Двое стали приподнимать тяжелый стол с ее ноги, а третий взял за руку, чтобы успокоить. Кто-то побежал в рентгенологию. Еще один выскочил в холл, чтобы принести носилки. Между членами этой медицинской команды не проскочило ни единого слова. Они все точно знали, что нужно делать, и каждый просто стал выполнять какую-то часть. Никто не назначался руководителем, не требовались ни обсуждения, ни переговоры, и, тем не менее, все занимались одним делом, не противореча друг другу.
В подобном синхронном взаимодействии нет ничего магического. Если посмотреть на этих людей внимательно, то можно заметить, что взаимодействие между ними главным образом невербальное. В существенной степени оно основано на молчаливом согласии и предварительном зна-нии. Так как каждый член команды видит, что делают другие, он может подстраивать свои действия под общее дело. Поэтому не все сразу бросаются к телефону, а носилки появляются в нужный момент.
При условии, что все члены эутопической команды хорошо понимают стоящую задачу, такая команда может достигать высокой эффективности в сложных или критических условиях (подобно ситуации в конфе-ренц-зале госпиталя) или при выполнении предсказуемых и ясных задач в течение более длительных периодов (как, например, построение сарая). Понимание задачи и наличие представления о том, как она может быть выполнена лучше всего, имеет важнейшее значение. Каждый работник в обществе Амиш видел, как строят сараи, и, вероятно, когда-нибудь участвовал в этом. Каждый, кто находился в конференц-зале госпиталя, имел более чем достаточный опыт в оказании медицинской помощи. Почти наверняка никому из них не приходилось иметь дело с падающими столами переговоров, но это не имело значения; их профессиональный медицинский опыт и знания позволили им быстро понять новую ситуацию и действовать как обычно.
Ключом к эффективности эутопических команд является полная приверженность всех членов команды довольно сложной, но четко определенной концепции того, что является задачей и методами группы. Если эта направленность является слабой или частичной или концепция является неадекватной, группа не сможет выполнять свою работу без консультаций или без конфликтов или же не сможет отвечать требованиям изменяющихся условий; в этом случае либо потребуется более жесткое управление, либо трудности команды станут возрастать.
Люди, изучающие менеджмент и организации, хорошо понимают первые три из наших основных моделей команд и лежащих в их основе механизмов. В то же время о проектных командах, основанных на направленности, известно меньше. Хотя полностью синхронные команды на практике встречаются нечасто, сочетание высокой синхронизации с традиционной иерархией является менее редким. Такое сочетание можно встретить в крепких компаниях, которые работают в давно существующих отраслях, имеющих давние традиции. Консультант Роб Томсет (Rob Thomsett) и я обнаружили ряд довольно синхронных групп по разработке программного обеспечения в австралийском банковском доме, функционирующем по британской модели. В Японии, где корпоративный мир свято чтит традиции преемственности и единообразия, даже высокотехнологичные фирмы могут широко применять синхронную направленность.
Тихие воды
Эутопическая командная работа является полной противоположностью модели, основанной на сотрудничестве. Вместо обсуждений и перегово-ров нормой здесь является их отсутствие. Зачем нужны переговоры, если люди думают настолько одинаково, что почти с самого начала согласны друг с другом? Обратной стороной такой эутопической гармонии является то, что в обычной, повседневной работе все это безоблачное и спокойное сотрудничество может стать несколько скучным. Поскольку члены такой команды привыкли работать без особых дискуссий или вообще без обсуждений, они могут не общаться даже тогда, когда это им нужно. Если условия на рынке или базовая технология неожиданно или радикально изменяются, команда может оказаться неспособной среагировать или адаптироваться к этому так же хорошо, как группы, построенные на индивидуальной инициативе или на совместном взаимодействии. В худшем случае члены команды могут продолжить действовать привычным способом и не обращать внимание на изменяющийся вокруг них мир. Если что-то не соответствует их общим представлениям, они могут посчитать это не заслуживающим внимания или ответа.
Согласно общепринятым представлениям, современные руководители должны учиться выживать в бурлящей воде, плавать в компании с акулами и при этом добиваться успеха. Выжить, плавая в окружении акул, конечно, возможно, но большинство пловцов, наверное, предпочтет теплые, тихие воды. Естественно, команде по синхронному плаванию лучше держаться в стороне от бурлящих вод и подальше от водоемов, населенных акулами. Точно так же и эутопические команды лучше приспособлены к стабильным, постоянным и невраждебным условиям.
Однако небольшая степень синхронности может быть полезной даже для команд, построенных на других базовых моделях. Более узкая направленность и более четкое взаимопонимание уменьшают потребность в жестком контроле и расширяют границы, в которых усилия одних членов команды могут подкрепить или поддержать усилия других, а не свести их на нет или помешать им.
Эффективные руководители эутопических команд являются харизматическими гуру, способными формировать и применять сложные концепции, а также вызывать к ним доверие других людей. Для длительных проектов особую важность имеет их способность изменять и расширять эти концепции для того, чтобы учесть новые требования и изменить направленность в соответствии с ними.
Естественно, вы понимаете, о чем идет речь. Мы хорошо понимаем друг друга, верно? Поэтому здесь нечего больше говорить (даже то, что эта эутопическая направленность просто отлична!).
Из журнала Software Development, том 1, № 17, июль 1993 г.
15
Командная политика
Этот проект по разработке программного обеспечения был чрезвычайно успешным. Команда разработчиков приобрела известность созданием потрясающей системы с усовершенствованными сервисами и отличным графическим интерфейсом. По каким-то причинам руководство отказалось от этого продукта.
Команда – не остров. Группы, которые хорошо работают вместе в комнате для обсуждений, могут не иметь успеха при выходе на уровень корпоративной политики. Неудача есть неудача. Знать интерфейс программирования приложений и библиотеку классов так же недостаточно, как недостаточно знать способы прихода к консенсусу или процессы параллельного проектирования. Если вы не знаете правила игры, вы проигрываете. Название этой игры – «внешняя среда».
Команды по разработке программного обеспечения должны сторожить свои границы, защищая свою территорию. Однако нужно и наводить мосты. Новый компилятор является частью набора инструментов. Система поддержки принятия решений должна согласовываться с системой бухгалтерского учета, но также она должна быть пригодной и полезной для руководителей. Репутация компании неуправляемых приверед может способствовать попаданию команды в список на сокращение. С другой стороны, репутация супергероев С++ может привести к необоснованным ожиданиям при создании очередной объектно-ориентированной чепухи, начатой зятем президента компании.
Мы рассматриваем командную деятельность по созданию программного обеспечения с точки зрения моделей, определяющих стиль внутренней ра-боты. В свою очередь, Дебора Анкона (Deborah Ancona) из школы управления Sloan при Массачусетском технологическом институте исследует функционирование команды в реальной корпоративной среде, а также то, как внешние стратегии и стили команд влияют на производительность (Ancona и Caldwell, 1992 [1]). Анкона изучала консалтинговые команды, команды разработки новых продуктов, а также команды по сбыту товаров и управленческие команды. Данные, полученные ею в течение многих лет, совпадают с моим опытом изучения команд по программированию.
Сквозь измерения
Внешние стратегии команд – это сложная тема. Лидер команды или менеджер проекта может играть ключевую роль в урегулировании внешних отношений, однако эта тема сводится не только к тому, как ваш начальник ладит с ее начальником. Команды должны взаимодействовать и сотрудничать со множеством других подразделений организации. Эти взаимодействия происходят в нескольких измерениях: во властной структуре, в структуре задач и в информационной структуре.
Представим «властное» измерение как вертикаль. Важные внешние связи в этом измерении направлены вверх. Немногие команды могут достичь действительно высокой производительности, если они не умеют «ладить с руководством». Командам нужны «послы», политики, которые знают, как играть в политические игры в организации и как работать со властной структурой, чтобы команда и проект оказались в выгодном положении. Они способствуют хорошей репутации группы, представляя саму группу и ее преимущества. Связи с общественностью имеют большое значение для успеха команды, поскольку репутация команды может стать самоисполняющимся пророчеством. «Хорошие» команды получают самые лучшие проекты и первоочередной доступ к новому программному обеспечению и оборудованию. Часть успеха может быть связана с тем, что команда берется только за те задачи, которые ей по силам, а скучные или невыполнимые оставляет в стороне.
Вероятно, самой важной политической проблемой для команд является необходимость обрести и сохранить эффективную поддержку со стороны высшего руководства. Высокопоставленный руководитель или покровитель может сделать для команды больше, чем все 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».[19]19
Аббревиатура от английской фразы из этого романа: «There ain't no such thing as a free lunch!» (В природе не существует таких вещей, как бесплатные завтраки
[Закрыть] Да, в этой модели тоже есть недостатки. Для ее применения необходимо дополнительное обучение и приемлемые темпы работы. Кроме того, не все руководители с удовольствием расстаются с частью своей власти, чтобы работать наравне со всей командой. Формальное назначение ролей и строгая поочередность их исполнения может быть неудобной для небольших команд. Глупо, если один человек проводит обсуждение, другой ведет записи, а третий (и последний) программист произносит живой монолог по поводу дизайна иконок. Маленьким командам придется идти на слишком большие компромиссы или выбирать другую модель.
В любом случае, согласно духу этой модели, я открыт для всех идей, относящихся к улучшению структуры.
Из журнала Software Development, том 1, № 9, сентябрь 1993 г.
