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

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

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

Существует и исключение: ситуация, когда вы используете некоторые базовые показатели в качестве контракта со второй стороной, возможно, в рамках SLO[12]12
  SLO (англ. service-level objective, «цель уровня обслуживания») – ключевой элемент соглашения об уровне обслуживания (англ. service-level agreement, SLA) между поставщиком услуг и клиентом. – Прим. пер.


[Закрыть] (16) – тогда вы, вероятно, захотите обсудить эти показатели более подробно.

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

Существуют десятки различных подходов к настройке показателей, к примеру, OKR[13]13
  OKR (от англ. Objectives and Key Results «цели и ключевые результаты») – метод, используемый в современном менеджменте для управления проектами. – Прим. пер.


[Закрыть] (17), и этот формат сгодится поначалу в качестве легкой структуры. Если вы считаете другие подходы более простыми или действенными, расскажите мне!

3.5. Руководство широкими организационными изменениями с помощью метрик

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

И в Stripe, и в Uber у меня была возможность управлять расходами на инфраструктуру. (Позвольте мне вставить ссылку на удивительный пост Райана Лопополо в блоге «Эффективное использование зарезервированных инстансов AWS» [англ. Effectively Using AWS Reserved Instances]). (19) Люди, которые не задумывались об этой проблеме, часто по умолчанию считают ее скучной, но по мере углубления в нее я обнаружил, что это богатая почва для изучения ведущих организационных перемен.

МЕТРИКИ – ЭТО ЧРЕЗВЫЧАЙНО ЭФФЕКТИВНЫЙ СПОСОБ РУКОВОДИТЬ ИЗМЕНЕНИЯМИ ПРАКТИЧЕСКИ В ОТСУТСТВИЕ КАКИХ-ЛИБО ОРГАНИЗАЦИОННЫХ ПОЛНОМОЧИЙ.

А еще – хороший пример того, как управлять изменениями с помощью метрик!

Стоимость инфраструктуры – отличный пример базового показателя (20). Когда вас попросят взять на себя ответственность за общие затраты компании на инфраструктуру, вы начнете с цели, примерно такой: «Поддерживать затраты на инфраструктуру на уровне текущей доли от чистой выручки в размере 30 %». (Я взял случайное число для примера, поскольку реальный процент будет зависеть от вашей отрасли и зрелости, но я обнаружил, что лучше срабатывает его привязка к чистой выручке, а не к определенной сумме в долларах.)

Подход, который я нашел эффективным, заключается в следующем:

1. Исследование: Первый шаг – получить данные в удобном для изучения формате в вашем хранилище данных, базе данных SQL или даже в таблице Excel. Погрузившись в цифры, потратьте время на то, чтобы просмотреть, прочувствовать их. Ваша цель на этом этапе – определить возможности для изменений. Например, вы можете обнаружить, что большая часть затрат приходится на пакетный конвейер и что хранилище данных стоит на удивление дешево, что позволит вам определить дальнейшие шаги.

2. Погружение: Как только вы выделите 3–4 основных статьи затрат, углубитесь в понимание того, откуда они берутся и как формируются. Затраты на пакетную обработку могут зависеть от количества заданий, общего объема хранимых данных или разработки нового продукта, а могут быть в полной мере обусловлены парой дорогостоящих заданий. Серьезное погружение поможет выстроить ментальную модель, а также положит начало отношениям между вами и командами, с которыми вы захотите сотрудничать наиболее тесно.

3. Атрибут: Для большинства показателей уровня компании (стоимость, задержка, скорость разработки и т. д.) первый шаг погружения позволит выявить одну команду, которая номинально отвечает за конкретный показатель. Обычно все не очень понятно на первый взгляд, и эта команда как бы прячется за завесой. Если отбросить завесу в сторону, станет очевидно: производительность команды на самом деле зависит от десятков других команд. Например, у вас может быть команда облачных инженеров, которая отвечает за подготовку виртуальных машин, но они не пишут код для виртуальных машин. Легко спустить метрику затрат облачной команде, но это просто снимет ответственность с менеджера перед ней. Куда полезнее помочь им создать систему атрибуции[14]14
  Показатели должны быть привязаны к тем, кто на них влияет. – Прим. науч. ред.


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

