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

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

По материалу из журнала American Programmer, июль 1993 г.

III Организация работы

11 Традиционная тактика

Ок, ребята, теперь давайте организовываться! Вопрос только — как? Работая самостоятельно, вы можете работать как угодно. Вам не нужно координировать свою работу с тем, что делают другие, и вам не придется подлаживаться к кому-либо. Вы можете в навязчиво-маниакальной манере аккуратно класть все вещи на свои места и в точности выполнять инструкции в соответствии с моделью жизненного цикла, принятой в разработке стандартного программного обеспечения. Или вы можете оставить все разбросанным по всему офису в полном беспорядке и кодировать по вдохновению или просто когда вздумается. Однако если вместе работают два человека или более, то ключевым словом здесь является слово «вместе». Работа, которую они выполняют, и способ ее выполнения требуют координации.

В этой главе начинается исследование вопросов организации и управления работой людей: как работа организована и как люди, работающие вместе, координируют свои действия (Constantine, 1990 [12], 1991 [15], 1003 [21]). Рассмотрим организацию как человеческий эквивалент архитектуры программного обеспечения, соотнося руководство с динамическим управлением программными компонентами. И снова мы придем к знакомым понятиям структуры и динамики систем управления. Когда вы хотите организовать новую компанию по разработке программного обеспечения или очередной программный проект, возникают все те же вопросы и проблемы.

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

Какой способ является правильным? Самое время вспомнить один из стандартных «ответов консультантов»: «Это как посмотреть!» Поиск правильного способа организации проекта похож на поиск правильного способа кодирования подпрограммы. Нужно исходить из того, что вы собираетесь получить в результате (Constantine, 1993 [21]).

Обычная работа по созданию еще одного набора драйверов для принтера или еще одного варианта традиционного генератора растровой развертки может потребовать совсем иной модели организации и руководства, чем работа над новейшим CASE-инструментом, поддерживающим процесс параллельного проектирования программного обеспечения и проектирование объектно-ориентированного ПО на основе консенсуса. В своей небольшой, но превосходной книге, посвященной командной работе, Jlap-сон и ЛаФасто (Larson и LaFasto, 1989 [47]) определили несколько основных вариантов такой работы, каждый из которых имеет свои преимущества. Здесь мы рассмотрим четыре отдельных и очень различных модели организации командной работы, их преимущества и недостатки.

Создание организации

Итак, давайте организовываться! Самый простой и надежный вариант основан на проверенной временем стандартной процедуре. Координирование работы более чем одного человека заключается в наделении кого-ли-бо полномочиями руководителя. Функция руководителя состоит в том, чтобы управлять и следить за работой других. Эта структура может быть расширена с помощью рекурсии. В результате появится иерархия руководителей, где высшие чины руководят низшими. Это простая, устойчивая и знакомая всем форма организации: традиционная пирамида, основанная на иерархии власти. В проектах по разработке программного обеспечения, ведущихся согласно этой модели, в иерархии может не быть много уровней, но это все равно иерархия. В принципе, такая структура может быть очень эффективной, однако на практике она может разрастись до огромной бюрократической машины, не способной ни к чему, кроме сохранения собственной бюрократической неэффективности.

Такая модель является не просто способом работы. Она может быть образом жизни. Недавно я занимался реорганизацией своей коллекции записей, чтобы освободить место для новых компакт-дисков, и обнаружил настоящее сокровище — старинную запись «Paean» из корпоративного альбома компании IBM.[17] Слушая, как Ассоциация британских секретарей в Америке (на самом деле!) энергично исполняет «Песню деревенского клуба IBM», я стал думать о корпоративной культуре и о том, как способ нашей работы определяет наше видение мира, и наоборот.