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

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

Барањата за функции се влезни информации, а не обврски

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

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

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

Практичен превод од барање во намера

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

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

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

Намерата им дава простор на тимовите да размислуваат

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

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

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

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

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

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

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

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

Користете хипотези без да се преправате дека се факти

Една едноставна хипотеза го одржува планирањето искрено: „Веруваме дека ако статусот на одобрување стане видлив порано, ќе се намалат повторените барања за проверка на статусот. По објавувањето ќе бараме помалку барања и помалку напуштени поднесувања.“

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

Поврзете ги изборите за испорака со последиците за продуктот

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

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

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

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

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

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

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

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

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

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

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

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