4. Контекстуализация: Вооружившись данными об атрибуции, начните создавать контекст вокруг результатов работы каждой команды. Самый распространенный инструмент – сопоставительный анализ. Одно дело, когда команда знает, что тратит 100 000 долларов в месяц, и совсем другое – знать, что сотрудники тратят 100 000 долларов в месяц и что эта сумма вторая по величине из списка расходов всех 47 команд в компании. Сопоставительный анализ особенно эффективен, поскольку автоматически адаптируется к изменениям в поведении. В некоторых случаях анализ всех команд может показаться слишком грубым, и лучше провести сравнительный анализ с небольшой группой команд. Например, вы можете захотеть определить когорты для интерфейсных, серверных и инфраструктурных команд, с учетом того, что у них очень разные профили затрат.

5. Побуждение: Как только вы создадите контекст с помощью данных, чтобы люди могли их интерпретировать, следующий шаг – начать подталкивать их к действию! Панели мониторинга очень эффективны для анализа, но проблема с базовыми показателями заключается в том, что люди не думают о них большую часть времени, а значит, могут и полностью забыть. Я нашел эффективной отправку уведомлений, обычно по электронной почте, командам, чьи показатели недавно изменились, как с точки зрения абсолютных изменений, так и с точки зрения их показателей по сравнению с когортой. Это гарантирует, что каждый раз, когда вы отправляете письмо команде, оно содержит важную информацию, на основании которой они должны действовать! Самое мощное в побуждении то, что простая констатация изменения подталкивает к действию, и для этого не требуется никаких организационных полномочий. (Подробнее об этой теме читайте в «Nudge. Архитектура выбора» Ричарда Х. Талера и Касса Р. Санстейна[15]15
  Талер Ричард, Санстейн Касс. Nudge. «Архитектура выбора». М.: МИФ, 2018. 240 с.


[Закрыть].) (21)

6. Базовые показатели: В лучшем случае вам удастся добиться необходимого организационного воздействия с помощью контекстуализированных побуждений, но иногда их недостаточно. Следующим шагом станет работа с ключевыми командами по согласованию базовых показателей их эффективности. Это полезно, поскольку гарантирует, что базовые показатели находятся в центре внимания, а также дает командам мощный инструмент для обсуждения приоритетов со всеми заинтересованными сторонами. В некоторых случаях это действительно требует определенных организационных полномочий, но я обнаружил, что люди повсеместно хотят быть ответственными. Пока вам удается выделить время, чтобы встретиться с ключевыми командами и объяснить важность цели, это не потребует больших организационных полномочий.

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

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

3.6 Технический переход: Единственное масштабируемое решение проблемы технического долга

Самым интересным переходом, в котором я участвовал, был переход Uber от сервисов, управляемых с помощью Puppet[16]16
  Puppet – это кросс-платформенная система, позволяющая системным администраторам выполнять общие задачи с использованием кода. – Прим. пер.


[Закрыть], к полностью автономной модели предоставления услуг, в которой любой инженер компании мог запустить новую услугу в два клика. Они не только могли, но и делали это, создавая по несколько сервисов каждый день к моменту завершения обслуживания, и каждый недавно нанятый инженер мог запустить сервис с нуля в первый же день.

Рисунок 3.5. Этапы технического перехода.

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

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

Технические переходы становятся необходимыми, и их частота удручающе растет по мере старения кодовой базы и роста бизнеса: большинство инструментов и процессов поддерживают рост только на один порядок (22), прежде чем становятся неэффективными, поэтому быстрый рост превращает переходы в образ жизни. Это происходит не потому, что у вас плохо организованы процессы или вы используете неправильные инструменты – совсем наоборот. Тот факт, что что-то перестает работать при значительно увеличенном масштабе, является признаком того, что оно было спроектировано соответственно предыдущим ограничениям, а не переразмеренно (23).

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

