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

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

Как же команда возвращается к первоначальной скорости, когда появляется необходимость снова вернуть проект на прежний темп через несколько месяцев? Как производится уменьшение масштаба, когда проект сходит до нуля? Возможно ли заново начать работу над проектом после нескольких месяцев заморозки или вернуться назад, чтобы добавить какое-то количество новых возможностей в уже завершенный проект? Для этого нужно обратиться к документации и стандартному процессу работы. Автоматизированные модульные тесты обеспечивают первый фундамент. Они отлавливают несоответствия, когда в код вносятся поправки. Если пара программистов возвращается к работе над проектом, делает изменения, а один или более тестов модулей не срабатывают, программисты сразу же узнают о том, что была допущена ошибка. Это освежает в их памяти решения, которые они приняли ранее. Управление кодом является также важной частью этого процесса, поскольку код изучается и дорабатывается в течение долгого времени таким количеством разных людей, что превращается в основную часть работы, отражающую всем ясный замысел, а не что-то запутанное, понятное только герою, придумавшему его.

То, что на ваших глазах начинает развиваться в индустрии программного обеспечения, представляет собой набор стандартов, напоминающих таковые, сформировавшиеся в строительной индустрии. Когда ремонтники заходят в более-менее современный дом, они могут быть уверены, что здесь через каждые сорок сантиметров стоят профили размером 2 × 4 и что электрическая сеть и связанный с нею выключатель (пример автоматизированного тестирования модулей) гарантируют соответствующую силу тока – в противном случае они расплавились бы и загорелись, если б этот предел был превышен.

Было бы просто прекрасно, если б по всем нашим текущим проектам необходимость увеличивать и уменьшать масштабы оказалась бы чудесно сбалансирована и точно соответствовала графику отпусков. Возможно, где-то так и есть, но здесь, на планете Menlo, это никогда не происходит гладко и прекрасно. Оставляя для себя резерв времени на случай, если понадобится добавить или убрать членов команды, работающих над проектом клиента, мы встраиваем в нашу систему буферные элементы. Это внутренние проекты, на которые можно направлять дополнительных сотрудников, или гибкие бизнес-договоренности с отдельными клиентами, которые не против, чтобы мы время от времени немного увеличивали или уменьшали количество сотрудников, занятых в их проекте, в обмен на скидки с нашей стороны.

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

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

Закон Брукса все еще применим к остальной части нашей отрасли. Если команда с традиционной организацией получает запрос об увеличении масштаба, единственная возможность для этого – сверхурочная работа. Неожиданно программисты начинают работать не по сорок-пятьдесят, а по восемьдесят-сто часов в неделю. Такой график может продлиться около недели, прежде чем уставшие программисты не начнут создавать больше проблем с качеством, чем новых функциональных возможностей. В этой точке местный резчик по камню начинает вырезать надгробие проекта, а идею закапывают. Вскорости происходит панихида по еще одному потерянному начинанию. Нашей отрасли это обходится примерно в 75 миллиардов долларов в год, согласно ежегодному «Протоколу хаоса»[46] от Standish Group.

Если нам нужно сделать больше, мы привлекаем больше людей. Это же так просто!

Хотя я уверен, что мы можем увеличивать масштаб по меньшей мере до 150 человек при текущей структуре, мы все равно будем продолжать совершенствоваться, чтобы приспособиться к большему числу сотрудников и более серьезной нагрузке. Проверьте мои слова через десять лет.

В процессе роста мы продолжали поддерживать, улучшать и расширять нашу культуру, чтобы достигнуть новых уровней численности персонала и проектной нагрузки. По состоянию на 2013 год, мы трижды увеличивали наше рабочее пространство втрое с момента основания компании. Размер команды вырос в десять раз. Для нас это является достаточно хорошим подтверждением того факта, что мы способны увеличивать масштаб. За десять лет между 2001 и 2011 годами произошло несколько глобальных катастроф, войн и экономических спадов, которые требовали от нас демонстрации способности также и уменьшать масштаб.

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

Когда Генри Форд построил завод Willow Run для выпуска бомбардировщиков B-24 во время Второй мировой войны, начальный темп производства в 1941 году составлял примерно один самолет в день. К 1944 году, ощущая серьезную необходимость в увеличении скорости, его команда улучшила систему и процессы и на том же самом заводе начала производить по одному бомбардировщику в час. Масштабирование процессно-ориентированной организации – это разумный подход. Масштабирование среды, основывающейся на героях, – безумие.