Текст книги "Человеческий фактор в программировании"
Автор книги: Ларри Константин
сообщить о нарушении
Текущая страница: 5 (всего у книги 26 страниц) [доступный отрывок для чтения: 10 страниц]
Для руководителей проектов, стремящихся удержать в голове набор подходов к управлению программистами-одиночками, может быть полезной аналогия с выпасом скота. Старшим ковбоям приходилось перегонять стада на пастбища, следя за тем, чтобы животные не отбивались от стада, и периодически собирая их вместе. Они внимательно следили за своими работниками и скотом. Они также не забывали про то, чтобы ковбои могли выпустить пар в субботние вечера.
Ковбойские коллективы
Меилир Пейдж-Джонс (Meilir Page-Jones) придумал очень практичную схему для определения эпохи зрелости, в которой пребывает процесс разработки программного обеспечения. Некоторые группы работают в эпоху анархии и разрабатывают программное обеспечение без помощи каких-либо системных подходов и даже не применяют систематизированные знания. Все опирается на индивидуальные умения. Эпоха фольклора характеризуется культурой коллективной мудрости, накопленного знания, которое часто воплощено в историях об успехе или неудаче или в эмпирических правилах, приобретенных в прошлом. Эпоха методов основана на использовании системных, не всегда формальных подходов к разработке программного обеспечения, которые выходят за пределы фольклора. Эпоха метрики базируется на проведении измерений для оценки качества и производительности и на организации обратной связи для улучшения процесса разработки, основанного на измерениях. И наконец, эпоха инжиниринга, в которую разработка программного обеспечения становится настоящей инженерной дисциплиной. В процессе непрерывного усовершенствования применяются методы, основанные не на фольклоре или догадках, а на теории, проверенной в исследованиях. Принимаемые решения и компромиссы являются системными и вырабатываются на основе моделей и измерений, вовлекая данные из растущего объема знаний.
Инжиниринг – это то, что вы получаете, когда зрелые индивидуумы в зрелых организациях используют зрелые методы. Анархия возникает, когда вы просто загоняете группу кодирующих ковбоев в загон и указываете им на проблему.
К сожалению, когда индивидуалисты включаются в группы, у них проявляется склонность к противостоянию. Нередко они начинают стремиться к противоположным целям. Без творческого лидерства группа кодирующих ковбоев может привести к неуправляемому хаосу.
Находясь в команде с другими, менее упрямыми людьми, кодирующие ковбои могут склоняться к нарушению командной работы. Одни ковбои воздерживаются от участия в групповом решении задачи, другие могут отнимать много времени, предлагая свои любимые варианты и подходы. Зачастую они весьма критически относятся к любым идеям, которые были предложены не ими, и вступают в конфликт со всей остальной группой.
В худших случаях ковбои будут загнаны в угол и подвергнутся презрению за свой негативный настрой. Со своей стороны, кодирующие ковбои могут начать смотреть на всю команду как на сборище поборников группового мышления, которые не смогут закодировать даже выход из картонной коробки и просто не способны оценить истинную гениальность.
Руководители должны знать, как предотвратить такую поляризацию в коллективе ради сохранения команды и получения конечного продукта. Прямая конфронтация является нежелательным стилем руководства в отношении кодирующих ковбоев, подавление которых может быть довольно рискованным шагом. Они заработали свою репутацию за свои твердые мнения, чувствительное самолюбие и зудящие указательные пальцы. Руководители вряд ли смогут победить в таком столкновении. Оно может только побудить ковбоев уйти в еще более глубокую оппозицию.
Главный вопрос для руководителей – что делать с индивидуалистами. Некоторые руководители настаивают на том, что индивидуалистов следует отделять от стада и уводить на выпас, но этот вариант не всегда доступен и может не соответствовать интересам организации. Мой начальник говорит, что работа руководителя заключается в устранении препятствий, которые мешают подчиненным делать работу хорошо и раскрывать свой потенциал. Как мне повезло. Часть потенциала индивидуалистов, которые работают под началом хорошего руководителя, состоит в том, чтобы принести в организацию свой заряд творческой энергии и недюжинные способности.
Некоторые команды выигрывают от оппозиции, тогда как другие не могут перенести разногласий. Это зависит от основной модели, по которой организована команда (Constantine, 1993 [21]; Larson и LaFasto, 1989 [47]). Проектные команды, которые основаны на иерархическом типе руководства и назначении заданий или опираются на традиционные приказы и инструкции, или возглавляются властными лидерами, будут испытывать большие сложности с индивидуалистами и кодирующими ковбоями. Работа таких традиционных тактических команд (см. главу 11) может быть затруднена оппозицией, а подобный стиль управления может подтолкнуть индивидуалистов к противодействию.
С другой стороны, ничем не стесненная команда «прорыва» (глава 12) может только укрепиться от присутствия в ней индивидуалистов, чей независимый дух и творческая индивидуальность так нужны группе. Весь вопрос состоит в том, как создать обстановку творчества, а не хаос. Ключом к получению полезного результата является поддержание высокого уровня взаимоуважения и признание профессионализма друг друга. В командах, где сотрудники смотрят на своих коллег как на опытных про-фессионалов, способных генерировать хорошие идеи, здоровое соперничество не переходит в драку.
Команды, стремящиеся к техническому консенсусу (см. часть I), могут также быть хорошим местом для индивидуалистов. Технический консенсус достигается тогда, когда вклад каждого члена команды учитывается в общем решении, которое все участники команды признают правильным, хотя и не обязательно могут быть согласны с каждой его деталью.
Оппозицию и критицизм никогда не следует путать с нелояльностью. В действительности критическая оценка часто является самой ценной информацией, услышать которую важнее всего. Здоровый скептицизм и критический взгляд нужно поощрять, а не отвергать. Исследования выявили, что качество группового решения задач напрямую зависит от этой «негативной обратной связи». Группы оказываются более эффективными, если в них присутствует «резидентный критик», или «адвокат дьявола», или если в них лучше используются диалектические процессы противопоставления идей и активная критика (Constantine, 1989 [11]; Priem и Price, 1991 [59]).
Руководители должны помнить, что оппозиция сопротивляется контролю и власти в той мере, в какой власть старается контролировать оппозицию. Поэтому, вместо того чтобы контролировать, сотрудничайте! Один из способов эффективного сотрудничества с оппозицией – наделить ее законным статусом. В одном из подходов (Constantine, 1989 [11]; 1991 [13]) резидентный критик или «адвокат дьявола» рассматривается как ценный сотрудник, роль которого очень важна для успеха группы. Так же, как и «песчинка в устрице», критическое наблюдение за работой команды является необходимым раздражителем, формирующим базис для появления жемчужин в области программирования (Thomsett, 1990 [62]). Как член команды индивидуалист формально обязан критиковать решения, придерживаться альтернативных точек зрения, отмечать исключения, сложности и ограничения и следить за тем, чтобы группа рассматривала альтернативы и исследовала трудности, связанные с предложенными решениями.
Зачастую индивидуалисты хороши как критики, а не как критикуемые. Однако когда они с головой уходят в работу, их результаты следует контролировать и проверять. Это может вызвать возмущение индивидуалистов, поскольку воспринимается ими как назойливость и подозрительность. Критические отзывы о работе кодирующих ковбоев лучше всего выражать в максимально безличной форме, обращаясь прежде всего к аналитическим и критическим способностям индивидуалистов и призывая к творческому подходу в решении любых возникающих задач.
Как это ни удивительно, но наибольшие ограничения на индивидуалистов накладываются ими самими. Они могут упорствовать в своем желании быть уникальными, сделать все по-другому, даже в ущерб практичности. Работа в одиночку также ограничивает список того, за что они могут взяться. В конце концов, индивидуалисты могут вызывать у коллег отторжение.
Разногласия и разнообразие
Теперь мы знаем, что разнообразие в командах способствует лучшему преодолению трудностей и принятию решений. Исследования по групповой динамике, которые проводились в течение нескольких десятилетий, показали, что разнородность почти всегда дает больше преимуществ, чем однородность. Команды, состоящие из мужчин и женщин, лучше справляются с решением проблем, чем однополые команды. Группы, которые состоят из людей разных специальностей и с разным образованием, достигают лучших результатов. Разнообразие приносит успех независимо от того, как оно проявляется – в личностях, в стиле общения, в культуре или в этническом происхождении.
Таким образом, не следует избавляться от всех индивидуалистов. Нужно, чтобы в командах проявлялось все разнообразие стилей лидерства и откликов на это лидерство, в том числе и сопротивление ему. Командам нужны движущие силы, новаторы, способные генерировать новые идеи, и чемпионы, способные их продвигать. Но также нужны критики и скептики, которые своим холодным сомнением противостоят необузданному энтузиазму и не пропускают идеи, не имеющие хорошего обоснования. Оппозиция лидерству может быть полезной даже для самой команды, так как позволяет удерживать руководство в определенных рамках.
Трудности возникают, когда мы рассматриваем оппозицию с точки зрения упрощенных методов командной работы, основанных на идеалах полной гармонии и фантазиях о сотрудничестве без конфликтов. Спор может способствовать наивысшей коллективной производительности и быть самым важным элементом в творческом процессе. В результате появляется качественный продукт.
Кто же такой программист-мудрец? Это тот, кто рассматривает оппозицию как возможность и способен видеть гибкость в споре. Программист-мудрец – это старый, умудренный опытом работник фермы, который прошел через фермерские войны, побывал в пустынных прериях и вернулся обратно на родную ферму. Программист-мудрец может быть даже исправившимся ковбоем – тем, кто никогда не терял уважения к индивидуализму, но который научился ценить сотрудничество.
По материалу из журнала American Programmer, июль 1993 г.
III
Организация работы
11
Традиционная тактика
Ок, ребята, теперь давайте организовываться! Вопрос только – как? Работая самостоятельно, вы можете работать как угодно. Вам не нужно координировать свою работу с тем, что делают другие, и вам не придется подлаживаться к кому-либо. Вы можете в навязчиво-маниакальной манере аккуратно класть все вещи на свои места и в точности выполнять инструкции в соответствии с моделью жизненного цикла, принятой в разработке стандартного программного обеспечения. Или вы можете оставить все разбросанным по всему офису в полном беспорядке и кодировать по вдохновению или просто когда вздумается. Однако если вместе работают два человека или более, то ключевым словом здесь является слово «вместе». Работа, которую они выполняют, и способ ее выполнения требуют координации.
В этой главе начинается исследование вопросов организации и управления работой людей: как работа организована и как люди, работающие вместе, координируют свои действия (Constantine, 1990 [12], 1991 [15], 1003 [21]). Рассмотрим организацию как человеческий эквивалент архитектуры программного обеспечения, соотнося руководство с динамическим управлением программными компонентами. И снова мы придем к знакомым понятиям структуры и динамики систем управления. Когда вы хотите организовать новую компанию по разработке программного обеспечения или очередной программный проект, возникают все те же вопросы и проблемы.
Каким же образом их решать? Как можно наладить совместную работу группы людей – будь это проектная команда или целая корпорация? Как организовать группу, структурировать работу и управлять процессом?
Какой способ является правильным? Самое время вспомнить один из стандартных «ответов консультантов»: «Это как посмотреть!» Поиск правильного способа организации проекта похож на поиск правильного способа кодирования подпрограммы. Нужно исходить из того, что вы собираетесь получить в результате (Constantine, 1993 [21]).
Обычная работа по созданию еще одного набора драйверов для принтера или еще одного варианта традиционного генератора растровой развертки может потребовать совсем иной модели организации и руководства, чем работа над новейшим CASE-инструментом, поддерживающим процесс параллельного проектирования программного обеспечения и проектирование объектно-ориентированного ПО на основе консенсуса. В своей небольшой, но превосходной книге, посвященной командной работе, Jlap-сон и ЛаФасто (Larson и LaFasto, 1989 [47]) определили несколько основных вариантов такой работы, каждый из которых имеет свои преимущества. Здесь мы рассмотрим четыре отдельных и очень различных модели организации командной работы, их преимущества и недостатки.
Создание организации
Итак, давайте организовываться! Самый простой и надежный вариант основан на проверенной временем стандартной процедуре. Координирование работы более чем одного человека заключается в наделении кого-ли-бо полномочиями руководителя. Функция руководителя состоит в том, чтобы управлять и следить за работой других. Эта структура может быть расширена с помощью рекурсии. В результате появится иерархия руководителей, где высшие чины руководят низшими. Это простая, устойчивая и знакомая всем форма организации: традиционная пирамида, основанная на иерархии власти. В проектах по разработке программного обеспечения, ведущихся согласно этой модели, в иерархии может не быть много уровней, но это все равно иерархия. В принципе, такая структура может быть очень эффективной, однако на практике она может разрастись до огромной бюрократической машины, не способной ни к чему, кроме сохранения собственной бюрократической неэффективности.
Такая модель является не просто способом работы. Она может быть образом жизни. Недавно я занимался реорганизацией своей коллекции записей, чтобы освободить место для новых компакт-дисков, и обнаружил настоящее сокровище – старинную запись «Paean» из корпоративного альбома компании IBM.[17]17
Этот альбом был выпущен в качестве шутки по случаю большой компьютерной конференции, однако он дает верное представление о корпоративной культуре и политике IBM.
[Закрыть] Слушая, как Ассоциация британских секретарей в Америке (на самом деле!) энергично исполняет «Песню деревенского клуба IBM», я стал думать о корпоративной культуре и о том, как способ нашей работы определяет наше видение мира, и наоборот.
Традиционный взгляд с вершины пирамиды рассматривает организацию как основу устойчивого функционирования, а контроль – как ключ к поддержанию целостности. Лидерство опирается на власть. Руководители принимают решения, а подчиненные должны выполнять их, демонстрировать лояльность и следовать инструкциям начальства. Предсказуемое и надежное исполнение достигается за счет стандартов, процедур и правил работы. У каждого есть своя работа, своя роль, свои обязанности и свое место в иерархии. Корпоративные интересы, или интересы отдела, или интересы проекта стоят превыше всего, а работники получают вознаграждение за добросовестное исполнение своей части в большой работе.
В общем виде эта модель довольно проста. Ответственность возлагается на кого-либо, кто может принимать решения и отдавать приказы (желательно, чтобы этот человек разбирался в деталях и тонкостях дела). В традиционных иерархиях подразумевается, что решения принимаются строго сверху вниз. На то, чтобы необходимые данные поступили к ответственному лицу, может потребоваться время, но как только это произошло, процесс принятия решения может быть довольно эффективным. Решение принимается, когда руководитель готов его принять. Не требуется никаких консультаций. Не нужны ни обсуждения, ни дискуссии, ни исследования. Очевидно, что это может быть как силой, так и слабостью, поскольку многое начинает зависеть от того, кто находится на вершине пирамиды. Правильные решения могут приниматься так же быстро, как и неправильные, а если руководитель обдумывает решение слишком медленно или с ним трудно выйти на связь, то это может привести к краху всей пирамиды.
Властная пирамида
Когда речь идет о проектах по разработке программного обеспечения и командной работе, традиционная модель лучше всего подходит для того, что называется тактической работой. В тактических проектах территория знакома, а параметры известны. Самое главное – это выполнить работу. Я заточил свои «программистские зубы» на тактических проектах, в которых разрабатывались стандартные бизнес-приложения, например платежные ведомости, исчисление себестоимости и кадровые архивы. После того как вы сделаете пару систем ведения платежных ведомостей, они все начинают казаться одинаковыми. Даже если это не так, такой взгляд позволяет упростить работу и дает возможность применять стан-дартные подходы. В итоге вы знаете каждый свой шаг и сможете сделать их даже во сне.
Ясность имеет решающее значение для тактической командной работы – ясность требований, ясность инструкций, ясность ролей. В этом мире методы разработки становятся более эффективными, если они хорошо определены и опираются на ясные стандарты и нормативы. При разработке программного обеспечения необходимо тщательно продумать жизненный цикл проекта и последовательность его этапов. Работа должна быть выполнена аккуратно и эффективно. В такой команде внимание группы акцентировано на текущей задаче. Точка. Члены команды больше всего нуждаются в ясных инструкциях от лидеров проекта и руководства. Каждому члену команды назначается конкретная часть хорошо понимаемой работы, и все выполняют то, что должны делать.
Традиционная иерархия работает. Многие компании в нашей отрасли и бесчисленные проекты по разработке программ организованы по этому принципу, в том числе и некоторые из наиболее успешных. Корпоративные песенники, восхваляющие бесстрашных лидеров компаний и их верных последователей, – лучшие тому свидетельства.
Такая ясно определенная и предсказуемая среда может быть комфортной, однако не каждый может чувствовать себя уютно в таком мире. Те, кому это удается, чаще всего лояльны, преданны и исполнительны. Они придают большее значение работе, чем самим себе, и всегда готовы к выполнению указаний лидеров. Такие люди предпочитают обращать большее внимание на программы, чем на людей. Тактические команды – это рай для конформистов и одержимых, для тех программистов, которые занимаются базовым программированием и о которых можно сказать, что они «соль земли». Тактическая командная работа подходит для тех, кто хочет знать, что делать, и делает это.
Обратной стороной медали является то, что любая группа, организованная по принципу традиционной иерархии, может очень легко застрять на месте. Сопротивляясь полезным инновациям в интересах устойчивости власти, такая группа тратит силы на строгое следование стандартам и процедурам, а не на решение задач и производство продукта. В лучшем случае такие группы эффективны и продуктивны, однако они не проявляют должной творческой активности. Их новаторство может выражаться не более чем в частичных улучшениях уже существующих технологий, то есть в эволюционных изменениях, а не в революционных. Если посмотреть на лидеров отрасли, полагающихся на традиционную иерархию, то зачастую можно увидеть, что их главные новшества были либо заимствованы извне, либо приобретены через внутренний обмен опытом.
Компании или группы разработчиков, организованные по этому принципу, вероятнее всего будут иметь особые трудности с кодирующими ковбоями (см. главы 7, 8 и 10). Независимые индивидуалисты и традиционная иерархия – это несовместимые понятия. Разработчики, которые сопротивляются власти или подвергают ее сомнению, а также стремятся идти своей дорогой или предпочитают отходить от стандартов, могут остаться без надбавки к зарплате или обнаружить себя в списке сокращения расходов.
С вершины пирамиды или изнутри может показаться, что другого способа организации и управления не существует. В конце концов, кто-то ведь должен быть ответственным, правильно? Либо вы руководите, либо выполняете указания, либо уходите с дороги. Некоторые люди до сих пор не видят никакой альтернативы иерархии. Но мы также когда-то думали, что вложенные подпрограммы, вызываемые из управляющей программы, – это единственный способ компоновки программ. Теперь мы используем множества связанных объектов и одноранговые сети с распределенными базами данных.
Что касается людей, то они всегда намного более гибки, чем программы. По крайней мере, некоторые люди.
Из журнала Software Development, том 1, № 3, март 1993 г.
