Фредерик Брукс
Американский ученый в области теории вычислительных систем. Автор известного эссе «Серебряной пули нет» и книги «Мифический человеко-месяц». Управлял разработкой OS/360 в IBM. Среди наград Брукса – Премия Тьюринга «за исторически значимый вклад в архитектуру компьютеров, операционные системы и инженерию программного обеспечения». Окончил Университет Дьюка, получил образование в области физики и научную степень по прикладной математике в Гарвардском университете.
О книге
Не очень-то хотелось разбирать книжку, вышедшую так давно, потому что где программирование и пиэм 1975 года и где программирование и пиэм 2017 года. Но раз базовая по профессии, значит надо. Ну и вот выводы-впечатления-важное.
Это сильно профильная книга – там куча старой и сугубо профессиональной информации, формул, исследований и рисунков. Осознанно прочитать все это и отфильтровать полезное смогут только программисты, которые как раз решают, развиваться ли дальше в сторону проджект-менеджмента.
«Мифический человеко-месяц. Как создаются программные системы» obvi посвящена управлению проектами по разработке ПО. То есть, во-первых, для не-программиста только отдельные абзацы и предложения будут представлять набор слов с понятным смыслом. Во-вторых, не-программисту будет недоступно найти точку отсчета и систему координат – элементарно нет знаний, чтобы понять, чему верить, на какие тезисы можно опираться, а что давно отменено технологическим прогрессом.
Поэтому не-программисту целесообразнее и быстрее почитать только последнюю часть, где собраны существенные идеи. И вот там будет реально интересно, независимо от подготовки – к тому же, без сомнений в актуальности. Проджект-менеджеры, которые управляют разработкой софта, – это одна из специализаций, не все пиэмы про код. Тем, кто не про код, а про какие-то другие проекты, будет полезно в смысле логики управления.
Если совсем лонг стори шорт, то вроде как главное в «Мифическом человеко-месяце» с точки зрения проджект-менеджмента – закон Брукса: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Но там еще масса всего интересного, часть идей из книги – списком, что-то цитируем, что-то перефразировали для удобства.
Идеи из книги
Про архитектуру и концептуальную целостность
- Концептуальная целостность – самое важное при проектировании. Будет быстрее разрабатываться и тестироваться. Концепциями должен руководить один. Достичь концептуальной целостности позволяет метафора.
- Идеи – податливый материал, поэтому обычно не учитывают, что ошибки в проекте возникают из-за ошибочности идей.
- Главный архитектор формулирует решения в виде руководства для пользователей. Он действует в интересах пользователя, отвергая даже крутые идеи, если они не вписываются в дизайн. Он должен быть простым.
- Метод Вирта – последовательность уточняющих шагов: набросать описание задачи и грубое решение, потом разбивать этапы и уточнять.
- Ни функциональность, ни простота сами по себе не являются признаками хорошего проекта. Важно соотношение.
- Планируйте перепроектировать первую версию. Придется.
Про командную работу
- Если над проектом работают 200 человек, увольте 175, и пусть менеджеры снова займутся программированием.
- В программировании работа не может быть разделена на независимые части. Некоторыми задачами можно заняться только после завершения других.
- Начиная с какого-то количества, рост числа программистов замедляет проект. Нужно время на обучение.
- Зачастую оптимально, если команда состоит из 2 человек, 1 из них – лидер. Идеал небольшой активной команды – не более 10 человек.
- Данные Сакмана, Гранта и Эриксона: лучшие программисты в 10 раз продуктивнее слабых при равной подготовке и 2-летнем стаже.
- Предложение Харлана Миллза: команды разработчиков должны быть организованы, как бригады хирургов. Врезается в критические задачи один, а остальные оказывают поддержку. С точки зрения функций, нужны: хирург, второй пилот, администратор, редактор, два секретаря, делопроизводитель, инструментальщик, отладчик, языковед.
- Разработчики должны тратить часть времени на взаимодействие, задавать вопросы. Предположения вместо прояснений порождают провал. Уменьшите конфликт ролей и стимулируйте открывать информацию.
- Ответственность за творчество, проявляемое при реализации, несет строитель. На этом этапе архитектор только предлагает.
Про исправление ошибок
- Бетти Кэмпбелл из Лаборатории ядерной физики MIT: когда пользователи выходят на новый уровень применения, выявляются скрытые ошибки. Исправление одной ошибки с вероятностью 20–50% влечет появление новой.
- Планируйте, как будете вносить изменения.
- Скрытый дефект имеет разветвления по всей системе. Хорошо, когда структура простая, ясная и задокументированная, а исправляет ошибки автор.
Экспресс-курс
Управление проектами. Как предотвратить типичные ошибки
Про планирование и сроки
- Люди склонны доверять своему оптимизму или эксплуатировать оптимистические надежды своих спонсоров.
- Как управлять большим проектом по жесткому графику? Иметь график с датами-вехами. Вехи – стопроцентные события.
- Как выглядит ваша мысленная модель календаря?
- 1/3 времени – планирование разработки ПО, 1/6 – написание программ, 1/4 – предварительное тестирование, 1/4 – системное тестирование, когда есть все компоненты.
- Как оказывается, что проект запаздывает на год? Сначала запаздывает на день. Обычно причиной катастрофы служат не смерчи, а термиты.
- В основе планирования обычно лежит ложное допущение, что все будет хорошо и каждая задача займет столько-то времени.
- Хроническое отставание от графика убивает моральный дух.
- Отставание от графика, несоответствие функциональности, системные ошибки – все из-за недостаточной коммуникации.
- Удобно иметь в отчете о состоянии дел 2 даты – «плановую» для менеджера проектов и «оцениваемую» – для менеджеров участков.
- Заниженные оценки существенно не меняются, пока до запланированного окончания работ не остается 3 недели.
- К финалу проект приближается к окончательному виду медленнее, хотя кажется, что сходимость должна быть быстрее.
- Дисциплина полезна искусству. Архитектура усиливает, а не подавляет творчество.
Про работу пиэма
- Все сложности, с которыми сталкиваются при разработке систем, – из-за организационных неполадок.
- Принцип второстепенной функции: власть и эффективность центра (а также общее процветание) увеличатся, если охранять свободу и ответственность более низких формирований. Лучший друг и постоянный противник пиэма – независимая тестирующая контора.
- Пиэму редко удается контролировать условия работы и даже ее цели: положение вещей – «полномочия ниже ответственности».
- Пиэму нужно 2 вида данных: 1. информация о срывах плана, которая требует вмешательства; 2. общая картина.
- Задача менеджера – разработать, записать, сообщить другим и выполнить план. Несколько документов становятся осями управления проектом и главными инструментами менеджера. Там зафиксированы: цели, спецификации, график, бюджет, организационная структура, пространственное расположение, оценка, прогноз и цены.
- Пиэм должен обеспечить общее движение в одном направлении. Его главная задача – общение, а не принятие решений.
- Выдающиеся проекты создают выдающиеся проектировщики, выявляйте их как можно раньше. Лучшие – не всегда самые опытные. Дайте наставника, разработайте планы роста, стимулируйте.
Про подход и мышление
- Голландская пословица: «Корабль на мели – моряку маяк».
- Чем выше уровень мышления, тем больше примитивных составляющих мысли.
- Линейная экстраполяция данных бессмысленна: если экстраполировать время, за которое можно пробежать стометровку, то окажется, что можно пробежать милю за 3 минуты.
- Инженеры-химики: осуществленный в лаборатории процесс нельзя сразу перенести на завод. Сначала нужен опытный завод, чтобы понять, как в данном случае наращивать количество веществ в незащищенной среде.
- Самые ужасные строения – те, бюджет которых слишком велик для поставленных целей.
- Древнее изречение: «В море нельзя выходить с 2 хронометрами: нужно взять 1 или 3».
- За мастерством стоит изобретательность. Экономичное и быстрое обычно появляется в результате стратегического прорыва, а не тактического умения.
- Иногда приходится возвращаться, отбрасывать верхний уровень и начинать сначала.
- Радикальное решение при создании программ – вообще не создавать, а покупать. Дешевле.
- Будьте готовы предложить способ реализации замыслов и согласиться с любым способом, который не хуже.
- Скептицизм не есть пессимизм. Нет царского пути, но путь есть.
- Сэмюэл Батлер: краткость полезна, когда нас понимают или не понимают.
- Страшно только на словах: фактическая власть приобретается как следствие успешного выполнения задач.
