Текст книги "Как управлять интеллектуалами. Я, нерды и гики"

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

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

Фред, проклятье успешного бизнеса состоит в том, что мы вынуждены двигаться медленнее. И да, это раздражает. Смотри, мы были успешны, и в результате этого успеха мы наняли больше людей для того, чтобы выполнить кажущийся нереальным объем работы, порожденный нашим успехом. Однако каждый новый сотрудник, взятый нами для того, чтобы делать больше работы, стратегически нас замедляет. Каждый дополнительный человек взымает с нас нечто вроде «коммуникационного налога», и пока мы не выясним, как усовершенствовать внутренние коммуникационные процессы, мы продолжим замедляться. Именно поэтому мы и находимся здесь; и даже если сейчас на кофейном энтузиазме мы обнаружим идеальные решения для наших коммуникационных проблем, то сначала нам нужно будет изучить их вместе с множеством светлых голов, нанятых нами за последнее время для того, чтобы они помогали нам расти.

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

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

И вот все закончилось. Фред вернулся в офис, он полон энтузиазма и готов менять мир; но в тот момент, когда он вошел в кабинет, он вдруг увидел всё то, что ему предстоит сделать. Когда он попытался перестроить свой ежедневный рабочий контекст, он понял: «У меня не просто очень много работы, теперь я еще и ужасно отстаю от всех сроков!» Сверкание и мерцание, явившееся ему на офсайде, очень быстро померкло.

Прошла неделя, и Фред начал злиться. Фред злился, ведь он наконец-то понял, что никто не собирается реализовывать за него все эти сверкающие и мерцающие идеи офсайда. Спустя неделю от двухдневного офсайда не осталось ничего, кроме неизменной реакции Фреда: «Что ж. Это была пустая трата времени!»

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

17
Другой тип ДНК

Горизонтальная организационная структура – это мем про быстро растущие команды в Кремниевой долине, и там есть пара выдающихся идей. Если в двух словах, то горизонтальная структура – это самая малая из всех возможных иерархических структур, позволяющая слышать каждый отдельный голос в компании. Как такое может не нравиться?!!

Первая трудность магической горизонтальной структуры – это неизбежный приход лидеров или руководителей, перед которыми будет стоять задача реализовать различные аспекты деятельности команды. Ответ «религии горизонтальной структуры» на этот неизбежный этап развития заключается в переосмыслении ролей: лидер или руководитель ничем не отличается от остальных сотрудников. Нет повышений по службе, нет карьерного роста, есть только различные проекты. Между теми, кто отвечает за продукт, и теми, кто отвечает за людей, нет никакой разницы. Я обожаю это! Обожаю, потому что это и есть начало для решения ключевой карьерной проблемы, типичной для инженерных команд: как нам расти? Как я писал в своей книге «Быть гиком» (Being Geek, 2010), проклятье Кремниевой долины состоит в том, что великолепных инженеров из-за их высокой работоспособности часто выдвигают в лидеры. Многие из них преуспевают на этом новом поприще, однако ровно столько же терпят поражение, потому что навыки, требуемые для того, чтобы быть лидером, разительно отличаются от навыков, требуемых для того, чтобы быть хорошим инженером. А проклятье заключается в том, что мы часто ставим самых ценных инженеров на позиции, где их поражение неизбежно.

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

Однако все мечтают о карьерном росте.

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

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

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

В качестве решения данной проблемы я предлагаю проведение ДНК-совещаний.

ДНК означает «дизайн и архитектура»[7]7
  DNA (Design and Architecture) (англ.). – Примеч. пер.


[Закрыть]. По существу, ДНК – это просто совещание. Это выборка блестящих инженеров из всей команды или даже из всей компании, которые находятся в одном помещении и перед которыми поставлена конкретная цель. Из названия ясно, что эти инженеры отвечают за глубокий анализ вариантов и направлений развития продукта. Вероятнее всего, вы уже неформально проводили подобные совещания, когда перед вами стояли крупные технические или дизайнерские задачи. Вы собирали в одном помещении несколько пар глаз, чтобы тщательно изучить новую задачу. ДНК-совещание превращает неформальное в формальное и имеет пять залогов успеха:

