Читать книгу Элегантная головоломка. Системы инженерного менеджмента - - Страница 9

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

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

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

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

2.4.1. Больше инженеров, больше проблем

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

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

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

Представим картину: обучение нового сотрудника отнимает у инженера около 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. И теперь три нанятых специалиста суммарно дают меньше, чем один опытный.

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

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

Иногда очень низкая ценность означает отрицательная!

2.4.2. Системы выдерживают рост на один порядок

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

Понимание общего воздействия растущей нагрузки сводится к нескольким важным тенденциям:

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

2. Если штат удваивается каждые полгода, то нагрузка увеличивается на порядок каждые 18 месяцев. (А порой появление новых функций или продуктов увеличивает сложность работы гораздо быстрее.)

3. Количество поддерживаемых решений растет с течением времени по мере того, как добавляются команды, а «тривиальные» системы превращаются из неподдерживаемых второстепенных идей в фокусные точки для целых команд, поскольку достигают плато масштабирования (например, ApacheKafka[6], доставка почты, Redis[7] и т. д.).

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

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

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

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

Основной вопрос состоит в том, что нам со всем этим делать?

2.4.3. Способы управлять энтропией

Из книги «Проект “Феникс”» Джина Кима, Кевина Бера и Джорджа Спаффорда (15) я почерпнул такую идею: вы получаете профит от проектов только тогда, когда они заканчиваются. Чтобы добиться прогресса, прежде всего нужно убедиться, что хотя бы какие-то начатые проекты вы довели до финала.

Легко сказать – но трудно завершить проекты, когда все силы уходят на решение иных задач.

Давайте остановимся на найме персонала, поскольку он с обучением часто отнимает у команды больше всего времени.

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

ЕСЛИ УЖ КОМПАНИЯ РЕШИЛА МАСШТАБИРОВАТЬСЯ, ТО ОСТАНОВИТЬ РОСТ НЕЛЬЗЯ, НО ЕГО ТОЧНО МОЖНО ОБУЗДАТЬ ТАК, ЧТОБЫ В КОМАНДАХ ПЕРИОДЫ РАСШИРЕНИЯ ЧЕРЕДОВАЛИСЬ С ПЕРИОДАМИ АДАПТАЦИИ.

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

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

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

4

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

5

«Единорог» – это термин, используемый в индустрии венчурного капитала для описания частной стартап-компании стоимостью более 1 миллиарда долларов. Впервые термин был популяризирован венчурным капиталистом Эйлин Ли, основателем Cowboy Ventures, фонда венчурного капитала начального этапа, базирующегося в Пало-Альто, в Калифорнии.

6

ApacheKafka – распределенный программный брокер сообщений, проект с открытым исходным кодом, разрабатываемый в рамках фонда Apache. – Прим. пер.

7

Redis – резидентная система управления базами данных класса NoSQL с открытым исходным кодом, работающая со структурами данных типа «ключ – значение». Используется как для баз данных, так и для реализации кэшей, брокеров сообщений. Ориентирована на достижение максимальной производительности на атомарных операциях. – Прим. пер.