Способ понять архитектуру программного обеспечения и ее недостатки

На данный момент я десятилетиями делился со своими инженерами парой «стандартных реплик». Пришло время записать их и сделать более доступными. Это первая из них!

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

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

Содержание

  • Основная идея:что такое W, X, Z и горизонтальные команды и как они работают
  • Здоровые отношения:как эти команды работают вместе, когда все идет хорошо
  • Распространенные проблемы (и способы их решения):Смешивание X-Z | Смешивание Z-Z | Смешивание W-Z | Горизонтальные отключения

Если вам интересно, что случилось с «Y»: у нас (Брайан Столер, Реза Бехфоруз и я) изначально были слои X, Y и Z, затем мы поняли, что есть также слой W, а затем поняли, что слой Y не на самом деле не существует. Итак, мы остановились на W, X и Z, и названия просто прижились.

Основная идея: системы имеют три уровня

Уровень Z — это часть системы, обращенная к пользователю. Как правило, каждая система имеет в себе большое количество Z — все особенности самого продукта. Новые Z ​​постоянно тестируются, а старые утилизируются.

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

Уровень X — это инфраструктура, которая напрямую поддерживает уровень Z. Он говорит на том же языке, что и уровень Z — например, у него могут быть такие примитивы, как «пользователи» или «потоки», а не «целые числа» или «ядра».

Задача слоя X состоит в том, чтобы максимально упростить для Z-команд быстрое проведение экспериментов; Успех для них заключается в том, что Z могут пробовать что-то, не думая о вещах, которые не имеют прямого отношения к вопросам клиентов, о которых они думают, не тратя много времени на координацию друг с другом или обеспечение того, чтобы проблема с одна система Z не разрушает всю среду.

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

Слой W — это следующий уровень инфраструктуры — вещи, которые часто раскрывают примитивы, структурно сильно отличающиеся от тех, о которых заботится слой Z. (Например, системы хранения, которые позволяют вам хранить байты, в то время как уровень Z думает с точки зрения пользователей и каналов). Во многих отношениях уровень W работает так же, как уровень X — большая разница заключается в том, кто их клиенты. Команды уровня X немногочисленны (примерно столько же, сколько у вас есть базовых примитивов, что соответствует количеству команд W, а не гораздо большему количеству команд Z), и являются клиентами со сложной инфраструктурой, которые думают в тех же временных масштабах, что и они делают.

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

Это из-за самой общности его примитивов; Инфраструктура X-уровня говорит на том же языке, что и конкретный продукт вашей компании, поэтому по самой своей природе вам необходимо ее построить. Но (по причинам, которые мы обсудим ниже), даже когда вы покупаете инфраструктуру, команды W-уровня часто создают уровни поверх этого для конкретных потребностей компании и предоставляют их своим клиентам, а не необработанным сторонним организациям. инструмент.

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

«Три слоя» этой модели — это еще не все: внутри каждого слоя могут быть подслои. Например, очень часто слой X имеет собственную глубокую подложку («W of the X»), которая позволяет легко строить более высокие слои X, средний слой («X of the X») общие примитивы и верхний уровень («Z of the X»), который на самом деле является логикой Z-уровня, который повторно используется достаточным количеством команд Z-уровня, которые вы частично инфраструктуризировали. И если вы покупаете слой W у кого-то (что вы и делаете, если только вы не занимаетесь добычей собственного кремния), у него есть слои W, X и Z внутри его компании, и вы клиент на своем Z.

Здоровые отношения

