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

Оставайся гибким!

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

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

Прекрати писать код!

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

Когда я вижу, что новоиспеченный руководитель «опускается» до написания кода, я говорю ему: «Мы знаем, что ты умеешь писать код. Вопрос в другом: умеешь ли ты руководить? Ты больше не отвечаешь за себя одного, ты отвечаешь за всю команду целиком; и я хочу быть уверенным в том, что ты сможешь сделать так, чтобы твоя команда решала проблемы самостоятельно, без того, чтобы тебе самому приходилось писать код. Твоя задача состоит в том, чтобы выяснить, как масштабировать самого себя. Я хочу, чтобы ты не был одним-единственным, я хочу, чтобы таких, как ты, было много».

Хороший совет, верно? Масштаб. Менеджмент. Ответственность. Такие расхожие модные словечки. Жаль, что совет неверный.

Неверный?

Ага. Совет неверный! Не то чтобы абсолютно неверный, но достаточно неверный, чтобы мне пришлось позвонить некоторым бывшим коллегам и извиниться: «Помнишь то мое любимое утверждение о том, что ты должен прекратить писать код? Оно неверное! Да… Снова начинай программировать. Начни с Python и Ruby. Да, я серьезно! От этого зависит твоя карьера!»

Когда я начинал карьеру разработчика ПО в Borland, я работал в команде Paradox для Windows, а это была огромная команда. Только одних разработчиков приложения было 13 человек. Если прибавить людей из других команд, которые тоже постоянно работали над ключевыми технологиями для этого проекта, такими как основной движок базы данных и основные сервисы приложения, то получалось 50 инженеров, напрямую занятых разработкой этого продукта.

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

Чем разработчики занимались последние 20 лет? За это время мы написали фигову тучу кода. Море кода! Мы написали так много кода, что решили: неплохо бы все упростить и перейти на открытый исходный код.

К счастью, благодаря интернету этот процесс сейчас стал максимально простым. Если вы разработчик ПО, то можете проверить это прямо сейчас! Поищите свое имя в Google или в Github, и вы увидите код, о котором вы давно забыли, но который может найти каждый, кто пожелает. Страшно, да? Вы не знали, что код живет вечно? Да, он живет вечно.

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

Эта цепочка рассуждений звучит удручающе, однако идея заключается в том, что все мы — это лишь кучка интеграционных автоматов, использующих клейкую ленту для того, чтобы соединять между собой разные частички уже существующих вещей для создания немного другой версии того же самого. Это классический ход мыслей высшего руководства, обожающего аутсорсинг. «Это может сделать любой, кто умеет пользоваться Google и у кого есть клейкая лента! Тогда зачем мы платим кучу денег нашим автоматам?»

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

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

Прекратите писать код, но…

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

Если у вас небольшая команда и она делает много за небольшие деньги, то идея прекратить писать код кажется мне плохим карьерным решением. Даже в компаниях-монстрах с их бесконечными регламентами, процессами и политикой вы не имеете права забыть, как самостоятельно разрабатывать софт. А разработка софта непрерывно меняется. Она меняется прямо сейчас. У вас под ногами! В эту самую секунду!

У вас есть возражения. Понимаю. Давайте послушаем.

• «Рэндс, я на пути в директорское кресло! Если я продолжу писать код, никто не поверит, что я способен расти».

Я хочу спросить вас вот о чем: с тех пор, как вы сели в свое кресло «Я скоро стану директором!», замечали ли вы, что сфера разработки соф­та меняется даже в пределах вашей компании? Если ваш ответ «да», то я задам вам другой вопрос: как именно она меняется и что вы собираетесь предпринять в связи с этими изменениями? Если на мой первый вопрос вы ответили «нет», то вам нужно пересесть в другое кресло, потому что (зуб даю!) сфера разработки софта меняется в эту самую секунду. Как вы вообще собираетесь расти, если вы медленно, но верно забываете, как разрабатывать софт?