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

Ларри Л. Константин

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

Предисловие

Другая сторона программного обеспечения

Эта книга о другой стороне программного обеспечения — той, что смотрит во внешний мир. Эта сторона компьютеров касается людей — технарей, как вы и я, и обычных людей, как вы и я. В собранных здесь заметках исследуются многие разнообразные аспекты человеческого фактора в программировании (peopleware), которые обеспечивают интерфейс между программным обеспечением и его разработчиками, а также между программным обеспечением и его пользователями.

Мои редакторы, как в журналах, в которых этот материал появился впервые, так и в издательстве Prentice Hall, разрешили мне затронуть большой круг вопросов. Тема человеческого фактора в программировании необъятна, и это позволило мне писать почти обо всем, о чем я хотел написать — начиная от организационной культуры и организации проектов, хаоса и дисциплины в кодировании, инструментов и методов программирования и заканчивая пользователями, юзабилити и пользовательскими интерфейсами. Эта широкая область охватывает особый промежуточный мир, в котором сливаются границы между техническими и социальными вопросами. Здесь психология встречается с кибернетикой, а теория и практика смешиваются друг с другом. Все это отражает мой давний личный и профессиональный интерес как к людям, так и к программному обеспечению для компьютеров.

Эта книга является пересмотренным, расширенным и обновленным переизданием книги «Constantine on Peopleware», Prentice Hall, 1995 [26]. Книга слишком радикально пересмотрена, чтобы называться вторым изданием, но в то же время она тесно связана со своей предшественницей. Читатели смогут найти здесь много новых материалов, освещающих данную тематику. К главам из первоначального издания добавлены 25 новых статей, которые впервые публикуются в виде книги. Статьи включают в себя все 52 заметки, которые изначально публиковались в Computer Language Magazine и Software Development под рубрикой «Peopleware», включая «потерянную заметку», появившуюся в самом конце этой серии (см. приложение). Кроме того, для удобства читателя я добавил еще семь близких по содержанию статей из журнала Object Magazine. Они особенно важны с точки зрения общего представления о том, что такое дизайн, ориентированный на использование. Описание этого подхода было улучшено и расширено в книге Люси Локвуд (Lucy Lockwood) «Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design», Addison-Wesley, 1999 [30], которая получила всеобщее признание.

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

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

Данный расширенный сборник разбит на девять тематических разделов. Каждая заметка помещена в соответствующий раздел с тем, чтобы в какой-то мере сохранить последовательность в изложении. Были добавлены новые разделы, посвященные организационной культуре, а также юзабилити объектов программного обеспечения. Читатель быстро поймет, что каждая статья, будучи взаимосвязанной с другими, является, тем не менее, самостоятельным материалом. Думаю, что отчасти именно это вызывало интерес к моим журнальным заметкам и к первому сборни-ку, поскольку каждая глава может быть прочитана независимо от других в такси или в перерыве между встречами.

Кроме того, новые главы размещены блоками для того, чтобы читатели первой книги смогли их быстро найти. Новые главы: 22–25, 31–32,40-41, 43–49, 53–61, а также приложение.

Данный материал собран из разных мест. Я надеюсь, что эта книга еще долгое время будет оставаться ценным источником и продолжит раздражать, вдохновлять и просвещать этих удивительных людей, которые работают в индустрии программного обеспечения. В первую очередь я писал и продолжаю писать именно для них — дизайнеров, разработчиков и руководителей, которые изобретают и внедряют программное обеспечение.

Предисловие к первому изданию

Аппаратное и программное обеспечение и человеческий фактор в программировании

Хорошее программное обеспечение берет начало не в применении CASE[1] -инструментов, методов визуального программирования, ускоренной разработки программ или объектно-ориентированной технологии. Хорошее программное обеспечение создается людьми. Так же, как и плохое. В 1992 году я начал вести колонку в журнале, исходя из простого принципа: поскольку программное обеспечение создается и применяется людьми, то наилучшее понимание людей — как они работают, каким образом выполняют свою работу, как взаимодействуют между собой — является основой для усовершенствования программного обеспечения и процесса его разработки. Таким образом, основным предметом заметок в этой колонке было не аппаратное (hardware) и не программное (software) обеспечение, а человеческий фактор в программировании (peopleware).

