Тимовите често го мерат инженерското здравје преку брзината на испорака, достапноста, завршувањето на спринтови или бројот на затворени задачи. Овие сигнали се важни, но можат да доведат во заблуда. Тимот може брзо да испорачува, а притоа да создава работа што никој не ја сака. Може да одржува импресивна контролна табла, додека клиентите остануваат заглавени во збунувачки текови. Може да го заврши секој доделен тикет, а сепак никој да не се чувствува одговорен за тоа дали производот навистина функционира.

Покорисната метрика е преземањето одговорност: подготвеноста и способноста да се води проблемот од нејасна потреба на клиентот до сигурен исход. Преземањето одговорност не значи херојски напор, работење до доцна или да станете личноста што поправа сè. Станува збор за тоа резултатот да го третирате како ваша одговорност, вклучително и незгодните делови што се надвор од тесно дефинираната задача.

Преземањето одговорност го претвора излезот во исходи

Излез е испорачана функционалност. Исход е клиент што може полесно, побезбедно или поуспешно да заврши значајна задача благодарение на таа функционалност. Разликата звучи очигледно, но многу проблеми со испораката почнуваат кога тимот ќе застане на излезот.

Разгледајте едноставно барање: додадете опција за извезување податоци од сметката. Имплементација насочена кон тикетот може да додаде копче, да генерира датотека и да ја означи работата како завршена. Личност што презема одговорност поставува дополнителни прашања: Кои податоци треба да бидат вклучени? Колку време ќе трае голем извоз? Што се случува ако генерирањето не успее? Дали преземањето е безбедно? Дали лице од поддршката може да го објасни резултатот? Дали корисникот има јасен статус додека се подготвува?

Ниту едно од овие прашања не бара совршенство или неограничен опсег. Тие бараат некој да се грижи за вистинското корисничко патување, а не само за патеката на кодот што ги исполнува почетните критериуми за прифаќање.

Преземањето одговорност почнува кога „тоа не беше во тикетот“ ќе престане да биде крај на разговорот.

Како изгледа преземањето одговорност во пракса

Преземањето одговорност е забележливо. Се појавува во малите одлуки донесени пред, за време на и по испораката.

• Разјаснување на проблемот: прашување кому му е потребна промената, што се обидува да постигне и како тимот ќе знае дека помогнала.
• Размислување за неуспех: разгледување празни состојби, повторни обиди, делумен успех, дозволи, бавни врски и разбирливи пораки за грешка.
• Заштита на системот: правење промени што се вклопуваат во постојните обрасци, можат да се тестираат и не создаваат тивко оперативен долг.
• Затворање на циклусот: проверување на објавеното однесување, слушање повратни информации од поддршката или производниот тим и исправување на пропуштеното.
• Правење на одговорноста видлива: документирање одлуки, споделување контекст и осигурување дека друго лице може безбедно да ја одржува работата.

Ова не значи дека секој развивач е сопственик на секоја деловна одлука. Производот, дизајнот, поддршката, безбедноста и операциите носат суштински перспективи. Доброто преземање одговорност е соработничко: ги вклучува вистинските луѓе рано, наместо готовата имплементација да ја префрли преку ѕид.

Преземањето одговорност не е индивидуален хероизам

Честа грешка е преземањето одговорност да се пофалува само кога некој спасува неуспешна објава на полноќ. Тоа може да биде неопходно при инцидент, но не е одржлив оперативен модел. Ако едно лице постојано станува патеката за итни случаи, организацијата создала зависност, а не преземање одговорност.

Здравото преземање одговорност ги распределува знаењето и донесувањето одлуки. Техничкиот лидер помага да се дефинираат јасни граници, создава простор инженерите да носат одлуки и осигурува ризиците да бидат видливи пред да станат итни случаи. Целта не е секое лице самостојно да биде одговорно за сè. Целта е тимот сигурно да биде одговорен за производот.

Изградете системи што поддржуваат одговорни одлуки

