У нас в Wrike есть традиция делиться с командой мыслями о книгах, которые прочитали. Мы давно думали, что было бы неплохо распространить эту инициативу и на наш блог на Хабрахабре, и вот подвернулся хороший случай — книга Фредерика Брукса «Мифический человеко-месяц».

Книгу можно назвать скорее классикой фольклора разработки, нежели реальным руководством по построению рабочего процесса. В ней отражены проблемы, с которыми Брукс столкнулся при организации работы над созданием операционной системы OS/360, и его подходы к их решению. Результат был далек от идеала, на что сам Брукс и указывает. Его целью было не научить как правильно, но поднять проблемы, требующие решения. Любопытно разобраться, что изменилось в разработке с 1960-х годов.


Фото из архива IBM

Прежде чем говорить о самой книге, нужно понять контекст. Что на самом деле был за проект OS/360, с какой целью он разрабатывался и в каких условиях.

История разработки System/360

В начале 1960-х корпорация IBM была абсолютным лидером рынка компьютеров. Ее доля составляла 75%. Однако перспективы становились все менее радужными. Абсолютно все системы IBM были несовместимы между собой. Серии 1401, 1620, 7070 и т. д. были полностью изолированными. Хотите перейти с 1401 на 1620 — купите не только новый процессор, но и всю периферию. Софт тоже придется переписать.

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

И вот, в январе 1961 года 29-летний Брукс представляет проект очередной серии 8000. Конечно, новая система лучше предыдущих во всем, но в одном она с ними одинакова. Это еще один полностью уникальный комплекс, переход на который обойдется клиентам в миллионы, как и его поддержка самой IBM. Понятно, что это тупик. Проект закрывают, а Бруксу предлагают возглавить группу по разработке совершенно новой системы. Но какой никто не знал. Одно было понятно — новая система должна обеспечить в дальнейшем обратную совместимость как на аппаратном, так и на программном уровне, а также быть системой общего назначения, подходящей и банкам, и военным, и ученым.

Была сформирована группа из 25 человек во главе с Бруксом, которая занялась разработкой плана новой системы. Процесс двигался медленно, и чтобы его ускорить, руководство решило переселить рабочую группу в отель в пригороде Нью-Йорка с ультиматумом, что команда не выйдет оттуда, пока не придет к общему решению. И они пришли. И этому решению дали зеленый свет.

Весь аппаратно-программный комплекс назвали System/360, а операционную систему — OS/360. Иронично, что проблемы обратной совместимости было решено решить за счет отказа от совместимости с предыдущими системами.

Разработка системы заняла существенно больше планируемых сроков, ее стоимость составила не $625 млн, но $5,25 млрд долларов — немногим меньше, чем программа Appollo с ее ракетами, астронавтами и высадкой на Луну за тот же 1965 год. Риск банкротства для IBM был вполне реален, но все обошлось. Анонс системы состоялся 7 апреля 1964 года, а первые продукты были выпущены в середине 1965. Успех был грандиозный. Принцип взаимозаменяемости компонент, заложенный в рамках этой системы, соблюдается и по сей день. К слову, именно после System/360 стандартным размером байта стали 8 бит.

Основные утверждения Брукса

Из предисловия ко второму изданию: «Эта книга является запоздалым ответом на вопросы относительно трудностей разработки программ (“запоздалым” в 1975 году! — прим. авт.). В течение ближайшего десятилетия не возникнет методов программирования, использование которых позволит на порядок повысить производительность разработки при прочих равных условиях».

Среди основных утверждений Брукса, которые стали расхожими, можно отметить следующие:

1. Программному продукту грозит устаревание еще до его завершения.
2. Из всех проектируемых систем наибольшую опасность представляет вторая по счету. Обычно ее приходится перепроектировать заново.
3. Планируйте выбросить первую версию — вам все равно придется это сделать, потому что она не удовлетворит ожидания пользователей.
4. Нельзя оценивать программные проекты в человеко-месяцах. Человеко-месяц — ошибочное и опасное заблуждение, поскольку он предполагает, что месяцы и количество людей можно менять местами.
5. Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых.
6. Закон Брукса: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

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

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

