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

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

Так обычно и происходит в мире, по крайней мере, в мире разработки программного обеспечения. Ни одна из моделей командной работы, представленных в главах 11–14, не отвечает всем требованиям типичных проектов. Необходима та или иная комбинация этих моделей, подходящая под непростые требования реальности.

Модели управления

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

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

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

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