Читать онлайн «Человеческий фактор в программировании». Страница 20

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

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

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

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

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

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

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

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

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

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

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