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

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

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

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

Термин «гиперрост» (12) теперь не так часто употребляют, как пару лет назад. Примерно раз в неделю вы можете услышать о нем. Но если обратитесь к Techmeme[4] – не увидите ни одного упоминания скачкообразного роста, что можно считать глобальным откатом в старые добрые времена. Только если речь не о единорогах[5] (13).

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

Когда я начинал работать в Uber, у нас было почти 1000 сотрудников, и каждые 6 месяцев становилось вдвое больше. Один мой давний коллега резюмировал: «Мы растем так быстро, что каждые полгода становимся новой компанией». Другой сразу заключил: «Вот почему наш бизнес-процесс с учетом роста персонала всегда отстает от желаемого результата на два квартала».

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

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

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

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

Представим картину: обучение нового сотрудника отнимает у инженера около 10 часов в неделю, а производительность новичков на треть ниже, чем у опытных. В результате на диаграмме 2.8 (по общему признанию, это наихудший сценарий) на двух неподготовленных приходится один обученный. Хуже того, производительность этих троих суммарно равна производительности 1,16 профи (2 х 0,33 для начинающих плюс 0,5 х 1 для обучающего).

Рисунок 2.7. Темпы роста персонала быстрорастущих компаний.

Также необходимо учитывать время, затраченное на найм новых сотрудников.

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

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

Однако затраты не ограничиваются только обучением и наймом:

1. На каждый дополнительный уровень инженеров необходимо разрабатывать и поддерживать вспомогательный уровень управления.

2. Каждые 10 инженеров нужно объединять в новую команду, что требует большей координации (14).

Рисунок 2.8. Больше сотрудников, больше клиентов, больше проблем.

3. Каждый инженер добавляет обязательств в общую копилку. Это увеличивает суммарный объем работы, от чего растет нагрузка на инструменты разработки.

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

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

Попробуем включить эти факторы в общие расчеты.

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

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