Мифический человеко-месяц

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

9.7 На всем протяжении реализации системные архитекторы должны постоянно проявлять бдительность с целью непрерывного обеспечения целостности системы.

9.8 Воспитание общесистемного и ориентированного на пользователя подхода является, возможно, главной задачей менеджера по программированию.

9.9 Нужно уже на ранних этапах определить, насколько детализированным будет предоставляемый пользователю выбор опций, поскольку объединение опций в группы сберегает память (а часто и расходы на маркетинг).

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

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

9.12 У программирования есть технология, и каждый проект нуждается в библиотеке стандартных компонентов.

9.13 Библиотеки программ должны иметь по две версии каждого компонента — быструю и компактную. (Похоже, что сегодня это устарело.)

9.14 Компактные и быстрые программы почти всегда являются результатом стратегического прорыва, а не тактической грамотности.

9.15 Таким прорывом часто является новый алгоритм.

9.16 Еще чаще прорыв происходит благодаря изменению представления данных или таблиц. Представление — сущность программирования.

Глава 10. Документарная гипотеза

10.1 Гипотеза: Среди моря бумаг несколько документов становятся критически важными осями, вокруг которых вращается все управление проектом. Они являются главными личными инструментами менеджера.

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

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

10.4 Для программного проекта требования те же: цели, руководство пользователя, внутренняя документация, график, бюджет, организационная структура и план помещений.

10.5 Поэтому даже для самого маленького проекта менеджер с самого начала должен формализовать такой набор документов.

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

10.7 Сопровождение каждого важного документа требует наличия механизма слежения за состоянием и предупреждения.

10.8 Каждый документ в отдельности служит контрольным списком и базой данных.

10.9 Важнейшая задача менеджера — обеспечить общее движение в одном направлении.

10.10 Главная постоянная задача менеджера — общение, а не принятие решений; документы информируют всю команду о планах и решениях.

10.11 Только маленькая часть, возможно, 20 процентов, рабочего времени администратора занята задачами, которые требуют сведений, отсутствующих в его памяти.

10.12 По этой причине модная идея «всеохватывающей информационной системы для управления», обеспечивающей поддержку руководителя, основывается на неверной модели поведения руководителя.

Глава 11. Планируйте на выброс

11.1 Инженеры-химики выяснили, что осуществленный в лаборатории процесс нельзя одним махом перенести в заводские условия, но необходимо построить опытный завод, чтобы получить опыт наращивания количеств веществ и функционирования в незащищенных средах.

11.2 Этот промежуточный шаг в равной мере необходим для программных продуктов, но для инженеров-программистов пока не стало обычной практикой проводить полевые испытания опытной системы, прежде чем начинать поставки готового продукта. (Сейчас это уже стало общей практикой благодаря выпуску бета-версий. Это не то же самое, что макет с ограниченной функциональностью, альфа-версия, которую я также пропагандирую.)

11.3 Для большинства проектов первую построенную версию едва можно использовать: слишком медленная, слишком большая, слишком сложная в применении, или все это вместе.

11.4 Отбросить и перепроектировать можно все сразу, а можно по частям, но все равно это придется сделать.