Луѓето не можат да покажат преземање одговорност кога околината ги казнува за тоа. Ако секое прашање се третира како доцнење, развивачите ќе престанат да укажуваат на ризици. Ако објавувањето е непроѕирно, тимовите не можат со сигурност да ја потврдат својата работа. Ако приоритетите се менуваат без контекст, инженерите ќе се оптимизираат за последната инструкција што ја слушнале, наместо за проблемот на клиентот.

Техничките лидери можат да го олеснат преземањето одговорност со воспоставување неколку практични навики:

• Дајте ѝ на работата јасна изјава за проблемот, а не само барано решение.
• Дефинирајте граници за одлучување за луѓето да знаат што можат да решат без да чекаат одобрување.
• Направете ги практиките за објавување, мониторинг и враќање на претходната состојба разбирливи за луѓето што испорачуваат промени.
• Прегледувајте инциденти и неисполнети очекувања заради учење, а не вина.
• Наградувајте рано пријавување неизвесност исто колку и видлива испорака.

Овие практики создаваат психолошка безбедност, но создаваат и оперативна јасност. Потребни се и двете. На тимот му треба дозвола да проговори и практичен начин да постапи според она што ќе го забележи.

На оддалечените тимови им треба експлицитно преземање одговорност

Во канцеларија каде што луѓето работат заедно, незавршената работа понекогаш може да се открие преку неформален разговор. Во оддалечените тимови, нејасноста опстојува подолго. Порака што вели „API-то е подготвено“ може да крие неодговорени прашања за документација, интеграција со клиентот, автентикација, мониторинг или пуштање во употреба.

Оддалечената соработка има корист од тоа преземањето одговорност да биде експлицитно, без секоја задача да се претвори во бирократија. За значајни промени, запишете го предвидениот исход, тековната одлука, отворените ризици и следното одговорно дејство. Кратко писмено ажурирање често спречува повеќе забуна отколку долг состанок.

Асинхроната работа исто така ги наградува луѓето што го објаснуваат своето образложение. „Го избрав овој пристап бидејќи ја одржува миграцијата повратна и ни овозможува да го објавиме интерфејсот пред да го овозможиме за сите корисници“ им дава корисен контекст на соиграчите. „Завршено“ не го прави тоа.

Како развивачите можат да го развиваат преземањето одговорност

Преземањето одговорност е вештина за кариера бидејќи се надградува. Инженерите што доследно ги поврзуваат техничките избори со последиците за клиентите и бизнисот добиваат поголема доверба за нејасна работа. Тие не се само побрзи имплементатори; ја намалуваат количината на координација и повторна работа што му е потребна на тимот.

Практичен почеток е да додадете кратка проверка на одговорноста пред да ја означите работата како завршена:

1. Кој кориснички или деловен проблем го решава ова?
2. Кој е најверојатниот начин на кој ова би можело да не успее или да збуни некого?
3. Кој треба да знае за оваа промена?
4. Како ќе утврдиме дали функционира по објавувањето?
5. Што останува неизвесно и дали таа неизвесност е прифатлива?

Одговорите можат да бидат кратки. Вредноста е во тоа прашањата да станат навика. Со текот на времето, ова ги менува изборите за имплементација: развивач додава смислена празна состојба, тим поетапно спроведува ризична миграција или продукт-менаџер дознава за ограничување доволно рано за да го приспособи планот.

Производот памети што вреднува организацијата

Секој производ ги одразува одлуките што луѓето ги донеле кога никој не набљудувал внимателно. Тоа се покажува во пораките за грешка, патеките за опоравување, однесувањето при вчитување страници, деталите за пристапност и во тоа дали збунувачки граничен случај бил оставен за „подоцна“. Овие детали не се одвоени од деловниот квалитет. Тие се деловниот квалитет што го доживува вистинска личност.

Испорачувањето подобри производи не бара бркање митски стандард на беспрекорно извршување. Потребни се тимови што испораката ја гледаат како обврска, а не како предавање. Кога преземањето одговорност ќе стане вистинската инженерска метрика, брзината станува позначајна, техничкиот квалитет станува попрактичен, а производот има многу подобра шанса да ја заслужи довербата што ја бара од своите корисници.