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

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

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

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

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