Фредерик Брукс — человек, заложивший основы руководства проектами разработки программного обеспечения как делом, так и словом. Брукс являлся менеджером проекта создания семейства мэйнфреймов IBM System/360 и операционной системы OS/360, а его книга «Мифический человеко-месяц», первое издание которой вышло в 1975 году, по праву считается классическим трудом по управлению проектами разработки программных систем. В ней автор вывел утверждение, которое позднее стали в его честь называть «законом Брукса»: «Если увеличить число участников проекта, отстающего от сроков сдачи, это приведет к еще большему опозданию». Брукс покинул IBM в 1964-м, в год рождения System/360, после чего основал факультет компьютерных наук в Университете Северной Каролины в Чапел-Хилл. Сейчас Бруксу 79, он по-прежнему преподает, и в этом году опубликовал новую книгу, которая вышла в издательстве Addison-Wesley Professinal, — The Design of Design: Essays From a Computer Scientist.

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

Это было написано в первой редакции «Мифического человеко-месяца». Во второй я признал, что ошибался! Следует учитывать в своих планах, что начинать сначала придется много раз, а не просто готовиться разработать что-то, выкинуть и начать с нуля. Кое-что из того, что я говорил в 1975-м, неточно, и во втором издании я подправил формулировки.

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

Это мой основной тезис. У всех видов инженерной деятельности есть что-то общее. Давайте попытаемся найти эти общие стороны и будем учиться на примерах имеющих более долгую историю разновидностей инженерии, нежели инженерия программного обеспечения.

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

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

Вы выдвигаете идею противопоставления команды и разработчика-одиночки, рассказывая о том, как произошел переход к командному проектированию ввиду усложнения проектов. А как же Стив Джобс? Он исключение из правила?

Джобс, безусловно, выдающийся инженер в том отношении, что всегда знает, каким должен быть конечный продукт. Таким же был основатель компании Polaroid Эд Лэнд. Возможно, главная заслуга Лэнда и Джобса в том, что они смогли собрать команду специалистов, способных реализовывать их идеи. Джобс не делает все сам — он очень хорошо понимает, что необходимо сделать, и излагает свои идеи перед командой, способной воплотить их в жизнь.

А как насчет всех остальных? Как обычному человеку создать что-то грандиозное?

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

Мой совет: разрабатывая что-то новое, выберите главного проектировщика и позвольте ему работать так, как он хочет, без каких-либо ограничений. Предоставьте ему самостоятельно решать, какой будет конструкция. Насколько я могу судить, когда архитектору Кристоферу Рену поручили построить заново храмы, сгоревшие в Великом лондонском пожаре 1666 года, к нему не особенно придирались. А знаменитое Lockheed Skunk Works — секретное подразделение Lockheed Martin? Туда набрали инженеров, дали им полную свободу действий, и те создали самолет-«невидимку». У нас при разработке System/360 была целая толпа контролеров, но на финальном этапе проекта я их всех отстранил.

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

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

Как с этим бороться?

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

Как сейчас обстоят дела с обучением компьютерным наукам в США?

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

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

Как заинтересовать детей технологиями?

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

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