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

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

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

Сопственоста значи носење на проблемот, а не само на барањето

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

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

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

Прашања што ги подобруваат разговорите за производот

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

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

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

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

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

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

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

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

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

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

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

Практичен ритам на испорака

1. Обликувајте го проблемот на корисникот и посакуваната промена во однесувањето.
2. Истражете го најмалото веродостојно решение, вклучувајќи ги ризиците и целите што не се дел од него.
3. Испорачувајте во делови што може да се набљудуваат и коригираат.
4. Прегледајте ја реалната употреба, сигналите од поддршката и повратните информации од тимот.
5. Одлучете дали да проширите, ревидирате, поедноставите или запрете.

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

Градете за одржлива испорака, а не за херојско закрепнување

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

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

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

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

Сопственоста е навика на насочување

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

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

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