Работа мечты. Как построить компанию, которую любят
Шрифт:
Настоящая способность к масштабированию работает в двух направлениях
Большинство бизнес-гуру рассматривают возможность масштабирования только в сторону увеличения. Когда кто-то задает вопрос «Реально ли изменить масштаб?», он думает об увеличении. Мы же считаем, что система, сформированная должным образом, дает возможность одинаково легко менять масштаб в обоих направлениях.
Увеличение масштаба
Скажем, клиент приходит в Menlo и просит, чтобы мы вдвое увеличили скорость работы над проектом, в котором задействовано четыре программиста.
В нашем мире это выливается в прямое увеличение вдвое часов работы, необходимых
Вуаля!
Рабочее пространство помогает в решении вопросов масштабирования, так как команда может притянуть еще два стола и два компьютера поближе к участникам этого проекта и без какой-либо суеты собраться вместе. Затем для дальнейшего увеличения передачи знаний может быть использована «высокоскоростная голосовая технология». Поскольку базовые практики планирования и программирования являются одинаковыми для всех проектов, у нас нет необходимости проводить обучение новых членов команды любым технологиям, которые распространяются только на данный конкретный проект или основываются на личности. Тот факт, что каждый член команды разделяет систему убеждений Menlo, гарантирует отсутствие трений при таких перестановках.
Это настолько обычное явление в нашем мире, что никто в цепочке, включая нашего клиента, не поставит под сомнение обоснованность требования об увеличении количества сотрудников, работающих над проектом.
Уменьшение масштаба
Бывает, проекты приходится сокращать. Если клиенту нужно уменьшить скорость расходования бюджета или проект просто достиг такой точки, в которой требуется не так много работы, как прежде, процесс масштабирования проекта происходит аналогичным образом. Поскольку наши команды не основываются на «башнях знаний», и никто из разработчиков не владеет своей личной частью кода, и все работают во всех частях кода, и люди, которые перешли в другой проект, по-прежнему сидят в этой же комнате в пределах видимости и слышимости, у нас не происходит существенной потери информации о проекте.
Как же команда возвращается к первоначальной скорости, когда появляется необходимость снова вернуть проект на прежний темп через несколько месяцев? Как производится уменьшение масштаба, когда проект сходит до нуля? Возможно ли заново начать работу над проектом после нескольких месяцев заморозки или вернуться назад, чтобы добавить какое-то количество новых возможностей в уже завершенный проект? Для этого нужно обратиться к документации и стандартному процессу работы. Автоматизированные модульные тесты обеспечивают первый фундамент. Они отлавливают несоответствия, когда в код вносятся поправки. Если пара программистов возвращается к работе над проектом, делает изменения, а один или более тестов модулей не срабатывают, программисты сразу же узнают о том, что была допущена ошибка. Это освежает в их памяти решения, которые они приняли ранее. Управление кодом является также важной частью этого процесса, поскольку код изучается и дорабатывается в течение долгого времени таким количеством разных людей, что превращается в основную часть работы, отражающую всем ясный замысел, а не что-то запутанное, понятное только герою, придумавшему его.
То, что на ваших глазах начинает развиваться в индустрии программного обеспечения, представляет собой набор стандартов, напоминающих таковые,
Предусматривайте резерв, чтобы управлять масштабированием
Было бы просто прекрасно, если б по всем нашим текущим проектам необходимость увеличивать и уменьшать масштабы оказалась бы чудесно сбалансирована и точно соответствовала графику отпусков. Возможно, где-то так и есть, но здесь, на планете Menlo, это никогда не происходит гладко и прекрасно. Оставляя для себя резерв времени на случай, если понадобится добавить или убрать членов команды, работающих над проектом клиента, мы встраиваем в нашу систему буферные элементы. Это внутренние проекты, на которые можно направлять дополнительных сотрудников, или гибкие бизнес-договоренности с отдельными клиентами, которые не против, чтобы мы время от времени немного увеличивали или уменьшали количество сотрудников, занятых в их проекте, в обмен на скидки с нашей стороны.
Нам не сложно добавить больше членов команды, если потребность в сотрудниках превышает численность штата Menlo. У нас есть проверенная команда независимых субподрядчиков, которые помогают нам, когда в этом возникает потребность. Если нам нужно добавить новых людей к нашему общему потенциалу, мы можем запланировать экстремальное собеседование и нанять новых полноценных сотрудников. У нас всегда есть уйма претендентов, готовых откликнуться на призыв, когда нам это будет нужно, потому что с помощью наших экскурсий, лекций и работы с общественностью мы создали базу заинтересованных потенциальных сотрудников.
Принципы бережливого производства учат инженеров промышленной эксплуатации предусматривать небольшую недогрузку оборудования в своей системе, чтобы работать с максимальной эффективностью. Забавно – это предполагает, что мы должны учиться заботиться о своем оборудовании лучше, чем о людях. Множество предприятий работает при стопроцентной или близкой к таковой загрузке, а с учетом сверхурочной работы она иногда намного превышает 100 процентов. Симптомы этой одержимости включают рабочие отпуска, остановку проектов, когда всего один человек берет выходной, и постоянную сверхурочную и домашнюю работу. Я отказываюсь считать это правильным способом заботы о людях.
Закон Брукса все еще применим к остальной части нашей отрасли. Если команда с традиционной организацией получает запрос об увеличении масштаба, единственная возможность для этого – сверхурочная работа. Неожиданно программисты начинают работать не по сорок-пятьдесят, а по восемьдесят-сто часов в неделю. Такой график может продлиться около недели, прежде чем уставшие программисты не начнут создавать больше проблем с качеством, чем новых функциональных возможностей. В этой точке местный резчик по камню начинает вырезать надгробие проекта, а идею закапывают. Вскорости происходит панихида по еще одному потерянному начинанию. Нашей отрасли это обходится примерно в 75 миллиардов долларов в год, согласно ежегодному «Протоколу хаоса» [46] от Standish Group.
46
Ежегодный отчет, в котором указывается число провалившихся проектов, причины этих провалов и основные принципы, которые могут сократить количество неудачных проектов в сфере программного обеспечения. Прим. пер.