Аудит менеджмента Вавилонского проекта
Согласно Книге бытия, Вавилонская башня была вторым крупным инженерным предприятием человека после Ноева ковчега. Вавилонская башня стала первым инженерным фиаско.
Эта история глубока и поучительна в нескольких отношениях. Давайте, однако, рассмотрим ее как чисто технический проект и посмотрим, какие уроки администрирования можно из нее извлечь. Насколько хорошо проект был обеспечен необходимыми составляющими успеха? Имелись ли:
1. Ясность цели? Да, хотя и наивно недостижимой. Проект провалился задолго до того, как столкнулся с эти принципиальным ограничением.
2. Человеческие ресурсы? В большом числе.
3. Материалы? Глина и битум в изобилии имеются в Месопотамии.
4. Достаточно времени? Да, нет никаких указаний на ограничения по времени.
5. Адекватные технологии? Да, пирамидальной или конической структуре присуща устойчивость и хорошее распределение нагрузки сжатия. Очевидно, свойства каменной кладки были хорошо известны. Проект провалился до того, как вышел за пределы технологических ограничений.
Так почему же провалился проект, если все это у них было? Чего у них не хватало? Двух вещей — обмена информацией и вытекающей из него организации. Они не могли разговаривать друг с другом и, как следствие, согласовывать усилия. Когда отказала координация, работа встала. Читая между строк, мы обнаруживаем, что отсутствие обмена информацией привело к спорам, дурному настроению и взаимной ревности. Вскоре кланы начали расходиться, предпочтя обособленность спорам.
Обмен информацией в большом программном проекте
В наше время происходит тоже самое. Отставание от графика, несоответствие функциональности, системные ошибки — все это из-за того, что левая рука не знает, что творит правая. По ходу работы участвующие в ней несколько бригад понемногу изменяют функции, размер, быстродействие своих программ, явно или косвенно меняют допущения относительно входных данных и использования выходных.
Например, исполнитель функции, осуществляющей оверлейную загрузку программ, может столкнуться с проблемами и снизить быстродействие, основываясь на статистических данных, указывающих на редкость использования этой функции в прикладных программах. В то же время его сосед может разрабатывать важную часть супервизора таким образом, что она крайне зависит от скорости выполнения этой функции. Это изменение скорости выполнения, в сущности, становится значительным изменением спецификаций, о нем нужно широко объявить и оценить с точки зрения системы.
Как же должны бригады обмениваться между собой информацией? Всеми возможными способами:
• Неформально. Хорошая телефонная связь и ясное определение взаимозависимостей между бригадами должны способствовать многочисленным телефонным переговорам, от которых зависит единая интерпретация печатных документов.
• Совещания. Нельзя переоценить значение регулярных совещаний участников проекта с поочередным заслушиванием технических отчетов бригад. Таким путем устраняются сотни мелких непониманий.
• Рабочая тетрадь. В самом начале нужно завести рабочую тетрадь учета проделанной работы. Эта тема заслуживает отдельного раздела.