Повеќето инженерски тимови не пропаѓаат затоа што не знаат да пишуваат код. Тие пропаѓаат затоа што никој доследно не е одговорен за тоа дали кодот создава корисен исход.

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

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

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

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

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

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

Претворете ги нејасните барања во исходи што може да се тестираат

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

Корисна почетна точка е да се разјаснат четири работи:

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

Разгледајте барање да се известат сопствениците на сметки кога фактурата доцни. Првата имплементација може да испрати е-пошта секогаш кога ќе помине рокот за плаќање. Сопственоста на производот прашува повеќе: Дали фактурите понекогаш намерно се задржуваат? Кој е одговорен за односот кога сметката има повеќе контакти? Може ли известувањата да се паузираат? Дали потсетникот создава товар за поддршката ако статусот на плаќањето доцни?

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

Направете ги компромисите експлицитни, особено под притисок за испорака

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

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

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

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

Преземете сопственост над животниот циклус, не само над лансирањето

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

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

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

Дизајнирајте за повратност

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

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

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

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

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

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

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

Градете кариера околу корисни исходи

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

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

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

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