3.6.1. О важности переходов

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

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

ПЕРЕХОД – ЭТО ЕДИНСТВЕННЫЙ МЕХАНИЗМ ЭФФЕКТИВНОГО УПРАВЛЕНИЯ ТЕХНИЧЕСКИМ ДОЛГОМ ПО МЕРЕ РОСТА КОМПАНИИ И УСЛОЖНЕНИЯ КОДА.

Каждый переход направлен на создание технических преимуществ (вы больше не должны использовать один сервер для всех задач!) или сокращение технического долга (код после апрува гарантированно сохранится, даже при масштабном сбое!). При этом формально у таких преимуществ шаткие позиции: снижение непосредственного вклада сегодня в обмен на увеличение мощностей завтра. Это затрудняет планирование перехода, и по мере того, как ваши системы становятся больше, растет и цена перехода. У сотрудников Google есть присказка «бежать, чтобы оставаться на месте», описывающая команду, все возможности которой расходуются на обновление зависимостей и шаблонов, так что группа не может продвигаться вперед в работе по продукту/системе, которой она владеет. Тратить все свое время на переходы – это крайность, но у каждой компании среднего размера есть длинная очередь переходов, которые она не может выполнить: переход от виртуальных машин к хранилищам, развертывание автоматического отключения, переход на новый инструмент сборки… список можно продолжать бесконечно.

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

3.6.2. Правильное выполнение переходов

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

Снижение риска

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

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

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

Внедрение инструментов

После того как вы проверили решение, которое поможет устранить предполагаемую проблему, пришло время «заточить» инструменты. Многие люди начинают переход с создания тикетов контроля для внедрения командами, но лучше притормозить и разработать инструментарий для программного перехода на 90 % (24). Это радикально снижает затраты на переход для организации в целом, что повышает вероятность успеха и создает больше возможностей для перехода.

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

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

Окончание процесса

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

Начните с остановки кровотечения, то есть сделайте так, чтобы весь недавно написанный код отвечал новым требованиям. Улучшите ваши линты[17]17
  Линт (англ. lint) – первоначально – статический анализатор для языка программирования Си, который сообщал о подозрительных или непереносимых на другие платформы выражениях. В начале XXI века термин стал нарицательным для всех программ такого типа. Как инструмент программа лишь анализирует статический исходный код, не скомпилированный, в отличие от отладчиков. – Прим. пер.


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

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

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

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

3.7. Проведение инженерной реорганизации

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

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

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

Предостережение: это скорее пища для размышлений, чем готовый рецепт!

Вот мой подход к планированию организационных изменений:

1. Убедитесь, что организационные изменения – это правильный инструмент.

2. Определите количество сотрудников на ближайший год.

3. Установите целевое соотношение руководителей и подчиненных.

4. Определите логические команды и группы команд.

5. Спланируйте штатное расписание для команд и групп.

6. Возьмите на себя обязательство двигаться вперед.

7. Запустите изменения.

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

Есть два вида оптимальной реорганизации:

• Та, что решает структурную проблему.

• Та, что вообще не происходит.

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

Вот мой контрольный список для определения уместности реорганизации:

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

Рисунок 3.6 Реструктуризация организаций по мере их роста.

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

3. Проблема уже существует? Лучше подождать, пока проблема возникнет, нежели заранее внедрять решение, потому что предсказать будущие проблемы чрезвычайно трудно. Даже если вы правы в том, что эта проблема возникнет, в конечном итоге вас может раньше накрыть другая проблема.

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

Итак, вы все еще думаете, что вам нужна реорганизация.

ЕСТЬ ДВА ВИДА ОПТИМАЛЬНОЙ РЕОРГАНИЗАЦИИ:

• ТА, ЧТО РЕШАЕТ СТРУКТУРНУЮ ПРОБЛЕМУ.

• ТА, ЧТО ВООБЩЕ НЕ ПРОИСХОДИТ.