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

    У нас в 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-е.
    Wrike
    Делаем совместную работу проще

    Комментарии 15

    • НЛО прилетело и опубликовало эту надпись здесь
        +1
        Да, и многие проекты появились на свет, благодаря именно такой «точной» оценке.
          0

          Вероятно, для компании вариант с отказом от разработки такого проекта был бы лучшим — сделали бы что-то менее масштабное.

          +3
          Уважаемый Дмитрий, в разделе «Что Брукс упустил» Вы выдвигаете идеи об ошибке и возможном решении. Хотел бы обратить Ваше внимание на то, что речь в случае Брукса идет о работе на границе известных вещей и за ней. Фредерик Брукс работал над передовым проектом, применял новые решения, а не воспроизводил старые. Хотя это и выглядит очевидным, но я вижу регулярное повторение ошибки разными людьми на разных уровнях: когда они переходят от работы над стандартными задачами, и берутся за что-то, находящееся на границе их познания или за ней, инструменты продолжают применять те же самые, что применяют к привычным задачам. В том числе, это касается планирования. И ошибка делается даже наедине с собой, не то что перед лицом бизнеса.
          Мне довелось видеть успешные примеры: перед началом работы выявляются области незнания, и помимо исследования и экспериментов, они на каждом очередном этапе разработки (неважно о каком продукте речь — программном или нет) переоцениваются заново, а так же оцениваются их стыки с известными частями. Ну а известные планируются стандартно. Этот прием не обещает гарантированный ответ сколько месяцев и долларов понадобится. Тем не менее, он закладывает коррекцию неправильных взглядов — специалисты, работающие над проектом, обязуются сразу и постоянно отслеживать определенные задачи и их структуру, а не просто брать-выполнять-завершать.
          Ожидать же от бизнеса понимания в данной ситуации — все равно что ожидать этого же понимания от того, кто будет реализовывать проект. Они все способны совершить одну и ту же ошибку. То есть, тому кто осознает ошибку и пытается ее корректировать, придется отстаивать свою позицию и соответствующие действия. Чтобы это не было досадной необходимостью по факту, нужно осознавать это как обязательные условия изначально.

          Еще одно небольшое дополнение. Утверждение «Планируйте выбросить первую версию — вам все равно придется это сделать, потому что она не удовлетворит ожидания пользователей» реализовано в виде приема у некоторых писателей и, особенно, у переводчиков. Специалист начинает работать над текстом, продвигается от начала к концу, и в финале отбрасывает начало (возможно, и середина), и делает его заново. В основе приема лежит простое явление: в начале работы специалист еще не знаком с материалом над которым работает (переводимый текст, создаваемый сюжет). И это относится к типовым задачам в данных отраслях. Если же повысить планку, то многие классические литературные произведения переписывались более одного раза.
            +1
            Спасибо за подробный комментарий! Я не совсем уверен, спорите ли вы со мной или дополняете, тем не менее, один момент кажется мне очень важным.
            Ожидать же от бизнеса понимания в данной ситуации — все равно что ожидать...


            1. Безусловно многие из нас делают ошибки путая достаточно определенные и предсказуемые работы и новые, непредсказуемые, для которые оценки основанные на предыдущем опыте не работают.
            2. Тем не менее, часто мы вполне понимаем что ступаем на terra incognita, и в лучшем случае мы можем оценить сроки и бюджет с ошибкой в 6-10 раз.
            3. Я ни в коем случае не пытаюсь апеллировать к тому чтобы бизнес «понял» и «простил» разработку, и «предоставил столько времени и ресурсов сколько разработчики захотят» — во первых такое отношение было бы снисходительным, а во вторых — так дела не делаются.
            4. Однако, неопределенность сроков сама по себе никуда не денется, вне зависимости от того кто берет на себя ответственность за соблюдение сроков которые невозможно гарантировать.
            5. Это проблема, и со стороны бизнеса можно ее игнорировать, а можно пойти навстречу разработке.
            +2
            Надо сравнивать сравнимые показатели. OS/360 — пример первого Enterprise программного продукта. И сравнивать его надо с такими же крупными промышленными решениями. Так вот, в таких решениях изменилось мало что за эти десятилетия. Так же невозможно точно планировать, так же сложно управлять огромным коллективом, так же есть проблема обманутых ожиданий и т.п.

            Спринты на 2 недели — отличное решение для небольших или архитектурно простых проектов. Или для наращивания функционала в крупном сложном проекте после стабилизации основных механизмов. Но для разработки этих самых основных механизмов требуется другой подход. И работа с крупным клиентом с тысячами требований радикально отличается от работы с клиентом с десятками требований.
              +1
              Спасибо за комментарий, но пожалуй я вам возражу. Одна из идей которую я хотел
              раскрыть состоит в том что не имеет значения «тип» проекта, как вы говорите.
              Возможность или невозможность осуществить предсказуемое планирование
              определяется тем, — выполняются ли для того необходимые условия.
              Более того, решение многих задач для профессионалов может быть вполне рутинной,
              планируемой работой. Однако, если лично вы не обладаете необходимой экспертизой
              и работа, по какой то причине, досталась лично вам — вы попадаете в область непредсказуемого, соответственно и планирование становится невозможным.
                0
                Есть вопросы, который каждый управленец открывает для себя сам. Это вопросы с сакральным смыслом, искать консенсус по ним бессмысленно (и правильного ответа на эти вопросы просто нет):
                — Надо ли все проекты вести по одной методологии?
                — Должен ли менеджер быть специалистом?
                — Кнут или пряник?
                — Точное планирование или главное ввязаться?
                — Эджайлый скрам наше все или нет?
                — Можно ли ядро банковский системы написать на php?
                — И пр.
                (Вопроса, надо ли врать заказчику при оценке проекта я не пишу, поскольку очевидно, что врать).
                У Брукса на подобные вопросы дан какой-либо ответ. С этим ответом можно соглашаться или нет, это ничего не меняет. Вообще, такие производственные мемуары нужны чтобы задуматься, а не искать ответ. В конце концов, можно вылепить Апполона из пенопласта ножовкой по металлу, но в программных проектах трудно сказать, какой метод работы правильный, а какой анекдотичен (предполагаю, что очень много программных проектов сделаны таким методом, просто им повезло).
                  0
                  надо ли врать заказчику при оценке проекта я не пишу, поскольку очевидно, что врать

                  А вы тоже используете две джиры, одну для разработчиков, другую для заказчиков? ;)

                  А если серьезно, следующее все же не соответствует действительности.
                  У Брукса на подобные вопросы дан какой-либо ответ.

                  Книга Брукса это список проблем нежели решений, более того, сам Брукс систематизировал их в список из двух сотен утверждений требующих критики.
                  Более того, сам Брукс сетует что получил слишком мало критики на свою книгу.
                    0
                    А вы тоже используете две джиры, одну для разработчиков, другую для заказчиков? ;)

                    Не джиру и не две, но мысль пошла в этом направлении ;-)
                    Книга Брукса это список проблем нежели решений, более того, сам Брукс систематизировал их в список из двух сотен утверждений требующих критики.

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

              Книгу можно назвать скорее классикой фольклора разработки, нежели реальным руководством по построению рабочего процесса.
              Очень сильное заявление. Если уж вы взялись оппонировать Бруксу, то дайте рецензию на его книгу, в чем вы с ним согласны, а в чем нет.
                +2
                Честно сказать, если бы я прочитал статью до прочтения книги — у меня бы вряд ли возникло желание читать ее.
                Вы берете цитаты Брукса и грамотно аргументируете, почему они не верны. Правда в самих цитатах некоторые неточности.
                Например:
                Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых.

                Под спойлером, автор опираясь на чужие исследования делает вывод, что это не всегда так
                Глава 3. «Операционная бригада»
                В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов. Правда, возможно и обратное. Полученные данные не выявили какой-либо корреляции между стажем работы и производительностью. (Я не уверен, что это всегда справедливо.)

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

                Этот вопрос не совсем к Бруксу. Во втором издании есть разъяснение. Вторая система и вторая версия системы — разные вещи.
                Глава 19 «Мифический человеко-месяц» двадцать лет спустя.
                Как насчет эффекта второй системы? Один наблюдательный ученый заметил, что «Мифический человеко-месяц» рекомендовал на случай неудачи для всякой новой системы планировать поставку второй версии (см. глава 11), которая в главе 5 характеризуется как таящая наибольшие опасности. Я вынужден был признать, что он меня «поймал».
                Противоречие скорее лингвистическое, чем реальное. «Вторая» система, описываемая в главе 5, — это вторая система, выпускаемая в развитие предыдущей с привлечением дополнительных функций и украшений. «Вторая» система в главе 11 — это вторая попытка разработки первой выпускаемой системы. Она разрабатывается в условиях всех ограничений, накладываемых графиком, способностями и неведением, характерными для новых проектов — ограничений, навязывающих дисциплину умеренности.

                В общем, тем, кто не читал, все же советую. Это классика, которую можно и читать и перечитывать. Не задаваться вопросом, «Прав ли автор!?», а просто анализировать, что же изменилось спустя 20, 50 или даже 100 лет.
                  0
                  Большое спасибо за детальный комментарий.
                  Согласен с вам, не смотря на то что некоторые главы откровенно устарели,
                  в целом книга вполне актуальна. Мы продолжаем сталкиваться с теми же проблемами
                  и совершать те же ошибки.
                    0

                    "Люди как люди. Любят деньги, но ведь это всегда было… Человечество любит деньги, из чего бы те ни были сделаны, из кожи ли, из бумаги ли, из бронзы или из золота. Ну, легкомысленны… ну, что ж… и милосердие иногда стучится в их сердца… обыкновенные люди… в общем, напоминают прежних… квартирный вопрос только испортил их…"

                  0
                  del

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое