В моем первом стартапе мы пользовались Microsoft’s SourceSafe. Хватит ржать! Он делал свою работу, и его было вполне достаточно для команды из шести инженеров, у которых не было ни секунды времени на то, чтобы побеспокоиться о контроле исходного кода. Конечно, он был адски медленным, и иногда мы теряли результаты целого рабочего дня из-за разных затыков, но ведь мы работали над нашим 1.0. Кто в такой период сможет найти время на то, чтобы подумать о более надежном инструменте?
Роланд!
Роланд был нашим младшим инженером и фанатом Perforce. Роланд сделал то, что сделали бы многие хорошие сотрудники стартапа. На выходных он установил сервер Perforce, перезаписал все наши инструменты разработки и запланировал совещание на 10 утра понедельника, пообещав всем пончики «Криспи Крим». Его сообщение звучало так: «Дело обстоит так и так… Теперь всё работает лучше. Всем спасибо, и угощайтесь пончиками!»
За одни выходные Роланд устранил крупный недостаток в нашем процессе (а именно паршивый инструмент) и заодно продемонстрировал еще один факт, касающейся иерархии 1.0:
Факт № 4: Каждый уровень двигает и оказывает влияние на те уровни, которые находятся по соседству с ним.
Верный признак правильной пирамиды в том, что один уровень тесно связан с другим. Посмотрите на любое изменение в уровнях «Люди», «Процесс» или «Проект» как на толчок в определенном направлении. Это движение требует компенсации за счет соседних уровней, иначе вся конструкция будет нарушена. Решение Роланда об изменении в уровне «Процесс» довольно сильно разозлило некоторых товарищей. Мы потеряли какое-то время на переписывание исходного кода пограничных участков, которые Роланд не учел, но уже через неделю всё было налажено. И даже самые громкоголосые противники перемены закончили тем, что спорили в кабинете Роланда о том, как мы еще можем улучшить наш процесс.
Если пирамида в вашей организации не регулируется на постоянной основе, чтобы сохранялось ее вертикальное положение, значит, что-то идет не так. Если новые сотрудники не тестируют проект, значит, они либо не верят в него, либо не понимают его. Если ваши инженеры не перестают спорить о непрерывном развитии софта, значит, наступает стагнация, которая стекает вниз и проникает в уровень «Проект», а также просачивается вверх и проникает в уровень «Продукт».
Самый существенный тревожный признак стагнации на этапе разработки 1.0 — это когда кто-то вдруг решает разработать органиграмму, которая будет демонстрировать «Кто за что отвечает». Да, инвесторам и сторонним организациям нужна такая органиграмма, благодаря ей они смогут понять, настоящие вы или нет, но вашей команде по созданию 1.0 она не нужна абсолютно. Доска в углу офиса, на которой перечислено кто что делает, — это и есть ваша органиграмма. Дефиниции и иерархия в органиграмме — это первый шаг к созданию культуры секретности в вашей организации. Это может сработать для Apple, но вы не Apple. Вы лишь надеетесь на лучшее и много работаете.