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

Факт № 6: Чем ниже падение, тем выше расходы.

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

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

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

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

Культура разработки

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

Назовите пять ваших любимых компаний и задайте себе вопрос, что именно сделало их такими успешными. Да, возможно, у них был гениальный 1.0. Помните, как вы впервые увидели Netscape? Помните, как вы впервые искали что-то в Google? Эти продукты стали результатом труда людей, которые готовы были рисковать жизнью ради того, чтобы наконец-то «вытолкнуть за порог» эту чертову вещицу. Эти люди создавали не только продукт, их работа сформировала культуру разработки в их компании, а это и есть то, что предопределило их будущий успех.

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

11 https://ru.wikipedia.org/wiki/Пирамида_потребностей_по_Маслоу

23. Мифы о процессе

Процесс — это слово из семи букв, начинающееся на «П», которое ненавидят все инженеры

Список способов вызвать гарантированную негативную рефлекторную реакцию у инженера может, по моему мнению, состоять из одного-единственного слова — «процесс».

Так, народ! Чтобы выпустить новый продукт точно в срок, я разработал новый процесс для работы с багами...

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

Ну, в чем же тогда дело? Почему мы вздыхаем?

Инженеры вовсе не ненавидят процессы. Они ненавидят только те процессы, которые не в состоянии себя оправдать.

Не отвечайте на мой вопрос

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

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

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