Первая и вторая системы 50 лет спустя

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

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

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

Архитектура второй системы получится плохой. Проект System/360 Брукс считает именно второй системой. Специализированные проекты, которые IBM разрабатывала ранее получались вполне неплохими, а вот с 360 они решили все сделать правильно.

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

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

В конечном итоге разработку ускорило не технологическое развитие, но сокращение цикла разработки и получение быстрой обратной связи.

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

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

Планирование сроков и ресурсов проекта — нехитрое по сути дело. Если знать все задачи, зависимости между ними, оценки сроков и необходимые ресурсы, то все вполне просто. Только ленивый не справится с созданием плана в таких условиях. Но даже в этом случае нельзя бесконечно добавлять людей, чтобы ускорить проект. Всегда есть критический путь который определяет минимально возможные сроки, вне зависимости от количества ресурсов. Подробнее об этом, см. «Управление проектами в СССР (1976)» и «Критическая цепь».

К сожалению, условия необходимые для осуществления планирования не всегда выполняются. В этом случае составить корректный план невозможно. Даже оценки сроков выполнения отдельных задач всегда получаются из практического опыта. Но что если такого опыта нет? Завязать шнурки — минутное дело, вернее 5-7 секунд. Завязывая шнурки каждый день, мы можем из своего опыта достаточно точно оценить, сколько времени нам потребуется на выполнение этой же работы завтра. Но попробуйте предсказать, сколько времени у вас займет завязать шнурки одной рукой. Совпадут ли ваши оценки с реальным опытом? Любопытный эксперимент. Подробнее — Robert C. Martin «Effective Estimation (or: How not to Lie)».

Мы очень плохи в планировании того, что никогда не делали, любых новых инициатив, не только программной разработки. Именно в такой ситуации оказался Брукс, когда его попросили составить план проекта, а также оценку сроков и стоимости разработки System/360.

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

Однако краткосрочное планирование вполне реально. Если планировать итерации на 2-4 недели, это можно делать достаточно точно. Со временем нарабатывается навык декомпозиции крупных задач на более мелкие, а небольшие задачи оценить проще. Кроме того, постоянно работая в одном направлении, человек накапливает экспертизу. Задачи, которые три месяца назад казались совершенно новыми, так что их можно было оценивать только пальцем в небо, оказываются вполне похожими на недавние. Значит, и оценки их сроков будут аналогичными.

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

Что Брукс упустил

— Мистер Брукс, вы сказали, что на проект вам потребуется два года и $625 млн, прошло уже два с половиной, вы вдвое превысили бюджет, но результатов нет. Мистер Брукс, вы понимаете, что успех всей компании зависит от скорейшего завершения вашего проекта? Мы выделяем вам еще $2 млрд и наймем вам дополнительно 500 человек.
— Мистер Брукс, ваша задача завершить все необходимые работы в течение следующего года.

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

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

Реальная проблема Брукса не в том, что на выполнение его проекта потребовалось четыре года, и не то что бюджет составил $5 млрд., а в том, что он не смог заранее точно спланировать ни сроки, ни бюджет. Фактически он ошибся в 10 раз. Конечно, Брукс ищет способ как ускорить разработку в те же 10 раз, но это не решение.

Никто на месте Брукса не смог бы дать более точных обоснованных оценок проекта. Конечно, кто-то другой мог бы сказать три года и два миллиарда долларов, в этом случае ошибка была бы меньше. Но такая, “более точная оценка”, была бы результатом удачной догадки нежели рациональным прогнозом.

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

Все могло бы повернуться иначе, если бы в начале проекта Брукс настоял на том, что бюджет проекта может составить от $1 до $6 млрд., а длительность от 3 до 7 лет, и дать более точных оценок невозможно. А руководство IBM, в свою очередь, признало эти оценки.

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