Элегантная головоломка. Системы инженерного менеджмента
В тексте упоминаются социальные сети Facebook и/или Instagram (организации, запрещённые на территории РФ).
Meta Platforms Inc. признана экстремистской организацией на территории РФ.
First published in English as An Elegant Puzzle: Systems of Engineering Management by Will Larson
Copyright © 2019 Will Larson
Published by permission of Will Larson (USA) and Nordlyset Literary Agency, LLC (USA)
via Igor Korzhenevskiy of Alexander Korzhenevski Agency (Russia)
© Шустова А. П., перевод на русский язык, 2023
© Оформление. ООО «Издательство «Эксмо», 2023
Благодарности
Хочу выразить особую благодарность некоторым людям.
Эту книгу я закончил писать за несколько месяцев до свадьбы и благодарен моей Лорел за ее мысли и поддержку. Спасибо Брианне Вулфсон и Тайлеру Томпсону, без которых эта книга не увидела бы свет. Наконец, спасибо Хоуп, любимой талантливой сестре, показавшей, что и я могу стать автором.
Предисловие
Свою первую запись в блоге я опубликовал 7 апреля 2007 года под заголовком «Поиск нашего стиля программирования». Текст был не очень хорош. В том же году я написал еще 69 статей. Последняя – «Миядзима и Хиросима» – представляла собой коллекцию фотографий из поездки по Японии, во время которой я преподавал английский язык. В следующем году я написал уже 192 поста. Но манера моего письма по-прежнему оставляла желать лучшего.
Потребовалось написать 200 статей и целое десятилетие, чтобы сделать достаточно ошибок и наконец-таки усовершенствовать стиль письма. Тогда уже о моем опыте стало интересно читать другим. Мне повезло, что на тот момент я работал в Stripe, где люди, как правило, достигали целей, которые вне компании могли бы показаться недосягаемыми (таких, как создание технологического журнала или публикация книги).
«Элегантная головоломка» – удачное сочетание опыта, почерпнутого в Stripe, десяти лет, проведенных за написанием постов и изучением лидерства и менеджмента. Плюс мне повезло с коллегами, которые предложили объединить мои посты в единое пособие.
Я надеюсь, что каждый, кто возьмет эту книгу в руки, извлечет для себя что-то полезное. Своими комментариями и мыслями вы можете поделиться со мной по электронной почте – я буду несказанно рад: [email protected].
Глава первая
Введение
Одни приходят в менеджмент из желания приносить пользу. Другие становятся руководителями, заключив циничное соглашение с самими собой: меняют стабильную должность на бо́льшие деньги и карьерный рост. Есть и те, кто идут в управленцы потому, что по горло сыты своим нынешним начальником и убеждены, что справились бы с его работой куда лучше.
Не скажу, какой из этих сценариев описывает мою ситуацию. Если мне вообще подходит хоть один.
Независимо от того, что привело вас в менеджмент, может возникнуть ощущение, что вы выбрали трудную профессию, ступили на тернистый путь. Квалифицированных специалистов не хватает, и редкая компания готова инвестировать в повышение профессионализма своих сотрудников.
Достойных учебных программ не так много, и опасения по поводу плохой подготовки менеджеров широко распространены. В начале управленческой карьеры мне повезло: один коллега назвал меня лучшим руководителем, с которым он работал. Другому потребовалось несколько лет совместного труда, чтобы назвать меня худшим.
Хоть плащ Давида уже и не скрывает сущность великанов-голиафов из Кремниевой долины, подавляющее большинство технологических компаний – всего лишь «куколки», мечтающие однажды стать «бабочками», то есть вырасти в крупный и успешный бизнес. На руководящих позициях сидят менеджеры, которые лишь учатся ремеслу и раз за разом получают от жизни неожиданные уроки. Для многих из них инженерный менеджмент начинается с кризиса, и их обучение – не что иное, как серия тяжких ударов.
Так было и в начале моего пути к идеальному руководству. Началось все с компании Digg в 2010 году. Тогда мне пришлось уволить несколько человек подряд. Это не привело к созданию строгих правил управления в моей голове. Я по-прежнему не представлял что делаю.
С самого начала я занимался самообразованием. Читал книги по менеджменту, казавшиеся мне хоть немного актуальными и практичными. Несколько из них вы найдете в разделе «Книги, которые я считаю очень полезными». Но редкие ответы, прочитанные на их страницах, тонули в постоянно растущем море вопросов. Потом мне довелось поработать в Uber (за два года их команда инженеров выросла с 200 до 2000 человек). Затем в Stripe, пережившей такой же стремительный рост. Лишь тогда я смог по-настоящему усовершенствовать свой подход к менеджменту, потому что столкнулся с бесконечным разнообразием проблем. Управление быстрорастущими компаниями спокойным не назовешь, но лучшей среды для обучения и развития было не найти.
Обретая опыт, я все больше ценил менеджмент, особенно инженерный. Стал рассматривать эту сферу как набор элегантных, полезных и важных головоломок.
Эта книга – сборник задач и их решений, над которыми мне посчастливилось поработать, и которые многому меня научили.
Все начинается с самого важного инструмента в моем наборе – организационного проектирования. Оно помогает расставлять людей по нужным местам, учит их самостоятельно принимать решения, брать ответственность за результат. Если систематически использовать этот инструмент и вносить умеренные изменения, откроются все дороги к масштабированию процессов.
Далее рассмотрим несколько фундаментальных «Инструментов» управления, которые я считаю полезными для самых разных сценариев. Эти методы варьируются от системного мышления до стратегического планирования, от метрик до миграции базы данных, от планирования карьеры до реорганизации компаний. Возможно, самое простое применение этой главы – быстро просмотреть изложенные в ней идеи и обратиться к ним, когда возникнет необходимость.
ЕСЛИ СИСТЕМАТИЧЕСКИ ИСПОЛЬЗОВАТЬ ЭТОТ ИНСТРУМЕНТ И ВНОСИТЬ УМЕРЕННЫЕ ИЗМЕНЕНИЯ, ОТКРОЮТСЯ ВСЕ ДОРОГИ К МАСШТАБИРОВАНИЮ ПРОЦЕССОВ.
В третьей главе «Подходы» рассматриваются обстоятельства, в которых вам, возможно, потребуется скорректировать методы управления. Вы узнаете, как адаптировать принципы менеджмента для быстрорастущих компаний и как управлять сотрудниками, когда желаемый уровень влияния выходит за рамки ваших полномочий. Надеюсь, информация из этой главы поможет вам найти альтернативный подход к работе в областях, в которых вам недостает уверенности и результативности.
За главой «Подходы» идет исследование понятия «Культура». Это раздел о практических методах создания инклюзивной команды или организации. В нем также рассматриваются несколько конкретных аспектов культуры, связанных с конфликтом «свободы для» и «свободы от», и так называемая «героическая культура».
Книга заканчивается главой «Карьера», посвященной собеседованиям, приему на работу и управлению эффективностью сотрудников. Многие менеджеры воспринимают подбор персонала как зону ответственности рекрутеров, а управление эффективностью – как вотчину специалистов по персоналу. Однако это мощные инструменты, которые вам стоит взять на вооружение.
Прочитав эту книгу, на следующий день вы не переступите порог офиса идеальным менеджером (меня по-прежнему радуют дни, когда я чувствую себя хоть немного некомпетентным). Но надеюсь, что по итогу вы задумаетесь о том, как грамотнее подходить к управлению. Что вам удастся поэкспериментировать с новыми методами, сделать еще несколько шагов на пути улучшения инженерного менеджмента.
Глава вторая
Организации
Организация представляет собой совокупность людей, работающих над достижением общей цели. Другими словами, это исследование возможностей, предпринятых командой из десяти, сотни или даже тысячи людей. Поначалу я хотел искушенно написать: «иногда у них это получается». Однако поистине удивительно то, что получается у всех.
Рисунок 2.1. Определение размеров команд и групп команд с использованием правил оптимальных размеров.
Просто некоторые справляются лучше других. Организационное проектирование – это попытка понять, почему одни генерируют энергию, а другие создают в основном проблемы: трения, разочарование и междоусобицы. Я считаю, что лучшие компании вырастают благодаря последовательной, логичной и эффективной работе.
Когда у меня возникает проблема, которую хочется решить быстро и дешево, я начинаю проектировать процесс. Проблема требует срочного решения или есть время подумать? Однако, если поиск ответа затягивается, и определенного подхода к решению задачи нет, а процесс слишком слаб – на помощь приходит организационный дизайн.
В этой главе рассматриваются наиболее эффективные, на мой взгляд, подходы к организационному проектированию и развитию менеджмента в целом. Если, дочитав до конца, вы поймаете себя на мысли, что все звучит слишком просто – я соглашусь! Считаю, что трудность здесь только в одном – сохранять мужество в сложных ситуациях.
2.1. Выбор размеров команды
Сначала я был менеджером одного отдела. Но когда стал директором целой компании, то столкнулся с нового рода проблемами, о которых никогда не задумывался. Сколько у нас должно быть команд? Стоит ли создавать новую под конкретную задачу? Или же поручить все старым? Как правильно определить их зоны ответственности?
С этими вопросами я подался в тогда еще малоизвестное искусство организационного дизайна. По мере изучения вопроса, я пришел к выводу, что одна из основных проблем заключается в определении размера команд. Вы поймете их величину по мере реорганизации (1), с учетом роста за счет найма и возникновения необходимости поддерживать новые проекты. Так или иначе, вам придется брать в расчет некоторые аспекты командного проектирования.
ПОД УПРАВЛЕНИЕМ ОДНОГО МЕНЕДЖЕРА ДОЛЖНО БЫТЬ ОТ ШЕСТИ ДО ВОСЬМИ ИНЖЕНЕРОВ.
Принимая во внимание, что я скептически отношусь к убеждению о существовании единого принципа определения размера команды, со временем мои требования сформировали подход, который помогает решить большинство возникающих вопросов. Он, в свою очередь, лег в основу инструкции о порядке действий. И то и другое отличается краткостью и, надеюсь, будет вам полезно!
Вот принципы, которыми я руководствуюсь для определения размера команд:
Под управлением одного менеджера должно быть от шести до восьми инженеров.
Тогда у них будет достаточно времени для того, чтобы активно обучаться, учиться действовать согласованно и выполнять задачи своей команды, следуя заданным стратегиям и структурным изменениям, основанным на корпоративном кодексе (2)(3).
У УПРАВЛЯЮЩЕГО МЕНЕДЖЕРАМИ В ПОДЧИНЕНИИ ДОЛЖНО БЫТЬ ОТ ЧЕТЫРЕХ ДО ШЕСТИ ЧЕЛОВЕК.
Ведущие инженеры (Технические лидеры). Менеджеры, у которых в управлении менее четырех подчиненных. Как правило, функции технических лидеров – проектирование и внедрение инноваций. Некоторым такая позиция позволяет уникальным образом задействовать их сильные качества, однако стоит учитывать ограниченные возможности карьерного роста. При продвижении по службе в менеджменте им потребуется больше времени на развитие управленческих навыков. С другой стороны, переквалифицироваться в инженеры тоже достаточно сложно, поскольку придется глубже вникнуть в технические детали.
Тимлиды. Менеджеры, ведущие более восьми или девяти человек. Обычно выступают в качестве и страхуют при возникновении проблем. Они слишком заняты, чтобы активно инвестировать время в собственную команду и ее прокачку. Разумно доверить менеджерам столь крупные команды на этапе перехода к более стабильной конфигурации, но не надо превращать это в норму.
У управляющего менеджерами в подчинении должно быть от четырех до шести человек.
Это дает достаточно времени для обучения, согласования проектов с заинтересованными сторонами и разумных инвестиций в свою организацию. С другой стороны, это занимает его в достаточной мере, чтоб не возникало соблазна нагружать сотрудников излишней работой.
Управляющие с нереализованным потенциалом. Менеджеры, оказывающие поддержку менее чем четырем другим менеджерам, должны либо находиться в стадии активного обучения, либо в борьбе с какой-то проблемной областью, либо в стадии перехода от поддержки инженеров к поддержке менеджеров. Иначе при слабой загруженности управленческими обязанностями они будут испытывать соблазн вмешиваться в повседневные рядовые задачи подчиненных.
Коучи. Как и в случае работы с большой командой инженеров, работа с большим числом менеджеров позволяет лишь сосредоточиться на решении спорных вопросов.
Рисунок 2.2. Команда, состоящая из двух групп, работающих по запросу, и разных штатных инженеров.
Оптимальный состав ротируемой группы – восемь инженеров.
Контроль над дежурными задачами осуществляется легче, если оптимальное число сотрудников двухуровневой поддержки 24/7 – восемь инженеров. Многие теперь используют групповые переписки в WhatsApp и Telegram, что накладывает ограничение на размер команды. Большое число участников чата перегружает переписку.
ОПТИМАЛЬНЫЙ СОСТАВ РОТИРУЕМОЙ ГРУППЫ – ВОСЕМЬ ИНЖЕНЕРОВ.
Общие ротации. Иногда необходимо объединить несколько команд в одну, чтобы собрать восемь инженеров. Так появляются проектные сотрудники. Это эффективное решение, но промежуточное, поскольку на долгую перспективу плохо работает. Большинству людей тяжело подхватывать проекты, с которыми они лишь детально знакомы.
Менее четырех человек для команды слишком мало.
Мне часто доводилось администрировать группы из одного или двух сотрудников, но каждый раз я жалел об этом. Подчеркиваю: каждый раз. Важная составляющая командной работы – возможность смягчать проблемные зоны ее отдельных участников. Коллектив менее чем из четырех человек представляет собой достаточно непрочную систему и функционирует так, будто каждый из них работает по отдельности. Руководя небольшим количеством людей, вы вынуждены подстраивать работу под график дежурных смен, перерывы и отпуска ее участников.
Маленькие команды очень хрупки, и при малейшем сбое они возвращаются от инновационных разработок к рутинному исполнению своих технических обязанностей.
Сочетайте инновации и техническое обслуживание. Для внедрения инноваций принято формировать новую команду, пока те, что есть, утопают в однообразных операционных задачах. И я делал так в прошлом, но решил работать силами существующих команд (5). При таком подходе принимать решения нужно очень обдуманно. Потребуется некоторая смелость, зато вы сохраните в команде высокий моральный дух и культуру обучения. Кроме того – избежите появления двухуровневой классовой системы из новаторов и обслуживающего персонала.
МАЛЕНЬКИЕ КОМАНДЫ ОЧЕНЬ ХРУПКИ, И ПРИ МАЛЕЙШЕМ СБОЕ ОНИ ВОЗВРАЩАЮТСЯ ОТ ИННОВАЦИОННЫХ РАЗРАБОТОК К РУТИННОМУ ИСПОЛНЕНИЮ СВОИХ ТЕХНИЧЕСКИХ ОБЯЗАННОСТЕЙ.
Собрав воедино эти руководящие принципы, я разработал удивительно простой и эффективный порядок действий:
• Формируйте команды из шести–восьми человек.
• Чтобы создать дополнительную команду, увеличьте существующую до восьми–десяти человек, а затем разделите ее на две по четыре или пять человек.
• Никогда не создавайте «пустые» команды (два-три человека).
• Никогда не просите одного менеджера вести более восьми человек.
Это лишь рекомендация, помогающая определиться с размерами команд, а не жесткое правило, не подразумевающее исключений. В любой ситуации контекст заслуживает тщательного изучения, но по моему опыту, долгосрочные издержки работы с исключениями перевешивают то, что я когда-то считал их достоинствами.
2.2. Старайтесь формировать высокоэффективные команды
Мой друг уже шесть месяцев ведет группу из 60 инженеров. Вполне логично, что большинство команд в организации такого размера чувствуют потребность в срочном найме персонала. Стоит ли одновременно дополнительно привлекать людей во все нуждающиеся отделы, или максимум в один-два, пока их запросы не будут полностью удовлетворены?
Это отличный вопрос, и он касается очень сложного аспекта руководства организацией. Увлекательно ощущать себя первооткрывателем, учиться у всех и каждого. Иногда возникает необходимость реорганизовать команду (6), что болезненно, хоть и быстро решается. Гораздо труднее сохранить вовлеченность, когда вы уже приобрели базовые знания и пытаетесь найти место для реализации конкретных планов. Придерживаться выбранного заранее курса чревато последствиями, когда речь идет о развитии организации. Некоторым отделам всегда нужно больше, чем вы можете предоставить.
Когда говорят о масштабировании, разговор обычно сводится к найму персонала. Хотя я считаю, что найм – очень серьезный инструмент в среде растущих организаций. Мне кажется, мы слишком часто к нему прибегаем. В течение последнего года я разбирался, в каких случаях найм принесет наибольшую пользу. Так был разработан алгоритм из вопросов, помогающий определить, что нужно команде для повышения производительности.
Рисунок 2.3. Четыре состояния команды.
2.2.1. Четыре состояния команды
Руководящие принципы начинаются с терминов для описания команд и их работы в данном контексте.
Команды могут находиться в одном из четырех состояний:
Спад производительности: каждую неделю количество задач в бэклоге растет. Как правило, сотрудники работают на пределе, но не добиваются существенного прогресса, моральный дух снижен, а заказчики громко выражают недовольство.
Стагнация: команда закрывает ключевые задачи, но не гасит технические долги и не приступает к новым крупным проектам. Моральный дух немного выше, но сотрудники по-прежнему работают на пределе, а заказчики могут казаться счастливее только от того, что поняли: никакие запросы ни к чему не приведут (поэтому они перестают выражать недовольство).
Погашение технического долга: все ресурсы уходят на техническое сопровождение, что провоцирует эффект «снежного кома». Каждая закрытая задача ведет к увеличению времени для погашения прочих долгов.
Внедрение инноваций: команда трудится над новыми проектами, когда объем технических доработок стабильно низок, моральный дух на высоте, а большая часть сил направлена на удовлетворение новых потребностей заказчиков.
Команды хотят двигаться от спада производительности к инновациям, в то время как энтропия тянет их вниз. Каждая стадия требует особого подхода.
Рисунок 2.4. Четыре этапа прогресса команды – от спада производительности до внедрения инноваций.
В рамках предложенной структуры команды переходят на новый уровень исключительно через принятие соответствующего системного решения. И это ваша задача как менеджера – определить, как лучше действовать на данном этапе, инициировать процесс, а затем оказать коллективу посильную поддержку, чтобы максимизировать возможность положительной трансформации. Если вы сосредоточитесь на тактической поддержке до того, как определитесь с планом действий, то истощите свои силы. При этом далеко не факт, что избежите проблем.
Вот список стратегических решений, которые я нашел эффективными на каждой из стадий, а также некоторые идеи о том, как поддержать команду в процессе реализации:
1. Когда команда переживает спад производительности, системное решение состоит в том, чтобы нанять больше людей и дожидаться перехода в стагнацию. Оказывайте тактическую поддержку, говоря заказчикам о прогнозируемых результатах. Вселяйте в них оптимизм, рассказывая о быстрых победах, которых может достичь ваш коллектив.
Предостережение: корректировка системы заключается в том, чтобы нанимать новых сотрудников, увеличивая общий потенциал компании. Вместо этого люди, принимающие решения, порой пытаются выжать как можно больше из действующего персонала. Не лучшая практика, на мой взгляд. Сотрудники не взаимозаменяемы и, как правило, находятся на своих местах. Потому я скептически отношусь к переназначению. Кроме того, дискуссии такого рода не могут не вызывать напряжение, даже когда все участники уважают и доверяют друг другу.
2. Когда команда в стагнации, системное решение состоит в том, чтобы объединить усилия и закрыть как можно больше задач из бэклога. Сокращать объем параллельной работы до тех пор, пока сотрудники не перейдут к погашению долгов (например, пока они не ограничат объем выполняемой работы). Основное внимание здесь уделяется тому, чтобы изменить взгляд людей на производительность. Трансформировать индивидуальный взгляд на эффективность в командный.
3. Когда команда занята погашением технического долга, систему нужно скорректировать путем увеличения времени на доработки. Все уже получается, вам просто нужно дать возможность расти совокупному объему завершенных проектов. Тактически попытайтесь найти способы поддержать заказчиков и закрывать долги одновременно, чтобы избежать ситуации, в которой команда нырнула с головой в доработки, отодвинув в сторону интересы пользователей. Это особенно актуально. Если команда сначала отставала, теперь подчищает хвосты, и заинтересованные стороны, вероятно, ждут не дождутся, когда им начнут поставлять новые проекты. Ваша обязанность – не допустить, чтобы это нетерпение привело к регрессу!
4. Внедрение инноваций – это решение отличается от предыдущих. Вы номинально достигли верха цепочки, но по факту все еще нуждаетесь в системной корректировке. Речь идет о том, чтобы поддерживать комфортный ритм внутри команды. Так сотрудники смогут повышать качество работы, постоянно внедрять инновации и избегать откатов. С тактической точки зрения убедитесь, что работа, которую выполняет ваша команда, востребована, ведь самый простой путь покончить с инновациями – рассматривать сотрудников как команду, работающую на исключительно научные интересы. Это неизбежно ведет к оттоку финансирования, что, конечно, не является вашей целью.
Должен подчеркнуть, что любая качественная трансформация требует времени. Статистические помехи накапливались на протяжении нескольких месяцев или лет, а вам предстоит изменить ситуацию в корне. Однако те же свойства, которые замедляли реализацию корректировок, сделают новую систему долговечнее.
Самое трудное – сохранить веру в свой план, как личную, так и организации в целом. В какой-то момент возникнет соблазн избавиться от ответственности, перейти на другую позицию или, возможно, сменить работу, но тогда вы пропустите ту часть, где вам предстоит учиться. Придерживайтесь выбранного пути.
2.2.3. Консолидируйте усилия
Как руководитель организации вы будете иметь дело с несколькими командами, каждая из которых находится в определенной точке. Кроме того, ваши ресурсы для внедрения изменений ограничены, обычно их недостаточно для одновременного продвижения всех отделов. Многие пытаются проводить изменения одновременно каждым из них. Располагая ограниченным ресурсом, пытаются распределить его на всех, руководствуясь ложным чувством справедливости. В итоге никто ничего не получает.
В рамках имеющихся ресурсов расставляйте приоритеты и корректируйте работу подразделений по отделу за раз. Если большинство из них переживает спад производства, нанимайте сотрудников в одну команду до тех пор, пока она не будет укомплектована достаточно, чтобы перейти в стагнацию – и только тогда переходите к следующей. Такой подход справедлив для любых ограниченных ресурсов, но особенно важен в вопросах найма.
Появление новых людей негативно влияет на сплоченность в коллективе. Я обнаружил, что лучше быстро набрать новых членов команды и дать ей время на сплочение. Организация не перестанет расти, но каждая команда будет органично развиваться.
2.2.4. Долговременный успех
Такой подход к взращиванию замечательных компаний идет вразрез с привычкой быстро решать проблемы. Хотя все происходит медленно, я обнаружил, что последовательные шаги ведут к постоянному, реальному улучшению качества жизни и производительности организации. Самое главное, что улучшения сохраняются достаточно долго, чтобы накапливаться. Это закрепляет долговременное превосходство.
Рисунок 2.5. Прибыль при консолидации инвестиций по сравнению с распределением инвестиций.
2.3. Аргументы против глобальной оптимизации сверху вниз
После того как я опубликовал исследование под заголовком «На пути к высокопроизводительным командам»[1] (8), многие задавали мне один и тот же вопрос: «Как только команда погасит технический долг, не должны ли лишние работники перейти в другие подразделения?»
В этом есть логика и смысл, потому что в команде, за которой не числится технического долга, оказывается слишком много сотрудников. Если говорить с точки зрения глобальных приоритетов. Когда дела обстоят так не в одном, а сразу в нескольких отделах, в организации наблюдается перевес инженеров, сконцентрированных на прошлых проблемах, и недостаток тех, кто способен заниматься насущными вопросами.
Это важная проблема, требующая решения!
Но сперва позвольте объяснить, почему я скептически отношусь к перераспределению сотрудников под глобальные приоритеты, а затем я предложу пару альтернативных подходов к решению этой головоломки.
2.3.1. Команда – первый приоритет
По сути, я считаю, что устойчивая производительность обеспечивается высокоэффективными командами. Их распад приводит к значительному снижению производительности, даже если сотрудники не уходят из компании. В моем мировоззрении такие коллективы очень ценятся, и я весьма неохотно их разбиваю.
МОРАЛЬ ЗАКЛЮЧАЕТСЯ В ТОМ, ЧТО НУЖНО УЧИТЫВАТЬ ЗАТРАТЫ НА ОТЛАДКУ РАБОЧИХ ПРОЦЕССОВ ПОСЛЕ ВНЕДРЕНИЯ ИЗМЕНЕНИЙ, А НЕ В ТОМ, ЧТО ИЗМЕНЕНИЙ НЕ ДОЛЖНО БЫТЬ ВОВСЕ.
Для формирования команды требуется много времени. Когда группа работает вместе в течение нескольких лет, ее участники понимают друг друга и знают, как поистине замечательно поощрять коллег на пути к успеху. При перемещении отдельных сотрудников из одного коллектива в другой может потребоваться время на адаптацию, особенно на ранних стадиях формирования при значительных различиях в командной культуре. Не надо бояться менять состав – отсутствие перемен ведет к застою. Просто поддержание сплоченности требует сдержанного роста.
Иногда хочется расти быстрее, чем позволяет сплоченная команда, и это нормально! Мораль заключается в том, что нужно учитывать затраты на отладку рабочих процессов после внедрения изменений, а не в том, что изменений не должно быть вовсе. Вот почему в предложенной модели (9) рекомендуется в первую очередь нанимать персонал в команды, обремененные техническим долгом, а не в команды, занимающиеся инновациями. Это позволяет избежать затрат на повторную адаптацию высокопроизводительных команд.
2.3.2. Постоянные затраты
Еще одна причина, по которой я воздерживаюсь от перевода сотрудников из высокоэффективных команд, заключается в том, что у большинства из них постоянные затраты высоки, а переменные – относительно невелики. Перемещение одного человека может привести к тому, что в коллективе уже на стадии инноваций снова начнется спад производства, и тогда ни отдающая, ни принимающая стороны не будут преуспевать. Это особенно верно для отделов, ответственных за продукты и услуги.
По своему опыту я вывел правило, что для нормальной ротации команде требуется восемь инженеров. Поэтому неохотно внедряю изменения в любую команду, в которой меньше восьми человек. Однако ситуации складываются разные: будь то усилия по предотвращению банкротства, достижение договоренностей до подписания контрактов, запросы на поддержку от других команд и т. д.
Есть несколько команд с очень низкими фиксированными затратами: стартап без пользователей, отдел, поддерживающий уже не работающий продукт. Полагаю, правила для них должны быть другими. Хотя в действительно успешных компаниях подобных отделов немного.
2.3.3. Наличие избыточных производительных мощностей
Чтобы побудить людей к оптимизации глобальной эффективности, требуется более глубокое понимание того, как достигается производительность компании и чем она отличается от личной продуктивности. Я твердо верю, что не стоит предоставлять больше ресурсов команде с видимым наличием избыточного технического потенциала. Но не уверен в обратном – что нужно изымать ее потенциал.
Рисунок 2.6. Постоянные затраты на управление командой.
Ожидаемое время выполнения новой задачи стремится к бесконечности, поскольку загрузка команды приближается к 100 %, а большинство команд сильно зависят друг от друга. То есть, проще говоря: вы рискуете замедлить работу одних, переводя им избыток ресурсов других, потому что это рождает производственные ограничения в других командах.
ЧТОБЫ ПОБУДИТЬ ЛЮДЕЙ К ОПТИМИЗАЦИИ ГЛОБАЛЬНОЙ ЭФФЕКТИВНОСТИ, ТРЕБУЕТСЯ БОЛЕЕ ГЛУБОКОЕ ПОНИМАНИЕ ТОГО, КАК ДОСТИГАЕТСЯ ПРОИЗВОДИТЕЛЬНОСТЬ КОМПАНИИ И ЧЕМ ОНА ОТЛИЧАЕТСЯ ОТ ЛИЧНОЙ ПРОДУКТИВНОСТИ.
Кроме того, в защиту наличия избыточных мощностей скажу, что команды широко используют свободный потенциал, улучшая продукты в зоне своей ответственности. В качестве бонуса они, как правило, производят улучшения с минимальными затратами на координацию, так что локальная производительность не создает помех для всей системы в целом.
Самое главное – команды с наличием избыточных производительных мощностей функционируют как организационный отладчик: вам не нужно учитывать их при регулировке общей пропускной способности организации. Я обнаружил, что гораздо проще работать с парой ограничений одновременно, продвигаясь вперед без необходимости пересматривать предыдущие ограничения.
«Цель. Процесс непрерывного улучшения» Элияху М. Голдратта и Джеффа Кокса[2] (10) и «Азбука системного мышления» Донеллы Х. Медоуз[3] (11) – феноменальные книги на эту тему.
2.3.4. Расширение сферы деятельности и ротация сотрудников
Как это работает на практике? Я нахожу наиболее полезным перераспределять задачи между командами, сохраняя состав команд. Если у команды есть свободные ресурсы, постепенно перекладывайте на них ответственность за новые задачи, тогда они начнут оптимизировать процессы с учетом повышенной загруженности. Лучше не торопиться, чтобы сохранить спокойную обстановку. Но когда стоит выбор между быстрым переводом сотрудников или резкой сменой деятельности, на мой взгляд, последнее более эффективно и менее разрушительно.
Расширение сферы деятельности работает лучше, чем перевод из команды в команду, потому что позволяет избежать затрат на адаптацию сотрудников и сохраняет паттерны поведения в системе. Это, в свою очередь, поддерживает неизменность существующей ментальной модели. А если такой подход не сработает, вы сможете снизить загрузку с меньшими потерями, чем в случае кадровых перестановок.
РАСШИРЕНИЕ СФЕРЫ ДЕЯТЕЛЬНОСТИ РАБОТАЕТ ЛУЧШЕ, ЧЕМ ПЕРЕВОД ИЗ КОМАНДЫ В КОМАНДУ, ПОТОМУ ЧТО ПОЗВОЛЯЕТ ИЗБЕЖАТЬ ЗАТРАТ НА АДАПТАЦИЮ СОТРУДНИКОВ И СОХРАНЯЕТ ПАТТЕРНЫ ПОВЕДЕНИЯ В СИСТЕМЕ.
Другой действенный метод, в чем я убедился лично, заключается в ротации людей на определенный период в зоны, где нужна помощь. Фиксированный срок позволяет временным сотрудникам сохранить свою идентичность и принадлежность к нынешней команде, полностью сосредоточившись на оказании помощи, вместо того чтобы разделять свое внимание между выполнением работы и попыткой влиться в новый коллектив. К тому же это безопасный способ понять, какой на самом деле излишний потенциал есть в команде (из которой переводится на время сотрудник).
Один мой коллега заметил, что некоторые компании благополучно перешли к так называемой модели «роя» всей организацией, не только на уровне отдельных команд. Надеюсь, когда-нибудь я услышу о людях, успешно идущих в другом направлении. В организационном проектировании интереснее всего то, что существует множество различных эффективных подходов.
2.4. Продуктивность в эпоху гиперактивного роста
Термин «гиперрост» (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) я почерпнул такую идею: вы получаете профит от проектов только тогда, когда они заканчиваются. Чтобы добиться прогресса, прежде всего нужно убедиться, что хотя бы какие-то начатые проекты вы довели до финала.
Легко сказать – но трудно завершить проекты, когда все силы уходят на решение иных задач.
Давайте остановимся на найме персонала, поскольку он с обучением часто отнимает у команды больше всего времени.
Если уж компания решила масштабироваться, то остановить рост нельзя, но его точно можно обуздать так, чтобы в командах периоды расширения чередовались с периодами адаптации. Когда в одном отделе набирается восемь инженеров, вы перейдете к найму сотрудников в другой (или вообще создадите новый). После докомплектации по мере формирования вся группа пройдет обучение и со временем выйдет на нужные показатели эффективности.
ЕСЛИ УЖ КОМПАНИЯ РЕШИЛА МАСШТАБИРОВАТЬСЯ, ТО ОСТАНОВИТЬ РОСТ НЕЛЬЗЯ, НО ЕГО ТОЧНО МОЖНО ОБУЗДАТЬ ТАК, ЧТОБЫ В КОМАНДАХ ПЕРИОДЫ РАСШИРЕНИЯ ЧЕРЕДОВАЛИСЬ С ПЕРИОДАМИ АДАПТАЦИИ.
Время от времени можно менять инженеров, сосредоточенных на найме, чтобы дать им время восстановиться. Если человек проводит огромное количество собеседований на потоке, он может выгореть. Сложится ситуация, что в прошлом году он проводил собеседования просто блестяще, а сейчас плохо отзывается о кандидатах или отклоняет каждого нового соискателя.
Если ваш инженер проводит более трех собеседований в неделю, полезно проявлять милосердие и давать ему месячный перерыв от собеседований каждые три или четыре месяца.
У меня меньше сведений о том, как оптимизировать процесс обучения, однако сегодня многие крупные компании инвестируют как в учебные центры для новых сотрудников, так и в регулярные образовательные мероприятия.