W, X и Z: Слоевете на една система

Начин за разбиране на софтуерната архитектура и нейните грешки

В този момент има няколко „стандартни изказвания“, които давам на моите инженери от десетилетия. Крайно време беше да ги запиша и да ги направя по-широко достъпни. Това е първият от тях!

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

Днес бих искал да го споделя с вас: първо основната идея, след това как работят нещата, когато всичко върви добре, и накрая четирите най-често срещани проблема и как да се измъкнем от тях.

Съдържание

Основната идея:Какво представляват 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-слой не трябва да мислят за тях изрично), и с Z-слой екипи, за да се уверите, че интегрираното поведение на системата не създава възникващи проблеми. Те се грижат за това да накарат системата да се провали добре и измерват успеха чрез здравето на споделения ресурс, с който са натоварени.

„Трите слоя“ на този модел не са съвсем цялата история: всеки слой може да има подслоеве вътре в него. Много често е за X слой, например, да има собствен дълбок субстрат („W от X“), който улеснява изграждането на по-високи слоеве от X, среден слой („X от X“) от обикновени примитиви и горен слой („Z от X“), който наистина е логика на Z-слой, която се използва повторно от достатъчно екипи на Z-слой, които сте частично инфраструктуризирали. И ако купувате W слой от някого (какъвто сте вие, освен ако не копаете свой собствен силиций), той има W, X и Z слоеве в тяхната компания и вие сте клиентът на върха на Z.

Здрави взаимоотношения

Когато всичко върви добре, нещата работят по следния начин:

Екипите на W-слоя прекарват времето си в мислене за мащабиране, надеждност, сигурност и други подобни. Те са в много близък контакт с екипите на X-layer и са наясно откъде ще дойдат следващите големи изисквания. Те разглеждат таблата за цялостно натоварване на системата, латентност, грешки и т.н. и наблюдават как натоварването се увеличава и надясно, докато всичко лошо остава малко. Ако купуват, а не изграждат технология, те се фокусират върху това как плавно да интегрират тази технология в екосистемата на 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 отбори. Дори и да бъде създаден отделен X екип, те все още притежават това тресавище.

Как да се измъкнем от това:Това е знак, че се нуждаем от по-ясен договор — API граница — между X и Z. Когато сте в тази ситуация, добър контролен списък, който трябва да следвате, е:

Стъпка 1:Ако все още не сте направили това, направете X отборите техен собствен обект — отделно от Z отборите — с цел да направите Z отборите щастливи.

Ако искате да стигнете някъде, първо разберете къде искате да бъдете, а след това как ще стигнете до там. Редът на тези стъпки има значение.

Стъпка 2:Екипите X трябва да навлязат в начина на мислене на корпоративна софтуерна компания, като екипите Z са техни клиенти. Те трябва да направят традиционно продуктово управление за това: да говорят с огромен брой клиенти и да разберат как да ги разделят на категории, които имат сходни нужди. Обикновено ще има няколко наистина големи (и често много уникални) и след това няколко категории, всяка от които съдържа много малки категории.

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

Този резултат трябва да бъде споделен с всички Z екипи и всички трябва да кимат енергично с глава. (Повтаряне, докато това се случи)

Стъпка 3:След това екипите X трябва да проектират къде искат да бъдат. На този етап запомнете първото правило за планиране: ако искате да стигнете някъде, първо разберете къде искате да бъдете, след това разберете как ще стигнете стигам там. Агресивно устоявайте на изкушението да разберете най-доброто постепенно подобрение от текущата ви архитектура; в момента сте много далеч от оптималното и в крайна сметка ще „оптимизирате“ (използвам термина свободно) за съществуващите ви проблеми. Направете чист дизайн и след това разберете как да преминете от текущата си система към нея.

Много ефективен подход тук е „проектиране по документация:“ искате да създадете ръководство за 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: Хоризонтално прекъсване

Проблемът:Хоризонталните екипи (сигурност и т.н.) не са правилно включени в процеса на проектиране и стартиране на други екипи. Това води до сериозни повреди, при които ресурсите на цялата компания са повредени, с последствия, вариращи от загуба на време за работа, до загуба на приходи, до загуба на доверие на потребителя, до загуба на живот. Непосредствените предшественици на това обикновено са или екипи, които правят нещо с най-добри намерения, но не осъзнават опасността до твърде късно, или бизнес лидери, които казват „не, трябва да поемем риска и да го направим!“ защото те или не разбират правилно риска, или (най-лошото) имат неправилно настроени стимули и биха предпочели да поемат риск и проектът им да „успее“ в известен смисъл, дори ако се провали в други.

Забележете как под капака всъщност има два много различни проблема:

В инженерството по безопасност, за разлика от продуктовото инженерство, това, което не знаете много, може да ви нарани. Екипи без някой, който знае как да задава правилните въпроси и да вдига подходящите аларми, могат да влязат в бедствие несъзнателно.
Хората са лоши в оценката на риска по много причини: сравняването на чести, малко добри събития с редки, наистина лоши събития е трудно. Порочните стимули или тунелната визия могат да накарат хората да се заблуждават, че нещата всъщност не са толкова лоши, докато не стане твърде късно. Екипи без някой, който може да хване проблема и да ескалира, докато се достигне ниво, където здравият разум преобладава, могат съзнателно да влязат в катастрофа. Тези, които не могат да си спомнят историята, са осъдени да я повтарят; онези, които могат да си спомнят историята, са осъдени да гледат безпомощно как другите хора я повтарят.

Как се случва:Има няколко неща, които могат да причинят този проблем.

Понякога голяма част от компанията или дори компанията като цяло не разбира достатъчно категория рискове, за да осъзнае дори, че трябва да се защитава срещу тях. Това е особено често срещано при стартиращи фирми или в по-изолирани части на големи компании. В континуум с това може да няма достатъчно обща осведоменост сред неспециалистите (хората от екипите 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.