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

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

За развивачите и техничките лидери, ова не е повик да станат продукт-менаџери под маска. Тоа е повик софтверот да се третира како жив производ, наместо како збирка завршени задачи.

Сопственоста започнува таму каде што завршува тикетот

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

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

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

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

Размислувајте за исходи, ограничувања и последици

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

Корисен начин за поставување на рамката за една задача е преку три леќи:

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

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

Техничкото лидерство често е способноста да се разликуваат тие два вида компромис.

Изградете го најмалиот целосен доживљај

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

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

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

Прашања што вреди да се постават пред издавање

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

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

На оддалечените тимови им е потребна видлива сопственост

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

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

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

Кога развивач ќе каже: „Јас го поседувам ова“, најздравото толкување не е „Јас ќе направам сè“. Тоа е „Ќе се осигурам дека се одговорени вистинските прашања и дека исходот нема да пропадне низ празнина меѓу улогите“.

Сопственоста ја прави испораката одржлива

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

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

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

Кариера изградена врз корисни исходи

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

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

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