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

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

20 «Кан — варвар», Джонатан Вебер, «Лос-Анджелес таймс» от 23 февраля 1992 г. (http://articles.latimes.com/1992-02-23/business/fi-5118_1_borlandinternational-chairman-philippe-kahn).

21 2http://blogs.wsj.com/deals/2012/02/01/mark-zuckerbergs-letter-from-thefacebook-filing/

31. Разрушители энтропии

Машины по уничтожению хаоса

Когда вы впятером сидели в одном кабинете, всё было легко. Если кто-то хотел что-то узнать, то он просто вставал посреди кабинета и спрашивал: «Кто сломал сборку?» Если нужно было принять решение, то вы все смотрели на Фила и говорили: «Фил, это нужно масштабировать, начиная с первого дня. Верно?» И Фил кивал. По его кивку вы могли определить весь план производственных характеристик продукта. Если кто-то испытывал затруднения или застревал на каком-то этапе, вы могли поговорить об этом, потому что вы слышали, как он громко ругается, сидя перед своим монитором — прямо напротив вас.

Ему явно нужно помочь.

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

Я хочу доказать вам, что пришло время нанять менеджеров проекта.

ВОУ, ВОУ, ВОУ, ПОЛЕГЧЕ, РЭНДС! ЧТО-О-О ТЫ СКАЗАЛ? У нас в компании самозапускающаяся культура разработки. Мы горизонтальная организационная структура, и мы не хотим портить нашу корпоративную культуру…. какими-то менеджерами проектов.

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

• Большинство инженеров не знают, чем занимается менеджер проекта, а даже если и знают, то обычно они не знают, как выглядит хороший проект.

• Слабые менеджеры проектов испортили репутацию этой позиции.

• Утверждая, что вам не нужны менеджеры проектов, вы — инженер — тем самым говорите, что хотите взять его работу на себя. В связи с этим у меня к вам вопрос: вы хотите быть инженером или кем-то другим?

Правила проекта

Во-первых, определимся с понятиями. Менеджер проекта, менеджер продукта, менеджер группы проектов — давайте разберемся в них. Менеджер проекта отвечает за выпуск продукта, тогда как менеджер по продукту отвечает за выпуск правильного продукта. Менеджер группы проектов — это такой мутант-переросток, объединяющий в себе и то и другое; обычно он нужен для того, чтобы вести множество взаимосвязанных проектов, скажем, таких, как разработка операционной системы. Разные компании используют разные названия для этих позиций, но в этой главе будет так: менеджер проекта = выпустить продукт, менеджер продукта = выпустить правильный продукт, а менеджер группы проектов = выпустить много разных взаимосвязанных продуктов, причем, как правило, в одно и то же время. Всё понятно?

Во-вторых, правило гласит: приход в команду каждого нового человека повышает «стоимость» каждого из следующих пунктов:

• Коммуникация. Сколько усилий требуется для того, чтобы сделать так, чтобы Идея А дошла до всех сотрудников, до которых она должны дойти?

• Решения. Как быстро группа людей может выбрать лучший вариант между Вариантом А и Вариантом В?

• Исправление ошибок. Как много времени требуется на то, чтобы выявить и исправить то, что не функционирует?

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

Как это происходит сейчас?

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