1. ДНК-совещание должно проливать свет на рассматриваемую проблему. Чем больше пар глаз обращено на проблему, тем лучше; ДНК-совещание проводится, когда в компании возникают сложности технического характера. Серьезные. Или даже суперсерьезные. Не то чтобы на кону стоит судьба компании, но на кону может стоять судьба команды или важное решение. Если мы провалимся, то последствия будут критическими. Именно поэтому, если ДНК-совещание проваливается, то вы…

2. Используйте достойную огневую мощь. Далее я подробнее расскажу о структуре ДНК-команды, а сейчас я хотел бы, чтобы вы вспомнили о трех лучших инженерах из своего окружения. Я говорю об инженерах, не просто обладающих выдающимися инженерными способностями, но и умеющих обучать, то есть об инженерах, которые не только понимают сами, но и могут говорить о том, что они понимают, и объяснить это другим. Такие инженеры проливают свет на идеи и понятия, делая сложное до боли очевидным. ДНК-команда – это не просто группа инженеров, являющихся лучшими кандидатами для изучения глобальной идеи; это группа инженеров, умеющих говорить о том, как эту идею можно усовершенствовать, способных на конструктивную критику и абсолютно свободных от драматизма и политических интриг.

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

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

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

4. ДНК-совещание не имеет ничего общего с менеджментом (однако очень много общего с лидерством). Чистопородные руководители не рассматриваются в качестве участников ДНК-совещаний, потому что ДНК-совещание подразумевает идеально культивированное техническое лидерство. ДНК-совещание – это совещание инженеров-«инфлюенсеров», которые не любят непосредственного подчинения, а стремятся быть лидерами. Они хотят принимать важные для всей технологической сферы решения. Если на ДНК-совещании всё будут решать руководители, то оно станет совещанием руководителей, а не технических лидеров.

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

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

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

18
Инженерная ментальность

В книге Рэндса о правилах для руководителей есть очень короткий перечень современных менеджерских «must-do»[8]8
  То, что нужно обязательно сделать. – Примеч. пер


[Закрыть]. Лаконичность этого перечня проистекает из того факта, что понятие «must» – это некий абсолют, а когда речь заходит о людях, то абсолютных понятий становится очень мало. Удачный метод руководства одним сотрудником станет настоящей катастрофой для другого. Эта мысль и есть первый пункт менеджерского «must-do» списка:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 «Уф, Рэндс! Но ведь кто-то должен быть арбитром! Кто-то должен видеть общую картину. Если я буду писать код, то я потеряю из виду перспективу».

Вы по-прежнему должны оставаться арбитром, вы по-прежнему должны транслировать решения, и вы по-прежнему каждое утро понедельника должны четыре раза обходить всё здание вместе с одним из своих инженеров, чтобы в течение 30 минут слушать его еженедельную тираду «Мы все обречены!». Но помимо всего этого, вы должны сохранять в себе инженерный образ мышления, а для этого вам не обязательно быть программистом на полную ставку.

Мои советы по сохранению инженерной ментальности:

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

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

3. Возьмите на себя реализацию одной из функций. Я буквально вздрагиваю, когда пишу это, потому что этот пункт таит в себе много скрытых опасностей, но я действительно не уверен в том, что вы сможете выполнить пункт № 1 и пункт № 2 без того, чтобы взять на себя реализацию хотя бы одной функции. Благодаря самостоятельной реализации одной из функций вы не только будете активно участвовать в процессе разработки, это также позволит вам периодически переключаться с роли «Руководителя, отвечающего за все» на роль «Человека, отвечающего за реализацию одной из функций».

Эта скромная и непритязательная позиция будет напоминать вам о важности маленьких решений.

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

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

Снова возражение?

 «Рэндс, если я буду писать код, то я буду сбивать с толку свою команду. Они не будут знать, кто я – руководитель или разработчик».

Хорошо.

Да, я сказал: «Хорошо!» Я рад, что вы считает, что сможете сбить с толку свою команду лишь тем, что плаваете в пруду разработчиков. Тут всё просто: границы между различными ролями в сфере разработки софта в настоящий момент сильно размыты. Парни, занимающиеся пользовательским интерфейсом, делают то, что можно в целом назвать программированием на JavaScript и CSS. Разработчики всё больше и больше узнают о проектировании взаимодействия с пользователем. Люди общаются друг с другом и узнают об ошибках, о воровстве чужого кода, а также о том, что не существует никакой уважительной причины для того, чтобы руководитель не мог участвовать в этой массивной, глобальной, перекрестно опыляющейся информационной вакханалии.

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

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