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

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

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

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

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

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

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

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

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

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

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

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

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