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

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

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

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

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

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

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

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

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

Претворете ги барањата во заеднички одлуки

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

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

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

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

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

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

Дизајнирајте за целиот животен циклус

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

Корисен начин за преглед на работата е да се помине низ нејзиниот животен циклус:

1. Како корисникот ја открива и разбира можноста?
2. Како изгледа вообичаениот тек?
3. Што се случува кога недостасуваат внес, податоци или зависност?
4. Како системот се опоравува од привремен неуспех?
5. Како поддршката или инженерскиот тим ќе дијагностицираат проблем?
6. Што се случува ако функционалноста мора да биде оневозможена, изменета или отстранета?

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

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

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

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

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

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

Направете ја оддалечената сопственост видлива

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

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

Развијте се од извршител во инженер со начин на размислување за производот

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

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

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