Когда все идет хорошо, все работает примерно так:

  • Команды W-уровня тратят свое время на размышления о масштабировании, надежности, безопасности и тому подобном. Они находятся в очень тесном контакте с командами X-уровня и знают, откуда будут поступать следующие большие требования. Они смотрят на информационные панели общей загрузки системы, задержек, ошибок и т. д. и наблюдают, как нагрузка растет и вправо, в то время как все плохое остается небольшим. Если они покупают, а не создают технологию, они сосредотачиваются на том, как плавно интегрировать эту технологию в экосистему X-уровня.
  • Команды X-уровня все больше и больше действуют как команды W-уровня, думая об общей нагрузке от своих клиентов. Они разделили своих клиентов на категории — горстка очень крупных клиентов, с которыми у них очень тесные отношения, и горстка категорий более мелких клиентов со схожими потребностями, с которыми у них отношения самообслуживания на расстоянии вытянутой руки. Они внимательно следят за теми видами экспериментов, которые хотят проводить Z-команды, и разрабатывают новые функции, чтобы сделать их еще больше.
  • Команды Z-уровня экспериментируют как сумасшедшие и редко думают о командах W- или X-уровня или даже о других командах Z-уровня. За исключением горстки действительно крупных и зрелых компаний, они обдумывают сотни идей поведения новых продуктов и безостановочно ищут соответствие продукта рынку. Иногда у них появляются идеи, которые потребуют какой-то принципиально новой инфраструктуры, и в этот момент они разочаровываются, что ее еще нет.
  • Горизонтальные команды были разделены на центральную команду (которая действует как рецензенты и штатные эксперты) и встроенную команду (люди, которые работают полный рабочий день в командах уровней W, X и Z, помогая этим командам правильно разрабатывать свои продукты). и делать их счастливыми), а также распределенную группу людей в командах уровней W, X и Z, которые понимают и заботятся о соответствующих проблемах и ежедневно используют свои знания в этой области. . Команды вкладывают свою энергию в то, чтобы помочь людям продумать случаи сбоев и справиться с эскалацией («Эта команда хочет сделать то-то и то-то, но это создает риск; должны ли мы это сделать?») и инцидентами.

Напоминание: эскалация — это здорово!

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

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

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

Распространенные проблемы (и как с ними справляться)

С помощью этой модели вы можете начать видеть четыре наиболее распространенных ошибки и способы выхода из этих проблем, когда они случаются. Большинство из них сводятся к тому, что разные уровни системы не имеют правильного разделения между собой: смешение X-Z, смешение Z-Z и смешение W-Z. Четвертый, горизонтальное отключение, происходит, когда команды не сотрудничают.

Проблема № 1: Смешивание X-Z

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

Как это происходит.Это очень распространенная проблема, и обычно она возникает из-за того, что когда система создается впервые, в ней вообще нет слоев; это в основном один Z. Затем строится второй Z, и он надевается как своего рода хак на сторону первого Z, возможно, повторно используя некоторые вещи; и третий, и четвертый, и вдруг у вас есть куча Z, но нет четкого X-слоя, только большое болото, полное логики Z-уровня. Каждая Z-команда в основном владеет кучей вещей внутри X, и они не могут легко это изменить, потому что все полно логики от других Z-команд. Даже если будет создана отдельная команда Х, это болото все равно принадлежит им.

Как выйти из этого.Это признак того, что нам нужен более четкий договор — граница API — между X и Z. В этой ситуации хорошим контрольным списком является:

Шаг 1.Если вы еще этого не сделали, сделайте команды X отдельной организацией, отдельной от команд Z, с целью осчастливить команды Z.

Если вы хотите чего-то добиться, сначала выясните, где вы хотите быть, а затем выясните, как вы собираетесь туда добраться. Порядок этих шагов имеет значение.

Шаг 2.Команды X должны войти в образ мышления компании-разработчика корпоративного программного обеспечения, где команды Z являются их клиентами. Им нужно заняться традиционным управлением продуктом: поговорить с огромным количеством своих клиентов и придумать, как разделить их на категории со схожими потребностями. Как правило, будет несколько действительно больших (и часто очень уникальных) категорий, а затем несколько категорий, каждая из которых содержит множество мелких категорий.

Результатом этого шага должен быть (1) список категорий клиентов с кратким изложением ключевых вещей, которые важны для каждой категории, и (2) краткий (‹10 пунктов) список типичных запросов клиентов, так что если все это было легко, все были бы счастливы. Вы должны настойчиво нацеливать этот список на то, что люди могут попросить в будущем, а не только на текущий список; опыт помогает сделать этот звонок.

Этим результатом следует поделиться со всеми Z-командами, и все должны энергично кивать головами. (Повторяйте, пока это не произойдет)

Шаг 3.Затем командам Х нужно спроектировать то, что они хотят. На этом этапе запомните первое правило планирования: если вы хотите куда-то попасть, сначала выясните, где вы хотите быть, затем выясните, как вы собираетесь достичь цели. Настойчиво сопротивляйтесь искушению найти лучшее постепенное улучшение вашей текущей архитектуры; вы в настоящее время очень далеки от оптимума и закончите тем, что «оптимизируете» (я использую этот термин вольно) для ваших существующих проблем. Создайте проект с чистого листа, а затем затем выясните, как перейти от текущей системы к новой.

