Майкл Лопп - Как управлять интеллектуалами. Я, нерды и гики

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

• Он обитает вне четко установленного процесса, который был разработан для того, чтобы мы могли выполнять свои задачи; он не следует общепринятым правилам и обычно не страдает от последствий этого факта.

• Все знают, что он — Волк, но никто никогда не называет его Волком.

• У него есть руководитель, однако никто не знает, кто это.

• У него куча совещаний, но ни одно из них не было запланировано заранее. Пригласить его на совещание — это настоящая лотерея.

• Он знает, как функционирует «система». Он знает, как можно использовать «систему» в своих целях, и он знает, почему «система» существует, однако он думает, что «система» — это что-то несерьезное.

• Вы можете попросить Волка стать руководителем, но он будет сопротивляться. Если вам удастся уговорить его, он будет прекрасно справляться со своей работой, однако вряд ли надолго останется в этой роли. Скорее всего, он уйдет с поста руководителя тогда, когда вы меньше всего будете этого ожидать.

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

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

Легко ненавидеть Волка, если вы только что потратили весь свой рабочий день на написание интеграционных тестов. С другой стороны, легко восхищаться Волком, потому что ему удается диктовать свои собственные условия.

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

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

43. Свободные электроны

Заботиться и подпитывать высокую производительность труда

Вернемся к тому времени, когда я работал в Borland. Мы трудились над Paradox для Windows. Я был инженером по контролю качества и тестировал функциональность баз данных по функциям создания и модификации. Джерри, мой партнер, занимавшийся разработкой, усердно работал, но не был особенно успешен.

Мы находились во второй половине производственного цикла версии 1.0, и большинство инженеров медленно, но верно двигались от разработки к режиму устранения багов. Но не Джерри! Джерри всё еще внедрял… Снова и снова. Если жизненно важная для вас задача поручена человеку, который абсолютно не способен ее выполнить, то ваше дело труба.

Но сначала давайте дадим Джерри перерыв и сделаем отступление. Он был прекрасным программистом, однако обладал двумя серьезными недостатками. Во-первых, Джерри никогда не программировал для Windows, поэтому ему приходилось учиться по ходу дела. Во-вторых, это была версия 1.0. Глава 22 этой книги называется «1.0», но на самом деле ее стоило бы назвать «1.0, что означает: “О боже! Я больше никогда не увижу свою семью!”» Кратко напомню: версия 1.0 — невероятно сложна, особенно учитывая отсутствующий опыт работы для Windows. Выходило, что Джерри — в большой беде.

У Джерри еще оставалось чувство собственного достоинства. Джерри всё еще верил, что справится с трудностями, но, будучи получателем кода, я отлично видел его вызывающий большие опасения метод программирования, который мы называем «возить фигню по тарелке». Подход Джерри к устранению багов сводился к тому, что он непрерывно двигал свой код разными интересными способами так, как вы в детстве двигали по тарелке свой обед в беспомощных попытках убедить маму, что вы уже съели пару кусочков. Ничего существенно не меняется, просто выглядит по-другому. У такого метода программирования есть еще одно название: «программирование наугад».

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

Если вы руководитель и находитесь в подобном положении, то вам необходимо внести в ситуацию значительные изменения, потому что вы не можете выпускать фигню. Существуют компании, которые так делают и получают крошечную прибыль. Однако вы не из таких, потому что однажды вас настигнет кара за выпуск фигни, вы вслепую войдете в штопор и устремитесь дорогой заурядности, которая в итоге приведет к тому, что вы будете работать в Computer Associates над продуктом, о котором никто никогда не слышал и который никого не интересует.

Существует процесс выхода из подобной ситуации, состоящий из двух шагов. Мы должны решить вопрос с Джерри, а потом нам потребуется чудо. Я начал с самого простого.

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