Повеќето софтверски производи не пропаѓаат затоа што првиот план бил слаб. Тие се мачат затоа што планот бил третиран како производ.

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

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

Сопственоста започнува по „завршено“

Функционалноста може да биде завршена во спринт, а сепак да остане недовршена како производна одлука. Дали го решава наменетиот проблем? Можат ли корисниците да ја откријат? Дали се однесува добро кога недостигаат податоци, се зголемува сообраќајот или откажува услуга од трета страна? Може ли друг развивач безбедно да ја измени шест месеци подоцна?

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

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

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

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

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

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

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

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

Користете записи за одлуки за значајни компромиси

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

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

Направете ја испораката одржлива со дизајнирање за промена

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

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

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

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

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

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

Корисните оддалечени навики се едноставни:

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

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

Развијте се од имплементатор во сопственик на производ

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

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

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

Дозволете производот да ве поучи

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

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

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