Очень эффективным подходом здесь является «дизайн с помощью документации»: вы хотите создать руководство для Z-команд о том, как вносить каждый из распространенных типов изменений, и сделать это должно быть действительно легко. Важно отметить, что в общем случае люди, которые это делают, не должны нуждаться в какой-либо явной помощи со стороны X-команд и не должны иметь глубокого понимания систем или проблем X-уровня, кроме простых предупреждений, таких как «не делайте X».

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

Это должно быть сделано в тесном сотрудничестве с клиентами; это те, кому нужно сказать «да, этот дизайн сделает нашу жизнь прекрасной!», поскольку успех или провал вашего проекта в конечном итоге будет определяться их счастьем.

Шаг 4.Теперь вы можете начать традиционный процесс планирования.

Ваша общая цель — создать эту систему; его ключевые результаты связаны с удовлетворенностью клиентов.

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

Каждая веха должна либо говорить о том, чтобы сделать что-то доступным для пилотной группы клиентов в рамках категории (3* крупных клиентов в этой категории, которые согласились тесно сотрудничать с вами, чтобы убедиться, что система действительно удовлетворяет их потребности, и выполнить работу над с их целью внедрить его; соответствующий KR касается исключительно удовлетворенности этих пилотных клиентов процессом и результатом) или обеспечения его широкого внедрения клиентами в этой категории (соответствующий KR касается степени внедрения и того, сколько времени у вас есть для расходы на одного клиента).

* Число 3 приблизительное, но волшебное. Помните, что в инженерии каждая система создается либо для одного использования, либо для N; 3 — это наименьшее число, которое больше единицы и не способствует построению для особых случаев.

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

Шаг 5.А теперь приступайте к исполнению! Оставайтесь на связи со своими клиентами; для вех с участием пилотов вы должны быть настолько близки, что многие люди даже не уверены, кто к какой команде принадлежит. Для достижения общей доступности убедитесь, что вы регулярно проходите проверки CSAT.

Это не только приводит вас в правильное архитектурное состояние (поскольку в руководстве действительно подчеркивается, что Z-командам не нужно тратить свое время на то, что им не следует), но и в правильное состояние здоровья команды (потому что у вас хорошие отношения). с вашими командами Z, и они счастливы).

Проблема №2: смешение Z-Z

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

Почему это происходит? Обычно это та же основная история, что и при микшировании X-Z. Здесь проблема заключается в том, что базовые примитивы системы — существительные и глаголы, предоставляемые API, — недостаточно ясны или различимы, поэтому условно небольшое и изолированное изменение, требуемое командой Z, превращается в большое и неизолированное изменение. это требует от всех сотрудничества.

Как выйти из этой ситуации. На самом деле здесь кроются три возможные проблемы.

  • Если происходит смешение X-Z, это создаст контакт Z-Z, поэтому, если это ваша проблема, решите ее, и она должна позаботиться об этом.
  • Если вы уже сделали хорошее разделение X-Z, но у вас все еще есть проблема с контактом Z-Z, ваш API-интерфейс X-уровня может быть неверным и выставлять неправильные существительные или глаголы. Признаком этого является то, что взаимодействие между Z-командами происходит на этапах детального проектирования или реализации. В этом случае: убедитесь, что у вас есть актуальный список вещей, которые Z-командам нужно (или понадобится в будущем), и сделайте чистый лист того, как должен выглядеть ваш API. поддержите это с хорошо ортогональными компонентами. Как обычно, подключите команды Z к новому API, подтвердив, что он позволит им делать то, что они хотят, и им не нужно думать о других Z. Затем внедрите новый API с связующим слоем, чтобы старый API был максимально реализован поверх него, и переместите людей со старого API.
  • Если, с другой стороны, проблема возникает больше во время развертывания или производства, а не во время проектирования или кодирования — такие вещи, как одна команда Z, перегружающая систему и выбивающая X-уровень — тогда у X-уровня есть проблема изоляции. На этом этапе команде X пора начать мыслить как команда W и, возможно, тесно сотрудничать со своими поставщиками W-уровня, чтобы сделать систему более изолированной и надежной. Здесь пригодятся все приемы системной инфраструктуры: расстановка приоритетов, сброс нагрузки, песочница и так далее.