В области, которая изобилует неологизмами, термин «peopleware» — один из немногих, которые действительно стоило выдумать. По-видимому, в печатном издании этот термин первым применил Питер Г. Ньюман (Peter G. Newmann), который, наверное, более всего известен по своим регулярным статьям о риске потребителей и опасностях компьютеров и компьютерных программ для человека. В 1976 году его статья «Peopleware in Systems» была опубликована в книге, получившей свое название от этой статьи. Судя по всему, этот термин придумал Меилир Пейдж-Джонс (Meilir Page-Jones), который использовал его в 1980 году в своей книге «Practical Guide to Structured Systems Design» (Практическое введение в проектирование структурированных систем) — книге, в конце концов сделавшей мою работу по структурному проектированию более понятной для обычного программиста. Но постоянное место в лексиконе нашей отрасли этот термин обрел, скорее всего, после того как в 1987 году под таким заголовком вышла небольшая, но великолепная книга Тома ДеМарко (Tom De-Marco) и Тима Листера (Tim Lister) [33] Таким образом, можно сказать, что названиe[2] для своей колонки, «Peopleware», я позаимствовал из самых лучших источников.

На самом деле «человеческий фактор в программировании» (peopleware) является третьей волной компьютерной революции. Сначала произошел кризис, связанный с аппаратным обеспечением. Одно время мы думали, что наши проблемы возникают из-за аппаратного обеспечения. Нам казалось, что если бы только у нас были более быстрые и мощные компьютеры с большими объемами памяти и более совершенными периферийными устройствами, мы смогли бы создавать более совершенные системы и решать наши задачи. И вот мы получили лучшие компьютеры. Год от года аппаратное обеспечение становилось все быстрее, память — больше, а периферийные устройства — более разнообразными и эргономичными. Однако наши проблемы не исчезли. Мы все еще продолжали создавать системы, трудные для применения. Мы все также опаздывали с завершением своих проектов и превышали запланированный для них бюджет. Поэтому мы решили, что на самом деле проблема состоит в программном обеспечении, после чего линия фронта в компьютерной революции переместилась к рубежу, который многие стали называть «кризисом программного обеспечения». Если бы только у нас были более совершенные инструменты, языки более высокого уровня, более мощные библиотеки компонентов и программы для создания программ, мы смогли бы решать наши задачи и создавать хорошие системы вовремя и в пределах бюджета. Языки третьего поколения стали еще более сложными и породили языки четвертого поколения (4GL). Компиляторы становились все быстрее и эффективнее. Библиотеки компонентов многократного использования расширялись, редакторы стали контекстно-зависимыми, а разнообразные инструменты автоматизированной разработки программного обеспечения появлялись, как грибы после дождя. Вслед за структурной революцией, давшей нам структурное проектирование и анализ, стало развиваться и набирать популярность объектно-ориентированное направление. Однако графики работ по-прежнему не выполнялись, бюджеты превышались, а количество ошибок в программах упрямо не желало становиться меньше.

В конце концов, подобно Пого и его легендарным друзьям из Окифиноки, на своем опыте мы выяснили, в чем тут дело. Как мудро сказал этот маленький опоссум: «Мы встретили врага — это мы сами». И это действительно так. Все сводится к человеческому фактору в программировании. Мы являемся проблемой, и мы же являемся ее решением. Как удобно.

Человеческий фактор в программировании охватывает довольно широкую область. Сюда входит все, что связано с ролью людей в процессе разработки программного обеспечения и приложений. В заметках и в книге затрагиваются разнообразные темы: качество и продуктивность, работа в команде, динамика поведения коллектива, личность и программирование, руководство проектом и организационные вопросы, разработка интерфейса и взаимодействие между человеком и машиной, познавательная деятельность, психология, процессы мышления.

