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

Ознакомительная версия.

1 — задание,

2 — продюсер,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Директор может быть начальником, а продюсер — его правой рукой. Роберт Хайнлайн ярко описывает такую организацию в «Человеке, продавшем Луну».

Костер закрыл лицо руками, затем взглянул вверх:

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

Гарриман очень мягко сказал:

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

Человек показался озадаченным, встал и, подойдя к двери, спросил:

— Да?

— Я хочу, чтобы этот стол в углу и все, что на нем, были перенесены в пустую комнату на этом этаже, и немедленно.

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

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

Часа через три он позвал Баркли, чтобы познакомить его с Костером. Главный инженер спал, сидя за столом, положив голову на руки. Гарриман хотел выйти, но Костер проснулся.

— Прошу прощения, — сказал он, краснея, — я, наверное, задремал.

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

Они пожали руки.

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

— Отлично! — Гарриману показалось, что Костер помолодел.

— И если вам понадобится что-либо, не относящееся к технике, не занимайтесь этим сами. Нажмите выключатель и свистните. Все будет сделано. — Беркли взглянул на Гарримана. — Хозяин говорит, что собирается поговорить с вами о настоящей работе. Я вас покину и займусь делами. — Он вышел.

Гарриман сел. Костер последовал его примеру и сказал:

— Уф!

— Так лучше?

— Мне понравился этот Беркли.

— Это хорошо. Теперь это твой двойник. Не беспокойся: он работал у меня раньше. Ты почувствуешь себя, как в хорошей больнице. [2]

Этот текст едва ли нуждается в аналитических комментариях. Такая организация тоже может эффективно действовать.

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

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

(Бедный Ричард — образ необразованного, но здравомыслящего доморощенного философа, созданный Бенджамином Франклином, издававшим в 1732 — 1757 годах ежегодный альманах и использовавшим этот псевдоним (примеч. перев.)).

Сколько времени потребует задача системного программирования? Сколько сил понадобится? Как можно это оценить?

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

Ознакомительная версия.