Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы

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

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

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

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

Д. Л. Пранас и Университета Карнеги-Мелона предложил еще более радикальное решение. [1] Он полагает, что производительность программиста выше всего, когда он огражден от подробностей конструкции тех частей системы, над которыми он не работает. Это предполагает, что все интерфейсы полностью и точно заданы. Такой проект определенно хорош, но если полагаться на его идеальное осуществление, это приведет к катастрофе. Хорошая информационная система не только должна выявлять ошибки в интерфейсах, но и способствовать их исправлению.

Организация крупного программного проекта

Если над проектом работает n человек, то существует (n [2] –n)/2 интерфейсов, через которые может происходить обмен данными, и потенциально существует почти 2 n групп, внутри которых должно происходить согласование. Цель организации работы состоит в сокращении необходимого объема обмена информацией и согласования. Поэтому создание правильной организационной структуры является решающим направлением решения проблем информационного обмена, рассматривавшихся выше.

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

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

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

1 — задание,

2 — продюсер,

3 — технический директор или архитектор,

4 — график работ,

5 — разделение труда,

6 — определение интерфейсов между разными частями.

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

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

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

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

Возможны три типа отношений, и все они с успехом встречаются на практике.

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

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

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