Все эти предметы интересуют и увлекают меня. Я получил ученую степень по менеджменту отчасти потому, что это позволило мне соединить компьютеры и теорию систем с психологией. Моя диссертация была посвящена психологии программирования на компьютере. В течение нескольких лет я знакомил тысячи студентов и десятки коллег с работами психолога Джорджа Миллера (George Miller) и его магическим числом (конечно, я имею в виду 7±2[3]). Структура схем была тщательно продумана таким образом, чтобы облегчить формирование визуальных понятий и решение задач. Связывание и сцепление, эти устоявшиеся метрики, лежащие в основе структурного проектирования, в действительности имеют отношение к восприятию людьми компьютерных программ. Сложными или простыми программы делает именно то, что кажется простым или сложным для программистов, которые эти программы пишут, сопровождают и модифицируют.

В известном смысле я могу избегать тему человека не больше, чем тему компьютеров. Казалось, мне удалось уйти от этих вопросов, когда в июле 1976 года я попрощался с компьютерной областью и объявил о своей независимости (Америка как раз отмечала двухсотлетие своего суверенитета). Будучи по образованию семейным врачом, я больше десяти лет потратил на частную практику и работу в медицинской организации, помогая супружеским парам, семьям или просто больным людям. Но силам вселенной было угодно снова вернуть меня в пределы технологии.

Человеческий фактор является перекрестком в этих пределах, пересечением, где сходятся магистрали из моих разных миров. Управление, организационное развитие, личность, моделирование, инструменты, методы, процессы, взаимодействие между компьютером и человеком и т. д. Во всех этих областях в то или иное время я либо писал, либо работал, либо преподавал. Колонка в журнале дала мне повод еще раз окинуть взглядом панораму отрасли. Подобно Чарльзу Куралту (Charles Kuralt), я мог останавливаться для исследования интересной идеи, решать возникавшие задачи и проходить по главным дорогам и магистралям в области разработки программного обеспечения и приложений.

Эта книга является сборником путевых заметок, начатых еще в Computer Language Magazine и продолженных в переименованном Software Development. Мои заметки выходили под рубрикой с простым названием «Peopleware». В этой книге собраны заметки из этой колонки, а также несколько других, тесно связанных с этой темой и опубликованных в других местах. Эти статьи и эссе были отредактированы в интересах последовательности изложения. Восстановлены некоторые материалы, которые были сокращены при публикации статей в журналах. Таким образом, данная подборка является «редакцией режиссера», в которой статьи размещены в квазилогических разделах, чтобы создать определенную иллюзию организации материала. Однако это не энциклопедия или учебник, и даже не карта огромной территории под названием «человеческий фактор в программировании», а только путевой журнал одного странника.

Путешествие продолжается.

I

Групповая разработка

1

Решения, решения

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

Я всегда считал, что способность принимать решения является одним из самых важных жизненных навыков. Этому можно научиться только опытным путем. Семьи и компании, достигшие успеха, стараются обеспечить достаточные возможности для такого рода практики. К середине карьеры типичный профессиональный программист уже решил бесчисленное множество задач и, вероятно, принял не одну тысячу решений. Естественно, от профессионалов мы вправе ожидать, что как раз в этом они обладают хорошими способностями. Однако большинство таких решений программист принимает самостоятельно, тогда как принятие решений и преодоление трудностей в группе — дело совсем другое.

Опасность посредственности

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

Согласно исследованиям, коллективные решения зачастую сводились к более рискованным вариантам по сравнению с теми, которые сотрудники группы могли бы принять самостоятельно. Если применить эту модель к программированию, то можно было бы ожидать, что группы будут создавать программы, использующие экзотические структуры данных, или необычные алгоритмы, или неявные возможности языка. Однако другие исследования групповой динамики показали, что при выполнении задач и принятии решений в группах имеет место эффект нивелирования, который сводит результаты к своего рода наименьшему общему знаменателю индивидуальных способностей и вкладов. Казалось, что один человек принимает более верные решения…

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

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

