Мифический человеко-месяц или как создаются программные системы - Брукс Фредерик - Страница 27

• Предыдущая
• 27/58
• Следующая

Но каждому начальнику нужны два вида данных: информация о срывах плана, которая требует вмешательства, и картина состояния дел, чтобы быть в курсе. [3] С этой целью он должен знать положение дел во всех своих командах. Получить правдивую картину нелегко.

В этом месте интересы менеджера низового звена и начальника вступают в противоречие. Менеджер низового звена боится, что если он доложит начальнику о возникшей у него проблеме, тот возьмется за нее сам. Его вмешательство отнимет у менеджера его функции, уменьшит его власть и нарушит другие его планы. Поэтому, пока менеджер считает, что может сам решить проблему, он не докладывает о ней начальнику.

У начальника есть два способа заглянуть под коврик. Использовать нужно оба. Первый — уменьшить конфликт ролей и стимулировать открытие информации. Второй — сдернуть коврик.

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

Напротив, если менеджер знает, что его начальник воспримет отчет без паники или вмешательства, он будет давать честные оценки.

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

Сдергивание коврика. Тем не менее необходимо иметь способ узнать истинное положение дел независимо от наличия стремления к сотрудничеству. Основой такого изучения служит диаграмма ПЕРТ с часто расположенными вехами. В большом проекте можно потребовать еженедельного изучения какой-либо части ее, рассматривая всю диаграмму раз в месяц или около того.

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

В. Высоцкий из Bell Telephone Laboratories добавляет следующее наблюдение:

Для меня оказалось удобным иметь в отчете о состоянии дел две даты — «плановую» и «оцениваемую». Плановые даты принадлежат менеджеру проекта и представляют собой последовательный план работы для проекта в целом, a priori являющийся приемлемым. Оцениваемые даты принадлежат менеджерам низшего звена, в переделах компетенции которых находятся рассматриваемые участки, и представляют их мнения о сроке фактического наступления события при имеющихся у них ресурсах и получении входных данных (или обязательствах об их поставке). Менеджер проекта должен осторожно относиться к оцениваемым датам и стремиться к получению точных, неискаженных оценок, а не утешительно-оптимистичных или перестраховочно-консервативных данных. Если эта позиция утвердится в умах, то менеджер проекта действительно сможет предвидеть, что он попадет в беду, если не предпримет каких-нибудь мер. [4]

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

У нас была умелая, энергичная и дипломатичная группа планирования и контроля, возглавлявшаяся А. М. Пьетрасанта (A. M. Pietrasanta), проявившим значительные изобретательные способности для разработки эффективных, но ненавязчивых методов контроля. В результате его группа пользовалась широким уважением и хорошим отношением. Это немалое достижение для группы, которая по природе своей должна вызывать раздражение.

Выделение небольшого числа подготовленных работников в группу планирования и контроля приносит большую отдачу. Для успешного завершения проекта это значительно лучше, чем если бы они непосредственно занимались разработкой программных продуктов, так как группа планирования и контроля стоит на страже того, чтобы неощутимые задержки стали видимыми, и сигнализирует о критических положениях. Это система раннего обнаружения потери года, происходящей день за днем.

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

Но у написанной программы есть обратная сторона: она должна быть в состоянии рассказать о себе пользователю-человеку. Это требуется даже для программы, написанной исключительно для собственных нужд, поскольку память может изменить автору-пользователю, и ему потребуется освежить детали своего труда.

Насколько же более необходима документация для программы общего пользования, пользователь которой отдален от автора во времени, и в пространстве! Для программного продукта сторона, обращенная к пользователю, столь же важна, как и сторона, обращенная к машине.

Многие из нас бранили далекого безымянного автора за скудно документированную программу. И многие поэтому пытались на всю жизнь привить молодым программистам уважение к документации, преодолевающее лень и пресс графика работ. В целом нам это не удалось. Я думаю, мы использовали неверные методы.

Томас Дж. Уотсон Старший (Thomas J. Watson, Sr.) рассказал мне историю своего первого опыта в качестве продавца кассовых аппаратов в северной части штата Нью-Йорк. Исполненный энтузиазма, он отправился в путь в своем фургоне, нагруженном кассовыми аппаратами. Он прилежно объехал свой участок, но ничего не продал. Обескураженный, он сообщил об этом своему хозяину. Послушав некоторое время, управляющий сказал: «Помоги мне загрузить несколько касс в фургон, запрягай лошадь, и поедем снова.» Так они и сделали, и обходя покупателей одного за другим, старик показывал, как продавать кассовые аппараты. Судя по всему, урок пошел впрок.

Несколько лет я старательно читал группам инженеров-программистов лекции о необходимости и желательности хорошей документации, увещевая их все с большим пылом и красноречием. Это не подействовало. Я предположил, что они поняли, как правильно составлять документацию, но не делали этого по недостатку рвения. Тогда я попробовал погрузить в повозку несколько кассовых аппаратов, т.е. показать им, как делается эта работа. Это имело значительно больший успех. Поэтому оставшаяся часть этого повествования посвящена не столько поучениям, сколько объяснению того, как делать хорошую документацию.

Какая документация требуется?

• Предыдущая
• 27/58
• Следующая