Организация коллектива разработчиков
Помните историю из Библии о Вавилонской башне? Адам и Ева вкусили запретный плод, в результате чего люди стали быстро размножаться, и говорили они, очевидно, на одном языке. Дела у людей шли хорошо, но возгордились они сверх всякой меры и чтобы доказать Богу, что они его не боятся, решили построить башню до самого неба. Бог с ними разобрался очень быстро – взял и смешал разные языки, люди потеряли возможность общаться, а, значит, управляемость, в результате амбициозный проект так и не был завершен.
Проблема интерфейсов – главная проблема в организации коллектива. Если есть n сотрудников, то имеется Cn2 = n*(n-1)/2 парных интерфейсов, а ведь иногда надо обсудить проблему и втроем, и вчетвером. Таким образом, с ростом коллектива быстро растет количество интерфейсов внутри него, при каждом взаимодействии могут возникнуть споры, непонимание, разночтение и другие конфликты. Как же с этим бороться?
Понятно, что ставить перед собой задачу абсолютного решения этой проблемы не стоит, но какие–то пути решения я покажу. А уж дальше можно надеяться только на личный опыт руководства коллективами.
Основная идея состоит в построении иерархии подчиненности. Есть руководитель темы или отдела, у него в подчинении несколько руководителей групп, у каждого руководителя группы в подчинении несколько специалистов. Разумеется, уровней иерархии может быть и 2, и 3, и 4, но все-таки не 15 и не 20. Каждый руководитель должен сформулировать задачу своим подчиненным так, чтобы минимизировать интерфейсы между ними, т.е. максимально локализовать решаемые ими задачи. Это не всегда возможно, не у всех руководителей получается, но так и различаются руководители и их команды.
В незапамятные времена многие верили в закон Конвея: "Каждая система структурно подобна коллективу, ее разработавшему". В 1976 году мне пришлось довольно долго беседовать с руководителем разработки трансляторов с языка ПЛ1 для IBM/360 по фамилии Маркс. Родился он в тот же год, что и я, закончил университет тогда же, когда и я, занимался очень похожей работой (в то время я был одним из руководителей разработки транслятора с языка Алгол 68), в общем, нам было интересно побеседовать.
Я его спросил: "Почему РL1/ F имеет 51 просмотр, когда с Алголом 68 мы справляемся за 6?". Он отвечает: "А что тут понимать, у меня в подчинении был 51 программист. К тому времени, когда мы начали реализовывать оптимизирующий транслятор с ПЛ1, у меня было 100 человек, поэтому PL1/ opt имеет 100 просмотров". Я и тогда понимал, что это глупо. Между каждой парой просмотров нужно организовывать файл на промежуточном языке; один просмотр – пишет, другой – читает, добавьте разные упаковки и распаковки, другие служебные действия – и вы поймете, почему трансляторы с ПЛ1 работали так медленно.
Но не все так просто в этом мире. Мы делали транслятор чуть ли не 10 лет, а они "слепили" свой транслятор за два года. Тот же Маркс позавидовал мне, что у нас есть такая замечательная возможность заниматься любимой наукой, не торопясь, исследовать разные варианты, придумывать новые методы, публиковать монографии и т.д. C понятием рынка ПО в те годы мы были совершенно не знакомы, да и сейчас, через 30 лет, далеко не все наши программисты понимают законы рынка: как важно первым выдать на рынок пусть не самый лучший, но работающий продукт, соответствующий определенным потребностям рынка. Таким образом, если вы проектируете систему в соответствии с законом Конвея и при этом вам легче уложиться в сроки и средства, значит, так и нужно, а всякие изыски оставьте университетским "яйцеголовым" (так в Америке обзывают нас и наших коллег из университетов всего мира).
Cо временем закон Конвея, который был сформулирован его автором только в качестве шутки, был обобщен до довольно конструктивного метода – матричного. К чему подталкивает закон Конвея? Каждый специалист выполняет только свой небольшой кусок работы, но делает это всегда, для всех заказов такого же типа, набивает руку, почти не думает, совершает мало ошибок, т.е. процесс превращается в производственный.
Итак, пусть у нас есть n специалистов и m однотипных заказов. Строим матрицу из n строк и m столбцов.
Элемент в i-ой строке из j-ого столбца обозначает работу i-ого специалиста для j- ого заказа. Например, один специалист хорошо делает синтаксические анализаторы, другой – оптимизаторы, третий – генераторы и т.д., а однотипные заказы – это трансляторы с разных языков для разных платформ. Тем самым каждый специалист подчинен двум руководителям – административному (он же принадлежит какой-то группе, отделу) и руководителю проекта, в котором он принимает участие в данный момент.
У матричного метода есть свои плюсы и минусы. С одной стороны, узкая специализация по конкретной теме позволяет надежнее планировать сроки, добиться той самой повторяемости результатов, которой требует CММ уровня 2. С другой стороны, нарушен принцип единоначалия (как когда-то в Красной Армии были командиры и комиссары, причем с одинаковыми правами и ответственностью; жизнь быстро доказала неправильность такого решения). Часто возникает ситуация, когда руководителю проекта нужен какой-то конкретный специалист, а начальник отдела загрузил его работой для другого заказа.
Есть и еще один недостаток матричного метода, не столь очевидный. Конечно, занимаясь годами одним и тем же, специалист оттачивает свое мастерство, но в целом он ограничен, не расширяет свой кругозор и т.п. "Специалист подобен флюсу – полнота его односторонняя". Предположим, некий сотрудник института много лет успешно занимался темой Х, а по прошествии какого-то времени тема Х перестала быть актуальной (такое в нашей науке бывает очень часто). И что он будет делать?
У Брукса описана совершенно другая модель организации коллектива – бригада главного хирурга. Сложные операции всегда делает один человек – главный хирург, но ему помогает целая бригада – кто-то делает надрезы, а потом зашивает, кто-то подает инструменты, следит за показаниями приборов и т.д. Примерно такой же схемой воспользовались Миллз и его коллеги для разработки информационной системы газеты "Нью-Йорк Таймс".
Все программы, документацию, основные тесты пишет один человек – главный программист.
У него есть заместитель, который участвует в проектировании, обсуждениях, критикует решения главного программиста, но ни за что не отвечает. В случае болезни или по какой-то другой важной причине заместитель может заменить главного программиста.
В бригаде есть тестер, секретарь, библиотекарь, продюсер с вполне понятными функциями. Возможно подключение еще каких-то узких специалистов. Оказалось, что такая бригада может работать в 3-5 раз быстрее традиционных команд программистов, поскольку не нужно тратить время на согласование деталей интерфейсов с другими программистами, изделие получается цельным и "элегантным", выполненным в одном стиле. Главный программист выбирается из числа наиболее опытных и высококвалифицированных, он может себе позволить сосредоточиться на основной задаче и не тратить время на всякие "бытовые" функции, которыми полна наша повседневная жизнь.
Эта модель организации коллектива не нашла широкого применения. Во-первых, ее трудно масштабировать. Сколько строк исходного кода может написать один программист? Ну, 50 тысяч, ну, скажем, 100. А если нужно миллион строк? Тогда все проблемы интерфейсов возвращаются, да еще на более сложном уровне, поскольку двум главным программистам договориться гораздо труднее, чем двум рядовым. Во-вторых (или все-таки во-первых?), где вы найдете множество программистов, готовых безропотно подчиняться главному программисту? Наша специальность подразумевает наличие твердого характера, творческого начала, гордости за свое детище.
