Элегантная головоломка. Системы инженерного менеджмента. Уилл Ларсон

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

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

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

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

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

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

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

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

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

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

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

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

      Если для компоновки команд из восьми человек вы проводите по четыре перевода за год, каждый

6

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

7

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