Слегка управляя

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

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

Большинство лидеров проектов и руководителей среднего звена в сфере разработки программного обеспечения являются довольно сильными специалистами. Почти каждый из них поднялся из отделов программирования, системного анализа и проектирования. Они достигли своего положения потому, что разбираются в вопросах разработки программ. Многим из них трудно оставить клавиатуру и позволить кому-либо другому выполнять эту работу и решать технические вопросы.

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

Такой лидер является другом для каждого и, в то же время, не является чьим-то адвокатом. Такой лидер стремится получить вклад от всех участников группы, никого из них не выделяя. Такой лидер помогает группе прийти к техническому консенсусу, но не оказывает влияния на исход обсуждения и не навязывает свой вариант решения.

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

Некоторые руководители избирают подход полного невмешательства и стараются совсем не вдаваться в технические вопросы. Однако это не является полезным ни для команд, которые остаются без опыта и мастерства своих руководителей, ни для самих руководителей, которые упускают много интересного. Лучшие из них передадут ведение собраний или обсуждений нейтральному ассистенту, а сами, оставаясь в заднем ряду, станут учиться тому, как участвовать в работе, не доминируя. Некоторые так никогда и не смогут научиться этому, но многие из тех, с кем мне довелось работать, действительно получают удовольствие от того, что они снова могут быть «в одной связке» и на равных со всеми обсуждать технические вопросы.

Жизнь продолжается. Даже после того, как вас повысили в должности. Из журнала Computer Language Magazine, том 9, № 3, март 1992 г.

2

Консенсус и компромисс

Возможность получить максимальную отдачу от команды, разрабатывающей программное обеспечение, зависит от способности профессионалов, вовлеченных в проект, приходить к техническому консенсусу. Но почему же так важно, согласны ли вы и ваш коллега в том, как должна выглядеть форма для заполнения или как следует выдавать сообщения об ошибках? Технический консенсус не касается того, насколько хорошо вы ладите с собратьями-программистами или насколько вы близки с ними по духу (естественно, нет ничего плохого в том, чтобы ладить между со-бой или хорошо относиться друг к другу). Технический консенсус подра' зумевает максимальное использование способностей и опыта каждого участника команды. Речь идет о создании более совершенного программного обеспечения.

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

Пустой компромисс

Компромисс — это ни то ни се, нечто среднее, зачастую находящееся на полпути в никуда. Рассмотрим классический пример. Ваша команда занимается разработкой графического пользовательского интерфейса. Одна группа настаивает, что кнопки управления следует разместить в нижней части экрана, другая группа считает, что на левой стороне экрана нужно предусмотреть специальную панель. Между этими вертикальным и горизонтальным вариантами есть совершенно реальный компромисс, который может ошарашить: просто разместить эти кнопки по диагонали, проходящей по середине экрана!

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

Синтез — это нечто оригинальное, вбирающее в себя важнейшие черты каждой идеи или предложения. В приведенном выше примере можно легко увидеть вариант творческого синтеза, в котором положение панели с кнопками выбирает сам пользователь. Консенсус, основанный на синтезе, включает в себя лучшее из альтернатив. Более того, такая комбинация обычно привносит новые свойства и возможности. Из синтеза горизонтальной и вертикальной панелей управления может появиться возможность пользовательской настройки. Таким образом, продукт вбирает в себя лучшее из двух идей, а не худшее.

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

Истинно верующие

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

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

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

Важнейшее правило достижения технического компромисса таково: никаких махинаций! Торговля голосами, поддержкой или влиянием — это одна из классических тактик для достижения политического успеха, но она может снизить эффективность технических решений. Например, при разработке интерфейса можно заключить сделку. Я соглашусь с вашей глупой идеей поместить панель с кнопками внизу экрана, если вы согласитесь с моим отличным предложением сделать пиктограммы без надписей. В результате мы получаем интерфейс, качество которого оставляет желать лучшего уже по двум признакам. Махинации — это тот же компромисс, только в другом, еще худшем виде, поскольку в этом случае одни решения портят другие. Для достижения настоящего согласия каждый технический вопрос должен рассматриваться отдельно, по существу, а не как часть некоторой системы подсчета очков, в которой уступки в одной области можно выторговать упрямством в другой.

