оклада. Просто кому-то нужно было руководить разработкой вот этого отрезка работы, поэтому говорилось что-то вроде: “Не хочешь ли взяться за это?” или “Очевидно, этим должен руководить ты”. Это было техническое руководство - таких руководителей было немного. Но в исследовательском центре человек становится членом исследовательского центра (Research Staff Member, RSM) с момента прихода туда и практически до конца карьеры. Вот кем являемся мы с коллегами. Поэтому можно постоянно выдвигаться и уходить с руководящей должности - без какого-либо клейма.

Сейбел: Скорее всего, руководить доверят тому, кто хорошо с этим справляется. Как вы приобрели подобные навыки?

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

Сейбел: Одна из трудностей в техническом менеджменте, которым вы занимались, - уравновесить стремление самому направлять работу сотрудников и их желание думать самостоятельно.

Аллен: Как мне представляется, в рамках работы над проектом Stretch я получила ряд суровых уроков. Помню, однажды ко мне подошли несколько сотрудников проекта и сказали, что мы должны использовать списки и хеш-функции. Мы знали о списках, но хеширование было в новинку. И двое колллег говорят мне, что хотят использовать хеширование для таблицы символов. Я ответила: “Нет, мы не можем. Мы не знаем, как с этим работать”. Бла-бла-бла. В следующий понедельник я прихожу и вижу - они сделали это. Они снесли систему целиком и сделали ее заново, добавив туда хеширование. Это сработало, система начала работать намного быстрее. Это был важный урок для меня. Я должна быть более открытой для совершенно новых идей.

Сейбел: То есть иногда - может быть, даже часто - подчиненные знают, о чем говорят, и не следует слишком уж вмешиваться в их работу, потому что вы можете зарубить на корню хорошую идею. Сложнее представляется ситуация, в которой вы действительно правы, а идея подчиненного в самом деле не без изъяна, но вы все равно не хотите на него давить.

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

С серьезной проблемой такого рода я столкнулась, выполняя какой-то проект по договору субподряда. У меня была группа специалистов, прекрасно справлявшихся с созданием оптимизатора на основе нашей же работы, которую мы проделали для ПЛ/1 - громоздкого, очень прихотливого языка. Но кто-то из работников субподрядчика, недавно открыв для себя объектно-ориентированное программирование, решил применить его здесь по полной. Я не смогла ему помешать, даже несмотря на то, что отвечала за контракт, и проект был загублен. Грубо говоря, проблема была в том, что в ПЛ/1 множество указателей, и каждый указатель постоянно отслеживался; а чтобы отслеживать значение, то есть находить значение по указателю, требовалось 11 инструкций.

Сейбел: То есть в уже сгенерированном коде.

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

Сейбел: Какие продукты для IBM, в разработке которых вы принимали участие, имели сроки сдачи, в которые надо было уложиться?

Аллен: Безусловно, здесь нужно упомянуть проект Stretch. Кроме того, я участвовала в разработке продукта еще 2-3 раза, с еженедельными ревизиями кода незадолго до сдачи проекта. Я с большим уважением отношусь к этим процессам, считаю их очень важными для конечного результата и для команды, работающей над проектом. Хотя это может быть очень утомительным - каждую пятницу садиться читать код, слушая объяснения, почему сделано так-то и так-то, и находить ошибки других.

Сейбел: Это утомительно, но стоит того?

Аллен: Безусловно, стоит. Во время работы над проектом PTRAN, ближе к завершению, мы включали фрагменты кода в другие продукты, полдня уходило на объяснение ошибок в нашем коде, их коде, неважно, - и так каждую неделю, около 10 месяцев. Полпятницы уходило на это.

Сейбел: Работая в подобных условиях, вы ощущали, что у вас есть процесс, позволяющий достаточно точно рассчитать время, необходимое для создания определенного объема ПО?

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

Сейбел: На что вы обращали внимание, нанимая сотрудников?

Аллен: У меня было множество связей в университетах. В Нью-Йоркском университете был прекрасный факультет, где программистов учили писать компиляторы; эти ребята действительно хорошо писали компиляторы.

Сейбел: То есть можно нанять человека, рекомендованного вам профессором, которого знаешь и которому доверяешь. А если проводишь собеседование с тем, у кого нет солидной рекомендации, - как за несколько часов понять, станет человек хорошим программистом или нет?

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

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

Сейбел: В дальнейшем вы стали заниматься наставничеством - IBM даже присуждает премию лучшему наставнику, названную в вашу честь. Как сделать, чтобы неопытные программисты становились более квалифицированными программистами?

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

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

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

Сейбел: Это, наверное, самое сложное. Как по-вашему, чем отличается по-