Проблема № 3: Смешивание W-Z

Проблема. Люди, работающие над проблемами Z-уровня, тратят время на общение с командами W-уровня и обдумывают очень важные детали. Все действительно сложно, и изменения производства даются тяжело.

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

Для примера из реальной жизни, когда я возглавлял высокопроизводительный поиск в Google, мы не только оптимизировали стек поиска, но и перенастроили его для каждой аппаратной платформы, реализовали самые внутренние циклы в кодируемом вручную ассемблере, обошли файловую систему и обращаться к дискам как к необработанным блочным устройствам, изменять драйверы блочных устройств в ядре, работать с аппаратной командой над архитектурой NUMA и шин данных на материнских платах в соответствии с нашими потребностями и убеждать производителей микрочипов изменить свои наборы инструкций. (Вот почему в x86 есть операция lzcnt!) В таком масштабе все это было вполне разумно. В большинстве других масштабов их не было бы.

Как это происходит.В начале жизни системы редко бывает известно, какие существительные и глаголы являются правильными, поэтому первоначальные Z-системы начинают напрямую общаться с более абстрактными нижними уровнями, например. хранение на уровне байтов. (Это особенно верно в эпоху облачных вычислений, когда компании с радостью продадут вам инфраструктуру W-уровня, а команды Z-уровня не поймут, что она не выполняет тех же функций, что и инфраструктура X-уровня. Харрис отметил, что маркетинговые команды SaaS очень заинтересованы в том, чтобы сказать вам, что это решит ваши проблемы, и не настолько заинтересованы в том, чтобы объяснять, что они предоставляют вам инструменты для решения ваших проблем, на самом деле они этого не делают. Автоматическое удаление данных является известным примером, поскольку для его выполнения требуется много знать о ваших схемах данных, и поэтому по своей сути это работа X-уровня) Этот материал сохраняется, и позже начинает казаться, что Z-уровни говорят всю дорогу. до W слоев.

В качестве альтернативы возможно, что уровень X недостаточно четко скрыл свои собственные абстракции, а API X-Z настолько подвержен влиянию API W-X, что это почти сквозной.

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

Как избежать этого:проверьте, действительно ли это проблема, прежде чем что-либо предпринимать; не все контакты W-Z являются плохим признаком. Если это действительно проблема, решите ее так же, как и любую проблему удобства использования инфраструктуры: «эта задача является бременем для команд уровня X/Z из-за утечки абстракции W». Можно ли автоматизировать задачу? Можно ли (и нужно ли) перепроектировать или заменить базовую систему, чтобы полностью исключить такую ​​задачу? В качестве альтернативы, должен ли быть какой-то промежуточный слой X?

Некоторыми типичными признаками того, что это есть проблема, являются несхематические данные, где вы не можете легко ответить на такие вопросы, как «какие данные у нас есть» или «какие из них являются пользовательскими данными»; доступ к базовым системам осуществляется тремя разными способами с разными библиотеками, которые были найдены в разных точках; трудности с инструментированием вашей инфраструктуры (особенно хранилища) для измерения ее поведения или добавления правил, специфичных для ваших нужд. Любой из них, как правило, является надежным показателем того, что уровень X крайне необходим.

Как правило, промежуточный уровень полезен, если вы не можете должным образом контролировать уровень W (программное обеспечение 3P), если вам может потребоваться заменить его или поддерживать несколько уровней W (например, различные виды облаков), или если полезные абстракции необходимые вашим слоям X и Z, отличаются от тех, которые предоставляются слоем W. Во всех этих случаях, как правило, хорошо, чтобы этот промежуточный слой был как можно тоньше. Тем не менее, наличие очень тонкого промежуточного слоя иногда может быть лучше, чем его отсутствие, так как наличие такой прокладки значительно упрощает замену W-слоя в будущем, если вам это понадобится!

Проблема №4: Горизонтальное отключение

