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

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

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

Почнете со исходот, а не со побараната функционалност

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

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

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

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

Направете го успехот забележлив

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

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

• Проблем: Што е тешко, бавно, ризично или збунувачко денес?
• Корисник: Чија работа или одлука се менува?
• Исход: Што може тоа лице да направи подобро потоа?
• Доказ: Што би нè уверило дека промената била корисна?

Претворете го backlog-от во систем за одлучување

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

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

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

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

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

Соработувајте со инженерскиот тим без да ја пренесувате сопственоста

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

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

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

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

Дефинирајте „готово“ надвор од споен код

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

За работа со значаен оперативен ризик, разговарајте експлицитно за испораката:

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

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

Дајте им на оддалечените тимови контекст што не можат случајно да го слушнат

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

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

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

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

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

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

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

Вистинскиот север е практика, а не слоган

Вредноста на Product Owner не се мери со тоа колку тикети поминуваат низ табла. Таа се мери со тоа дали тимот постојано претвора ограничено време и внимание во корисна, безбедна, разбирлива промена.

Постојано враќајте се на истите прашања: Кој проблем го решаваме? За кого? Зошто сега? Кој е најмалиот значаен чекор? Што ќе научиме откако ќе биде испорачан?

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