Кодеры за работой

Должен выразить самую искреннюю благодарность Фрэнку Харту. Не знаю, как ему удавалось руководить нами, при этом всегда позволяя оставаться самими собой. Не припоминаю ни одного собрания программистов. Не припоминаю, чтобы нас хоть раз загрузили бумажной работой, когда наши головы были полностью заняты программой и некогда было отвлекаться на все это. Это был такой уровень доверия и уверенности, когда нам троим просто дали эту работу и оставили в покое. Оглядываясь назад, я понимаю теперь, как это трудно быть менеджером проекта и какую потрясающую работу проделал Фрэнк. Никаких еженедельных собраний сотрудников, никакого рисования PERT-диаграмм на доске. Уилл, конечно, отслеживал текущие задачи, найденные ошибки и прочую проделанную работу, но отсутствие какого-либо систематического надзора над нами поражало. Собрать нас вместе, дать нам поручение и уйти в тень — думаю, для руководителя это был очень смелый поступок.

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

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

Та часть выступления, в которой ты был уверен, не вызывала интереса. Тебе просто говорили: «О!» Но на той части, где ты «плавал», непременно концентрировали внимание. Я знаю тех, кто действительно боялся таких ревизий. Неуверенный в себе программист мог подумать, что его раскритиковали, выставив некомпетентным, и все плохо.

На самом же деле все было не так, и с другой стороны стола это было отлично видно. Ревизия проекта помогала сотруднику двигаться в верном направлении при работе над проектом. Там, где он чувствовал себя уверенно, он мог разобраться и сам. Но зато лучшие умы BBN могли подсказать ему что-то в тех местах, которые он недостаточно продумал. Почему так получилось? О чем он вообще думал? Что пошло не так? За 15 минут можно было получить реальную помощь.

Нужно быть достаточно уверенным в своих навыках профессионалом, чтобы сказать: «Отлично. Вот моя проблема. Я не знаю, что с ней делать, и когда готовил свой отчет, надеялся, что вы, ребята, этого не заметите и одобрите его». Естественным ответом на это будет: «Конечно, мы одобрим его, потому что он выглядит хорошо. Теперь давай разберемся с твоей проблемой — наши лучшие парни собрались здесь как раз для того, чтобы ты не бился над этим сам еще неделю или две».

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

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

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

Сейбел:

Как часто проводились подобные ревизии? Один раз в самом начале проекта или периодически на протяжении всего срока работы над ним?

Козелл: Многократных ревизий не было. Обычно она проводилась один раз сразу после того, как ты разработал проект.

Сейбел: Получается, нужно было знать, как будет выглядеть результат, еще до того, как начнешь программировать?

Козелл: Да, точно. Именно так. Наверное, что-нибудь запрограммировать все-таки придется, потому что многим, включая меня, требуется собрать по кусочку кода, чтобы понять, как все в итоге будет работать.