— Прошу прощения, — сказал он, краснея, — я, наверное, задремал.
— Для этого я притащил тебе диван, — сказал Гарриман, — на нём удобнее. Боб, познакомься с Джоком Беркли. Это твой новый раб. Ты остаёшься главным инженером и неоспоримым начальником. Джок будет Главным лордом Всё Остальное. С этого момента тебе абсолютно не о чём беспокоиться — исключая такую мелочь, как лунный корабль.
Они пожали руки.
— Хочу просить об одной вещи, мистер Костёр, — сказал Беркли с серьёзностью, — передавайте мне все, что сочтёте необходимым — ваша сторона техническая, — но Бога ради, записывайте все, чтобы я был в курсе. Я хочу, чтобы вам на стол поставили выключатель, который будет управлять опечатанным магнитофоном на моём столе.
— Отлично! — Гарриману показалось, что Костёр помолодел.
— И если вам понадобится что-либо, не относящееся к технике, не занимайтесь этим сами. Нажмите выключатель и свистните. Всё будет сделано. — Беркли взглянул на Гарримана. — Хозяин говорит, что собирается поговорить с вами о настоящей работе. Я вас покину и займусь делами. — Он вышел.
Гарриман сел. Костёр последовал его примеру и сказал:
— Уф!
— Так лучше?
— Мне понравился этот Беркли.
— Это хорошо. Теперь это твой двойник. Не беспокойся: он работал у меня раньше. Ты почувствуешь себя, как в хорошей больнице. [26]
Этот текст едва ли нуждается в аналитических комментариях. Такая организация тоже может эффективно действовать.
Мне кажется, что последний тип организации лучше подходит для небольших команд, описанных в главе 3 «Операционная бригада». Полагаю, что продюсер в качестве начальника более подходит для больших поддеревьев действительно крупных проектов.
Вавилонская башня была, возможно, первым инженерным фиаско, но не последним. Решающее значение для успеха имеют схема связи и вытекающая из неё организация. Технологии обмена информацией и создания организационных структур требуют от менеджера большой работы мысли и такой же подкреплённой опытом компетентности, как и сама технология программного обеспечения.
Глава 8
Объявляя удар
Практика — лучший учитель.
ПУБЛИЙ
Опыт — дорогой учитель, но для глупцов иного нет.
АЛЬМАНАХ БЕДНОГО РИЧАРДСА
[26a]
Сколько времени потребует задача системного программирования? Сколько сил понадобится? Как можно это оценить?
Ранее я предложил соотношения, которые можно применять для времени планирования, написания программ, тестирования компонентов и тестирования системы. Во-первых, нужно сказать, чтонельзяделать оценку всей задачи, оценивая только часть, относящуюся к написанию программ, а затем применяя соотношения. Написание программ составляет лишь одну шестую часть задачи или около того, и ошибки при его оценивании или в соотношениях могут привести к смехотворным результатам.
Во-вторых, нужно учитывать, что оценки, полученные при создании отдельных небольших программ, нельзя применять для больших системных продуктов. К примеру, для программы, насчитывающей 3200 слов, Сакман, Эриксон и Грант оценивают суммарное время написания программ и отладки для одного программиста в 178 часов, что экстраполируется до 35800 операторов в год. Вдвое меньшая программа потребовала меньше четверти указанного времени, что при экстраполяции даёт производительность, близкую уже к 80000 операторам в год. [27] Необходимо добавить затраты времени на планирование, составление документации, тестирование, системную интеграцию и обучение. Линейная экстраполяция данных, относящихся к коротким задачам, бессмысленна. Если экстраполировать время, за которое можно пробежать стометровку, то окажется, что можно пробежать милю менее чем за три минуты.
Прежде чем отказаться от этих данных, отметим, что и для не совсем сравнимых задач они показывают, что объём работы растёт как степенная функция размера,дажебез учёта процесса отмена информацией (кроме программиста с собственной памятью).
Показанные на рис. 8.1 данные вызывают грустные чувства. График демонстрирует результаты, полученные в исследовании, проведённом Нанусом (Nanus) и Фарром (Farr) [28] в System Development Corporation. В нём выявляется зависимость с показателем степени 1,5:
Объём работы = (константа) * (количество команд)^1,5.
В другом исследовании, проведённом в этой компании, о котором сообщает Вайнвурм (Weinwurm) [29] , также получен показатель, близкий к 1,5.
Есть несколько исследований относительно производительности труда программиста, в которых предложен ряд технологий оценивания. Есть обзор опубликованных данных, подготовленный Моурином (Morin). [30] Я приведу здесь лишь несколько наиболее показательных результатов.
Рис. 8.1 Затраты на программирование как функция размера программы
Данные Портмана
Чарльз Портман (Charles Portman) [31] , менеджер отдела программирования ICL — Computer Equipment Organization (Northwest) в Манчестере, предлагает своё понимание проблемы, которое может оказаться полезным.
Он обнаружил, что его команды программистов отстают от графиков примерно наполовину, т.е. каждое задание выполняется примерно вдвое дольше, чем предполагалось. При этом оценки очень тщательно проводились группами опытных экспертов, оценивавших в человеко-часах трудоёмкость нескольких сотен подзадач с помощью диаграмм ПЕРТ. Когда выявлялось отставание от графика, он просил вести подробные ежедневные журналы использования времени. Из них выяснилось, что ошибка оценок полностью объясняется тем, что его команды использовали на программирование и отладку лишь 50 процентов рабочего времени. Остальное время терялось из-за отказов машины, на небольшие срочные посторонние задания, совещания, писание бумаг, дела фирмы, болезни, личное время и т.д. Короче оценки исходили из нереалистичного предположения о том, какая часть рабочего времени отводится непосредственно работе. [32]
Данные Арона
Джоэл Арон (Joel Aron), менеджер IBM по системным технологиям в Гейтерсберге, штат Мэриленд, изучал эффективность труда программистов во время работы над девятью крупными системами ( крупнаясоответствует более чем 25 программистам и 30000 операторов). [33] Он классифицирует такие системы в соответствии с интенсивностью взаимодействия между программистами (и частями системы) и обнаруживает следующие величины производительности:
Очень слабое взаимодействие 10000 инструкций на человека в год
Некоторое взаимодействие 5000 «
Существенное взаимодействие 1500 «
Человеко-год здесь не учитывает поддержку и системное тестирование, только разработку и программирование. При введении поправки с коэффициентом два с целью учёта системного тестирования эти цифры близко соответствуют данным Харра.
Данные Харра
Джон Харр (John Harr), менеджер по программированию Electronic Switching System, входящей в состав Bell Telephone Laboratories, сообщил о своём собственном опыте и других известных ему данных в докладе на Объединённой конференции по компьютерам весной 1969 года. [34] Эти данные приведены на рисунках 8.2, 8.3 и 8.4.
Наиболее поучителен и содержит больше данных рисунок 8.2. Первые два задания являются, по преимуществу, управляющими программами, а два вторых — языковыми трансляторами. Производительность измеряется в количестве отлаженных слов за человеко-год. При этом учитывается время программирования, отладки и системного тестирования. Неизвестно, учтены ли затраты на планирование, поддержку машины, составление документации и т.п.
Рис. 8.