Только факты

Принято считать, что технические решения принимаются в ходе обсуждения технических материй — фактов, количественных оценок, практического опыта. Правда же состоит в том, что чувства, мнения, интуиция и обыкновенные человеческие пристрастия играют роль во всех процессах принятия решений и преодоления трудностей. Это вполне объяснимо, поскольку люди остаются людьми. И хотя некоторые люди пытаются отрицать, сдерживать или подавлять такие иррациональные проявления, это никогда не удается в полной мере.

Важнейшим умением для любой команды, надеющейся достичь технического консенсуса, является умение отделять факты от мнений. Если группе необходимо найти наилучшие варианты и подойти к решению задач творчески, то для этого сотрудники группы должны получить доступ к самым надежным данным и понимать, какого рода информация у них есть. Сами по себе мнения не являются плохими, и члены команды должны иметь возможность свободно их выражать. Мнения могут быть даже полезными, особенно когда они подкреплены ценным опытом, но их нельзя смешивать с фактами, данными или анализом. К слову сказать, факты тоже имеют свои ограничения. В области эстетики или рыночной привлекательности фактов может недоставать. К сожалению, некоторые сотрудники рабочей группы, однажды придя к какому-то решению, перестают обращать внимание на факты.

Ничто не может стать фактом просто потому, что вы это так назвали. Поэтому группам следует учиться пресекать пустословие и договориться не злоупотреблять средствами языка. В первые годы нашей совместной жизни моя первая жена научилась с подозрением относиться к любым утверждениям, которые я начинал с фразы наподобие: «Факты ясно свидетельствуют, что…». Это было сигналом, что далее, вероятно, последует глубоко личное мнение, не подкрепленное ни данными, ни доказательствами. После того как этот гамбит перестал действовать, за мной стали иногда замечать приверженность к другой тактике, которую мы назвали ходом «95 % всех ученых». Некоторые из вас, наверное, поняли, о чем идет речь. «Вы знаете, этот метод предпочитает большинство, уж точно более 95 % профессиональных программистов-разработчиков». Естественно, для того чтобы продолжать пользоваться этой уловкой, вам нужно варьировать проценты. «Почти 78 % пользователей WordPerfect знают, что лучшим способом является…» или «Если провести опрос, то более двух третей программистов, пишущих на С, согласятся, что…». Иногда кажется, что стоит только присмотреться, как увидишь легионы ученых, программистов-разработчиков или конечных пользователей, выстроившихся в ряд позади говорящего, чтобы лично поддержать его (или ее) точку зрения.

Но это только мое мнение.

Из журнала Computer Language Magazine, том 9, № 4, апрель 1992 г.

Достижение консенсуса

Консенсуса нельзя достичь до тех пор, пока вы сами не признаете его наличие. Это значит, что в группах по разработке программного обеспечения, стремящихся к коллективным решениям, разумно заранее договориться о критериях, относительно которых будут решаться технические вопросы. Что является важным? Что имеет значение? Что «хорошо», а что «плохо» в рамках данного проекта?

Часто, когда какая-нибудь группа застревает, проводя анализ или принимая проектное решение, а участники группы говорят: «Мы не знаем, как поступить», я спрашиваю их: «Как вы определяете, какой подход лучше?». Инжиниринг связан с поиском компромиссов — согласия на уступки в одном в обмен на уступки в другом. В любом проекте компромисс требует понимания ценности того, что приобретается или теряется при взаимных уступках.

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

Непосредственные приоритеты

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

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

Спор и диалог

