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

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

Многие отрасли промышленности сталкиваются с «истинами», подобными закону Брукса, которые все считают неопровержимым и действительным фактом, а не устаревшей традицией. Врачи многопрофильной больницы в Вене в XIX веке наверняка считали высокий уровень смертности матерей неопровержимой и неизбежной истиной. Орвилл Райт полагал, что самый большой самолет, который только можно будет построить, позволит переносить максимум двух пассажиров. Как для любой теоремы, для опровержения достаточно всего одного исключения.

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

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

Каждое предприятие сталкивается с вопросом масштабируемости при желании улучшить показатели бизнеса. Walmart искала информационную технологию, которая помогла бы решить вопрос масштабируемости розничной торговли со скидкой. McDonald’s обратилась к системности ингредиентов, меню и работы персонала. Zingerman’s выбрала видение для изменения масштаба от одного бизнеса до десятка и более. Southwest Airlines добилась масштабируемости за счет стандартизации на основе одного самолета, Boeing 737.

Думая о своей компании, задайте себе следующие вопросы.

• Возникают ли у вас проблемы, когда нужно найти правильный талант, соответствующий вашим нуждам?

• Регулярно ли вы разочаровываетесь в новых сотрудниках по прошествии нескольких месяцев их работы?

• Обладаете ли вы гибкостью, позволяющей передвинуть недостаточно загруженный талант в область высокой загрузки?

• Отказываетесь ли вы от новых возможностей, потому что не находите нужного вам таланта?

• Продолжаете ли вы наращивать сферы бизнеса, не увеличивая при этом число сотрудников?

• Поддерживаете ли вы команду занятой, если ее проект замедляется?

• Лежите ли вы без сна, пытаясь найти лучшие ответы на эти вопросы?

 

Практикуйте масштабирование

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

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

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

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

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

 

Настоящая способность к масштабированию работает в двух направлениях

Большинство бизнес-гуру рассматривают возможность масштабирования только в сторону увеличения. Когда кто-то задает вопрос «Реально ли изменить масштаб?», он думает об увеличении. Мы же считаем, что система, сформированная должным образом, дает возможность одинаково легко менять масштаб в обоих направлениях.

 

Увеличение масштаба

Скажем, клиент приходит в Menlo и просит, чтобы мы вдвое увеличили скорость работы над проектом, в котором задействовано четыре программиста.

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

Вуаля!

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

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

 

Уменьшение масштаба

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

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

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

 

Предусматривайте резерв, чтобы управлять масштабированием

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

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

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

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

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

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

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

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

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

 

Связь масштабируемости с ответственным отношением

• Если при масштабировании вы разрушаете качество, действительно ли вы масштабируете?

• Если при масштабировании вы разрушаете моральное состояние, дух и энергию вашей команды, действительно ли вы масштабируете?

• Если при масштабировании вы этим процессом создаете угрозу жизни людей, действительно ли вы масштабируете?

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

• Если вы можете увеличить масштаб, но не можете его уменьшить, уместно ли говорить, что вы способны к масштабированию?

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

 

Измеряя радость

Большинство посетителей думают, что все описанное выше очень классно, – пока не задумываются о его влиянии на стоимость. Тогда они начинают думать, что увеличение масштабов тем способом, которым пользуемся мы, делает процесс разработки ПО минимум в два раза дороже.

А чем они меряют стоимость? Если скоростью набора кода, то да, я полагаю, что у нас получается в два раза дороже. Если бы хоть кто-то из представителей нашей отрасли действительно верил, что скорость набора текста лежит в основе себестоимости разработки, каждое учебное заведение в стране сделало бы занятия по слепой печати обязательным условием для получения степени или даже внесло тест на скорость набора в список вступительных испытаний для абитуриентов.

В Menlo мы измеряем стоимость, сравнивая ее с финальным продуктом – радостью. Мы хотим, чтобы конечные пользователи однажды поблагодарили нас и сказали, что они любят то, что мы сделали для них. Большинство команд по разработке ПО никогда даже не приближаются к такому результату. Вы можете измерить что-то столь же нематериальное, как радость? Вряд ли. Зато вы можете оценить частоту использования, долгосрочное качество, доли рынка, удовлетворенность клиентов, доминирующее положение на рынке, радость или недовольство конечного пользователя (по крайней мере, опираясь на слухи) и отсутствие звонков с жалобами в службу поддержки. Если мы сделаем команду ответственной за получение всех этих видов результатов для каждого продукта, мы придем к радости.