Ричард Шеридан - Работа мечты. Как построить компанию, которую любят

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вуаля!

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

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

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

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