Фактический человеко-месяц
У нас в 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 году! — прим. авт.). В течение ближайшего десятилетия не возникнет методов программирования, использование которых позволит на порядок повысить производительность разработки при прочих равных условиях».
Среди основных утверждений Брукса, которые стали расхожими, можно отметить следующие:
- Программному продукту грозит устаревание еще до его завершения.
- Из всех проектируемых систем наибольшую опасность представляет вторая по счету. Обычно ее приходится перепроектировать заново.
- Планируйте выбросить первую версию — вам все равно придется это сделать, потому что она не удовлетворит ожидания пользователей.
- Нельзя оценивать программные проекты в человеко-месяцах. Человеко-месяц — ошибочное и опасное заблуждение, поскольку он предполагает, что месяцы и количество людей можно менять местами.
- Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых.
- Закон Брукса: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Это далеко не все мысли приведенные в книге, но они кажутся самыми главными. Разбирать все 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-е.
