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

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

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

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

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

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

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

Прашања што вреди да се постават пред имплементацијата

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

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

Претворете ги барањата во исходи

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

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

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

Среќната патека често е најкраткиот дел од функционалноста. Околното искуство одредува дали луѓето ѝ веруваат.

Направете ги компромисите видливи

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

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

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

Практичен запис за одлука

За одлуки со трајни последици, запишете неколку концизни точки:

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

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

Сопственоста на далечина бара намерна комуникација

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

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

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

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

Одржливата испорака е работа на производот

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

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

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

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

Градете кариера околу проценката, не само околу резултатот

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

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

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

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