Отсутствие ясности или согласия по поводу критериев — это не единственное, что может затруднить достижение технического консенсуса. Свободное обсуждение — это не только основа командных усилий по достижению согласия. Такое обсуждение интересно и само по себе. Однако будучи интенсивным, оно может перейти в злопыхательский спор. Ни зал суда, ни политическая трибуна не подходят для командной работы, основанной на достижении согласия. Как бы ни зарекомендовал себя состязательный подход в судебной системе, важно, чтобы группы по разработке и проектированию не разбились на противоборствующие сообщества.

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

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

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

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

Когда людям, отстаивающим свои позиции, не удается найти общий язык, поможет такой метод. Стороны меняются ролями и начинают защищать позиции, предложенные другими. Или же активным спорщикам можно поручить защиту технически интересных, но слабо отстаиваемых идей. «Послушай, Мэвис, твоя идея хороша, но сможешь ли ты убедить нас, что в идее Грега есть преимущества?» Еще один прием — предложить следующее: «Давайте применим те же аргументы в рассмотрении другого предложения».

К техническому консенсусу лучше приходить в диалоге и переговорах, чем в споре и препирательствах. Очень полезными могут быть сведения о переговорах, почерпнутые в других областях. Прежде всего, следует порекомендовать две великолепные книги, изданные в рамках «гарвардской программы по ведению переговоров»: Фишер (Fisher) и Юри (Ury) «Getting to Yes» (Как добиться согласия), 1981 [37] и Фишер и Браун (Brown) «Getting Together» (Как добиться единства), 1988 [38].

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

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

Собирая все вместе

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

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

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

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

Из журнала Computer Language Magazine, том 9, № 5, май 1992 г.

4

Скромный и высокопоставленный писарь

Помните, как Боб Крэтчит (Bob Cratchit) трудился над книгами в солидной фирме Скруджа (Scrooge) и Марли (Marley), надев на руки перчатки без пальцев, чтобы они не замерзали, пока Боб перелистывал страницы? Я очень люблю «Рождественский гимн» (A Christmas Carol). Недавно мне подарили видеокассету с изумительной черно-белой экранизацией, где главную роль играет Алистэр Сим (Alistair Sim). Посмотрев этот фильм, я задумался о старом Бобе и других «клерках», которые на протяжении столетий вели учетные книги для множества предприятий. Эти писари были настоящими компьютерами своего времени. Без них предприятия пришли бы к банкротству, а целые отрасли были бы ввергнуты в хаос. Их реальная власть и влияние намного превосходили их скудные жалования или невысокий статус. Вообще говоря, продолжительный успех Скруджа и Марли был в большей мере связан с работой старого доброго Боба и его соотечественников, чем с тем, что привнес Эбенезер.

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

Если группы по разработке программного обеспечения ведут какие-то записи, то в архивах и заметках отражаются только результаты и выводы, рабочие продукты или готовые компоненты. Программисты особенно не любят записывать что-нибудь кроме самого кода, если только перед ними не стоит угроза штрафа или тюремного заключения. Заставить их нари-совать диаграммы — это все равно, что заставить слона сделать наброски карандашом. В конце концов, разве не является хороший код самодокументируемым?

Жизненно важная статистика

Такое отношение приводит к потере жизненно важной информации. Вообще говоря, когда сохраняется только конечный продукт, нам известен результат, но мы не знаем, как его получили. Как создавалось программное обеспечение, какие решения были найдены в процессе работы — все это является важным. Можем ли мы полагаться на свою память? Беспокоимся ли мы только об ошибках или вдобавок хотим извлечь из них пользу?

Особые трудности в работе групп, сохраняющих только конечный программный продукт, вызывает отсутствие записей о решениях, от которых отказались. Знать о том, какие методы были отклонены и по каким причинам, часто бывает так же важно, как и о том, какие методы были выбраны. Это жизненно важно в тех случаях, когда готовятся новые версии или системы или когда разработка текущей системы заходит в тупик.