Проблема. Горизонтальные группы (безопасность и т. д.) не принимают должного участия в разработке и запуске других команд. Это приводит к серьезным сбоям, когда повреждаются ресурсы всей компании, с последствиями, варьирующимися от потери времени безотказной работы до потери дохода, потери доверия пользователей и гибели людей. Непосредственными предшественниками этого обычно являются либо команды, делающие что-то из лучших побуждений, но слишком поздно осознающие опасность, либо бизнес-лидеры, говорящие: «Нет, мы должны рискнуть и сделать это!» потому что они либо не понимают риска должным образом, либо (что хуже всего) имеют несогласованные стимулы и предпочли бы рискнуть и добиться успеха своего проекта в каком-то смысле, даже если он потерпит неудачу в других.

Обратите внимание, что под капотом здесь на самом деле две очень разные проблемы:

  1. В технике безопасности, в отличие от разработки продукта, то, чего вы не знаете, может навредить вам. Команды без кого-то, кто знает, как задавать правильные вопросы и поднимать соответствующие тревоги, могут по незнанию попасть в беду.
  2. Люди плохо оценивают риск по многим причинам: трудно сравнивать частые, слегка хорошие события с редкими, действительно плохими событиями. Извращенные стимулы или узкое видение могут заставить людей обманывать себя, думая, что все не так уж и плохо, пока не станет слишком поздно. Команды без кого-то, кто может обнаружить проблему и эскалировать ее до тех пор, пока не будет достигнут уровень, при котором преобладает здравомыслие, могут осознанно попасть в беду. Те, кто не может вспомнить историю, обречены на ее повторение; те, кто может помнить историю, обречены беспомощно смотреть, как другие люди повторяют ее.

Как это происходит.Есть несколько вещей, которые могут вызвать эту проблему.

  • Иногда большая часть компании или даже компания в целом не понимают какую-то категорию рисков настолько, чтобы даже понять, что им нужно защищаться от них. Это особенно распространено в стартапах или в более изолированных частях крупных компаний. В связи с этим неспециалисты (например, люди в командах W, X и Z) могут быть недостаточно осведомлены о проблеме, чтобы знать, когда им нужно обратиться за помощью.
  • Может отсутствовать процесс, который гарантирует, что горизонтальные команды имеют возможность работать друг с другом и следить за тем, чтобы все шло по плану; в качестве альтернативы горизонтальные команды могут быть радикально недоукомплектованы, поэтому многие вещи ускользают из виду.
  • Горизонтальные команды могут не знать, как эффективно поддерживать другие команды; например, они могут быть построены скорее как группы соответствия (которые могут ставить галочки, но не могут помогать людям в проектировании) или иным образом иметь плохие отношения с этими командами.
  • Может отсутствовать поддержка защиты этого ресурса на уровне высшего руководства, что означает, что все эскалации в конечном итоге терпят неудачу. На самом деле это означает, что высшее руководство вообще не заботится об этом ресурсе.

Как выйти из этого:

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

  • Если есть непонимание проблем, наймите экспертов или иным образом найдите их и пригласите в свою группу. Эскалируйте, если вы не можете получить ресурсы. Хорошо функционирующие горизонтальные команды особенно хороши и часто любят помогать другим узнавать о предмете, поэтому спрашивайте именно у них!
  • Отсутствие поддержки для защиты ресурса является самой серьезной проблемой, и, как правило, ее нужно решать сверху вниз: высшее руководство должно понимать и постоянно выражать свое внимание к сохранению этого ресурса и распространять этот приоритет вниз. Установка таких приоритетов и сохранение общих ресурсов компании — ключевая часть их работы. Если вы обнаружите, что работаете в компании, где высшее руководство понимает, но законным все равно, все, что я могу сказать, это то, что сейчас самое время подумать о том, как вы можете найти другую работу. Здесь будут происходить плохие вещи.

Один важный прием, который я нашел полезным в этом случае, заключается в том, чтобы переформулировать проблему от «рисков» к «учебникам». Руководителю слишком легко сбрасывать со счетов риск как нечто, что на самом деле не произойдет. Но если вы сформулируете это так: «Когда произойдет X, нам нужно будет принять следующие решения. К кому нам обращаться в этой ситуации? Это ты?" Это способ сделать реальность последствий более личной для людей и привлечь их внимание.

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

Want to Connect?
Yonatan Zunger is Distinguished Engineer at Twitter. In the past, he’s held similar roles at Humu and Google, where he ran things from high-capacity search, to planet-scale storage, to social networking.