Производот ретко пропаѓа затоа што тимот не успеал да затвори доволно тикети. Пропаѓа затоа што тикетите биле третирани како производ.

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

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

Испораката е исход, а не редица од завршена работа

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

Ништо од ова не значи дека секој развивач мора да ја поседува секоја одлука. Здравата сопственост не е херојски индивидуализам ниту постојана достапност. Таа значи преземање одговорност за последиците што разумно се поврзани со работата и правење на неизвесноста видлива пред да стане скапа.

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

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

Направете го контекстот на производот достапен

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

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

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

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

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

Претворете го „завршено“ во заеднички стандард за квалитет

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

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

Точниот стандард ќе варира. Промена на текст на маркетинг-страница не треба да носи ист товар како ажурирање на текот на плаќање. Целта е пропорционална грижа: доволно докази за промената да биде безбедна и корисна, без рутинската испорака да се претвори во церемонија.

Дизајнирајте за патеката на неуспех

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

Земете работен тек што испраќа известување по зачувување на претпочитање на клиентот. Ако зачувувањето успее, но испораката на известувањето не успее, претпочитањето треба да остане зачувано. Системот треба да го пријави точниот статус, да запише доволно детали за истрага и да избегне да го наведе корисникот погрешно да мисли дека неговото претпочитање е изгубено.

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

Дајте им на луѓето овластување со одговорност

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

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

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

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

Вградете ја сопственоста во навиките на тимот

Културата се зајакнува со повторено однесување, а не со постер за одговорност. Неколку лесни навики можат да ја направат сопственоста практична:

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

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

Заштитете ја одржливата сопственост

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

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

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

Градете производи, не само проток

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

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

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