Наверное, вы когда-нибудь рассматривали свой код, написанный несколько месяцев или лет назад. Случалось ли так, что вы находили такие места, которые казались неверными, и вы удивлялись, как же программа вообще могла работать? Если вы поддавались соблазну «исправить» эту скрытую ошибку, как это иногда делал и я, то могли обнаружить, что «исправление» загоняло систему «в угол». Естественно, код только казался неправильным, но сам по себе он не объяснял, почему здесь все в порядке. Не помогут и такие комментарии в коде: «Ничего здесь не меняйте. Это место кажется неверным, но здесь все правильно». Если программист знал, что «здесь все правильно» и почему другой вариант будет неверным, то почему же тогда эта логика не отражена в комментарии? Если мы хотим поддерживать систему не один год или иметь возможность выпустить следующую версию через пять лет после того, как все разработчики первой версии системы будут далеко, нам нужно знать, какие варианты рассматривались, какие были отклонены и почему.

Сегодня бизнес-консультанты говорят об организационном обучении как о ключе к долговременному успеху предприятия. Организации, как и люди, могут учиться на своем опыте, накапливая знания и улучшая свою производительность. Если в организационное обучение вовлечены только отдельные сотрудники, то такая организация становится уязвимой. Работники болеют, уходят в отпуск, меняют работу. В конце концов, они забывают.

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

Каракули

Входит скромный писарь. Звучат фанфары и приветствия!

В команде, разрабатывающей программное обеспечение, писарь или протоколист отвечает за коллективную память команды, в которой хранятся как рабочие продукты, так и описание процессов, давших результаты. Писарь ведет учетные книги. В модели командной работы с открытой структурой (Structured Open teamwork), которую независимо друг от друга разработали Роб Томсет (Rob Thomsett, 1990 [62]) и я (Constantine, 1989 [11], 1991 [13]), такая роль была обозначена как «информационный менеджер». Этот термин был введен для того, чтобы повысить статус этой роли, подобно тому как в объявлениях о вакансиях вместо «водитель мусоровоза» пишут «инженер санитарно-гигиенического транспорта».

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

Хорошая групповая память должна вмещать много информации. Одна часть этой памяти является непостоянной или временной памятью, другая часть — постоянной. Часть групповой памяти является активной и может оперативно использоваться в обсуждениях и решении повседневных задач. К другой части памяти команда обращается реже. Для удобства функции управления информацией можно разделить на функции сессионной памяти и функции проектной памяти. Сессионная память состоит из записей, созданных и задействованных во время групповых сессий, когда участники команды встречаются и вырабатывают групповые решения. В проектной памяти хранятся постоянные записи и документация, написанная и применяемая группой. Она включает в себя рабочий продукт, под которым понимается не только код, но и все проектные и анали-тЕческие модели и документы, созданные при написании кода. Кроме того, в проектной памяти хранятся входные данные, такие как требования, спецификации и другие основополагающие документы. Для управления проектной памятью нужен библиотекарь, и часто эта роль известна именно под этим названием.

Модульная память

Важнейшая функция сессионной памяти — хранение отчета о процессах, который отражает проведенные обсуждения и решения, принятые в группе (Дойл (Doyle) и Страус (Strauss), 1982 [35]). Наверное, идея о ведении записей в ходе процесса нова для большинства групп, разрабатывающих программное обеспечение, однако на различных собраниях это практиковалось десятилетиями. Ведя записи, начинающие писари часто допускают одну из двух ошибок. Они либо пытаются записывать все подряд, словно под диктовку, либо ждут, пока группа не придет к какому-то заключению, и просто записывают итог. Для технической работы, выполняемой командой, записи вида «он(а) сказа л (а)» не особенно подходят и не являются необходимыми. В хорошем протоколе отмечены ключевые события на пути к конечному результату, особенно рассмотренные альтернативы, принятые решения и представленные аргументы. Такие записи вносят наибольший вклад в групповое приобретение опыта. Они могут стать бесценными, когда необходимо оценить проект или когда проект вступает в фазу «post mortem».[4]