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

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

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

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

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 человек. Вы раскиданы по двум этажам здания, работаете над двумя разными продуктами и приближаетесь к тому страшному моменту, когда уже не будете знать даже имен некоторых членов своей команды. Это первый из множества тревожных сигналов, возникающий, когда команде необходимы эволюционные изменения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, у нас есть первоначальный список задач, но кто будет выполнять всю эту работу? Нам нужно СОВЕЩАНИЕ ПО РАСПРЕДЕЛЕНИЮ ОБЯЗАННОСТЕЙ! А это значит, еще больше дебатов о том, кто что будет делать. Снова ведутся споры, потому что бывают крутые функции и некрутые функции, и они должны быть распределены тщательно, чтобы их крутизна была разделена поровну. Отлично! Наконец-то все функции распределены, но прежде чем начать работу, мы должны написать спецификацию по функциям, которая затем должна быть согласована с остальными членами команды, чтобы мы были уверены в том, что мы создаем нужную функцию. Я бы хотел обратить ваше внимание на тот факт, что еще не написано ни единой строчки кода, а я уже совершенно выдохся.

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