Страница 14 из 28
Очевидно, что продюсер должен признать права директора в принятии технических решений и поддерживать его власть в подавляющем большинстве случаев неизбежной проверки. Это возможно только при условии, если продюсер и директор имеют одинаковые точки зрения на основные технические проблемы. Они должны обсуждать главные вопросы еще до того, как по ним будут приняты решения. И, наконец, продюсер должен с большим уважением относиться к профессиональному мастерству директора.
Менее очевиден тот факт, что продюсер с помощью различных символов статуса (размер кабинета, ковер, мебель и т. д.) может всячески подчеркивать, что директор облечен законодательной властью, хотя формально он и не является руководителем.
Тем самым можно сделать работу очень эффективной. К сожалению, все это практикуется редко. Хуже всего, когда руководители проекта используют в качестве продюсера талантливого специалиста, который не силен в проблемах управления.
Директор может быть начальником, а продюсер - его правой рукой. В книге "Человек, продавший луну", Роберт Хейнлейн выразительно описывает такую организацию.
Костер уронил голову на руки, потом вдруг поднял ее:
"Я в этом разбираюсь. Я знаю, что нужно сделать - но каждый раз, когда я пытаюсь заняться технической проблемой, какой-нибудь идиот требует, чтобы я принял решение насчет грузовиков или телефонов, или другой такой же чертовщины. Простите, мистер Гарриман. Я думал, что смогу справиться со всем этим".
Гарриман сказал очень мягко: "Не принимайте все это так близко к сердцу, Боб! Вы, наверное, не высыпаетесь последнее время? Вот что я вам скажу - мы перехитрим Фергю-сона. Я заберу ваш стол на пару дней и построю вам такую баррикаду, за которой никакие грузовики не страшны. Я хочу. чтобы вы могли спокойно думать о направлении реакции, КПД горячего топлива, об узких местах в проекте и не заботиться о контрактах на грузовики". Гарримап подошел к двери, выглянул в коридор и позвал какого-то человека, по виду напоминавшего старшего клерка. "Эй, Вы! Идите-ка сюда!".
Человек удивленно огляделся, подошел к двери и спросил:
"Да?". "Я хочу, чтобы вот этот стол в углу, и все, что на нем, перенесли в пустой кабинет на этом же этаже, направо по коридору". Он проследил за тем, как стол и вещи Костера перенесли в новый кабинет, позаботился, чтобы там отключили телефон, и, немного подумав, велел принести туда диван. "А вечером поставим проектор, чертежный прибор, шкафы и все остальное",-сказал он Костеру. "Вы только составьте список всего, что вам нужно, чтобы заниматься делом. Если что-нибудь еще потребуется-звоните мне". Он вернулся в кабинет главного инженера и стал размышлять, чего же стоит его организация и что в ней не в порядке?
Часа четыре спустя он пригласил Беркли, чтобы представить его Костеру. Главный инженер спал за столом, положив голову на руки. Гарриман собирался уже уйти, но Костер проснулся. "Простите,- покраснел он,- я, наверное, задремал". "Для этого я и принес вам диван,- сказал Гарриман - на нем удобнее отдыхать. Вот, познакомьтесь с Джеком Беркли. Он ваш новый раб. Вы остаетесь главным инженером и верховным начальником, приказ которого не обсуждается. Джок - это Его Превосходительство Все Что Хотите. Отныне вам абсолютно не о чем беспокоиться - разве, что о такой малости, как создание лунного корабля".
Они пожали друг Другу руки. "Я только об одном вас попрошу, г-н Костер,- сказал Беркли серьезным тоном,- переправляйте ко мне все, что хотите - в конце концов, вам командовать техническим парадом - но, ради бога, записывайте все, чтобы я был в курсе дела. У вас будет кнопка, включающая мой диктофон".
"Отлично"- Костер, как показалось Гарриману, молодел на глазах.
"А если вам понадобится что-нибудь, что не имеет отношения к проблеме, не делайте этого сами. Нажмите на кнопку и свистните - и все будет сделано". Беркли взглянул на Гар-римапа. "Босс говорит, что хочет обсудить с вами настоящее дело. Так что я вас покину". Он вышел.
Гарриман уселся. Костер последовал его примеру и вздохнул: "Уф!".
- Ну как, легче?
- Мне этот парень сразу понравился.
- Ну вот и хорошо, теперь он - ваша тень. Не беспокойтесь, он у меня и раньше работал. Вам покажется, что вы живете в хорошем пансионате2).
Этот отрывок вряд ли нуждается в комментариях. Для эффективной работы такая организация вполне приемлема.
Я считаю, что этот последний метод организации более всего пригоден для маленьких коллективов, таких, как обсуждаются в гл. III "Хирургическая бригада", в то время как продюсер в качестве верховного руководителя - это наиболее приемлемая форма организации для больших поддеревьев действительно крупного проекта.
Вавилонская башня была, возможно, первым инженерным фиаско, но не последним. Установление связи и, как ее следствие, организация наиболее важны для успеха. Методика связи и организации требуют от руководителя столько же способностей и компетенции, как и само создание математического обеспечения.
VIII. ОБЪЯВЛЕНИЕ ЦЕЛИ
"Практика - лучший учитель".
(Публилиус)
"Опыт - хороший учитель, но и он ничему не научит дурака".
(Альманах "Бедный Ричард")
Сколько времени занимает решение задачи системного программирования? Сколько усилий потребуется? И как все это оценивать?
Выше я уже предлагал соотношения для определения затрат времени на проектирование, написание программ, отладку компонент и комплексную отладку. Во-первых, необходимо отметить, что нельзя оценивать задачу в целом, взяв только данные о времени, затрачиваемом на написание программ и распространив их на остальные этапы работы. Написание программ составляет примерно только одну шестую всей задачи, и ошибки в оценке этого этапа или в соотношении его с другими могут привести к смехотворным результатам.
!' Во-вторых, необходимо отметить, что данные, относящиеся к созданию отдельных маленьких программ, не приложимы к комплексному программному продукту. Так, например, Сакмен, Эриксон и Грант приводят среднее время на написание и отладку программы объемом около 3200 слов - 178 часов для одного программиста, что дает производительность в 35 800 команд в год. В два раза меньшая программа требует в четыре раза меньше времени, так что средняя производительность получается равной почти 80 000 команд в год '). Сюда следует, однако, прибавить затраты времени на проектирование, документирование, отладку, объединение в систему, обучение и всякие перерывы. Экстраполяция таких малых цифр не имеет смысла. Так, если экстраполировать время, показываемое бегуном на дистанции в 100 ярдов, то получится, что человек может пробежать милю быстрее, чем за 3 минуты.
Но п'режде чем отбросить эти данные, отметим, однако, что эти числа, хотя и не годятся для строгого сравнения, показывают, что затраты растут квадратично с увеличением объема программы, даже когда нет викакого взаимодействия с другими людьми, если не считать обращения человека к своей памяти.
На рис. 8.1 показаны начальные результаты исследования, проведенного Нанусом и Фарром2) в фирме System Development. Здесь появляется показатель степени 1,5, т. е., затраты -- (константа) X, X (число команд)''5.
В других исследованиях, проведенных этой же фирмой и опубликованных Вайн-вурмом3), также приводится показатель степени, близкий к 1,5.
Производительность программистов неоднократно бы- р", g.l. Программировала предметом изучения, пред- ние как функция разме-лагались различные методы ров программы. ее оценки. Моурин подготовил обзор публикаций4) по этой тематике. Здесь я коснусь только некоторых фактов, представляющих особый интерес.
Данные Портмана
Чарльз Портман, руководитель Северного отделения системного программирования фирмы ICL в Манчестере, высказал другую интересную точку зрения.
Он обнаружил, что его коллективы программистов не укладывались в график почти наполовину - каждая задача занимала в два раза больше времени, чем ей отводилось по плану, несмотря на то, что оценки были очень тщательны (их делали опытные люди, которые определили затраты в человеко-часах для нескольких сотен подзадач с помощью схем PERT). Когда выявилось отставание от графика, Портман попросил своих сотрудников вести подробные ежедневные записи расхода времени. Эти записи показали, что ошибочная оценка полностью объясняется тем фактом, что коллективы тратили только 50% рабочего времени собственно на программирование и отладку. Остальное врем"я уходило на побочные, но срочные дела, совещания, За работу с бумагами, общественные дела, болезни, личные нужды, а также терялось из-за простоев машины. Короче говоря, при составлении графика было сделано нереальное предположение о том, какая часть времени затрачивается непосредственно на работу. Мой собственный опыт полностью подтверждает это заключение.