Факт № 6: Чем ниже падение, тем выше расходы.
Через год работы в стартапе основатели оказались на распутье. Мы разрабатывали корпоративное веб-приложение, работы велись у заказчика. Проблема состояла в том, что все просто сходили с ума из-за внешнего размещения. Проект звучал так: «Смотрите, сколько энергии и времени я вам сэкономлю, если размещу это приложение в моем дата-центре, а не в вашем». Эта идея шла вразрез с эпохой Oracle, PeopleSoft и IBM, с эпохой доминирования гигантских куч бизнес-софта и железа, лежавшего в ваших дата-центрах, но пришел интернет, интернет был готов спасти мир.
Основатели изменили свой проект. «Мы просто создадим копии софта в нашем дата-центре! Мы сэкономим деньги, храня наши биты поближе к дому!» Невелика разница, да? Нет! Эта перемена в нашем проекте фундаментально изменила архитектуру нашего продукта. Нам нужны были не сотни индивидуально разработанных версий нашего софта, расположенных в различных клиентских дата-центрах, а одна-единственная копия, конфигурируемая под любые потребности клиентов. Это и стало продуктом, который мы впоследствии разработали.
Это была катастрофа в режиме реального времени. Мы вложили кучу денег в эту трансформацию, но затраты на переход стали такими огромными, что мы прекратили заниматься чем бы то ни было, кроме того, чтобы пытаться заставить приложение хоста работать, и именно в этот момент произошел обвал доткомов.
Давайте называть «провалом» крупное неверное решение. Например, когда вы решаете провести какое-нибудь изменение, и это изменение пронизывает всю вашу пирамиду насквозь. Если вы приняли неверное решение по поводу изменений в управлении версиями, что ж, возможно, вы сможете адаптироваться к нему. Вы можете уволить свободный электрон и найти другого выдающегося человека, который сможет вести проект лучше, но очень может быть, что вашу пирамиду будет трясти сильнее, чем вы думаете. Провал проекта — это структурный провал, который влияет на всю компанию. Всё в вашей компании зависит от версии, которую вы представили, и запороть ее — значит совершить фатальную ошибку.
Культура разработки
Итак, у вас есть проект, повторюсь еще раз: это ваш кошмар. Состряпанная мной на скорую руку модель разработки продукта абсолютно концептуальна и не покрывает некоторых ключевых вопросов, которые вы должны понимать. Как вы собираетесь финансировать эту вещь? Где искать венчурный капитал? Где искать талантливых людей? Ваша жизнь превратится в бесконечную череду вопросов и решений, в безумном спринте вы, скорее всего, забудете всё, о чем я здесь пишу, и будете думать только о том, как поддерживать жизнь в вашем проекте, поэтому далее я буду упрощать. Описанная мной иерархия — это не модель создания грандиозного продукта; это лишь картина, демонстрирующая создание в вашей компании «культуры разработки». Именно ее вы реально создаете, работая над 1.0. Стабильная и интересная культура разработки, которая, если повезет, позволит вам в дальнейшем создавать новые и новые грандиозные продукты.