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

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

Сопственоста е поширока од одговорноста

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

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

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

Целта не е секој инженер да се претвори во продукт-менаџер. Таа е последиците за производот да станат дел од техничкото донесување одлуки.

Метриките треба да ја информираат проценката, а не да ја заменуваат

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

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

Поздрав пристап е мерките за испорака да се спарат со прашања за производот и операциите:

• Кој кориснички проблем оваа промена го олесни за решавање?
• Кои докази ќе ни кажат дали помогнала?
• Каква нова сложеност воведовме?
• Може ли тимот подоцна да ја поддржува, набљудува и безбедно да ја менува оваа функционалност?
• Што би нè натерало да го ревидираме или отстраниме ова решение?

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

Направете го проблемот видлив пред да го направите решението

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

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

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

Користете едноставни записи за одлуки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изградете тим што се грижи по „завршено“

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

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

Вистинската сопственост над производот не е титула, состанок или контролна табла. Таа е повторувана практика на поврзување на одлуките со последиците — и доволна грижа за да се подобрат и двете.