Элегантная головоломка. Системы инженерного менеджмента — страница 7 из 32

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

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


Определение целей

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

Хорошие цели – это комбинация из четырех конкретных чисел:

1. Цель указывает, чего вы хотите достичь.

2. Базовый уровень определяет, где вы находитесь сегодня.

3. Тренд описывает текущую скорость.

4. Временные рамки устанавливают границы для изменения.

Соберите все воедино, и хорошо структурированная цель примет следующую форму: «В третьем квартале мы сократим время рендеринга нашей главной страницы с 600мс[11] (p95) до 300мс (p95). Во втором квартале время рендеринга увеличилось с 500мс до 600мс».

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

Инвестиции и базовые показатели

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

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

Представьте, что вы хотите ускорить конвейер обработки данных. Цель может звучать так: «Основные пакетные задания должны завершаться в течение трех часов (p95) к концу третьего квартала. В настоящее время они занимают шесть часов (p95), а во втором квартале стали на два часа длиннее». Это хорошо структурированная цель, но она также является неполной, потому что вы, например, можете достичь ее уже завтра, удвоив размер своего кластера – но это, вероятно, нежелательный исход.

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

• Эффективность выполнения основных пакетных заданий не должна превышать текущую цену в 0,05 доллара за ГБ.

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

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

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

Планы и контракты

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

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

Существует и исключение: ситуация, когда вы используете некоторые базовые показатели в качестве контракта со второй стороной, возможно, в рамках SLO[12] (16) – тогда вы, вероятно, захотите обсудить эти показатели более подробно.

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

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

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

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

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

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

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

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

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

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

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

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

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