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

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

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

Сопственоста е повеќе од завршување на доделената работа

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

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

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

Градењето на побараното е извршување. Помагањето на тимот да утврди што вреди да се гради е сопственост.

Почнете од моментот на тешкотија кај клиентот

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

Насочете го разговорот кон моментот кога работата се распаѓа. Кој се обидува да направи што? Што ја прави таа задача тешка денес? Што се случува ако не можат да ја завршат? Како некој ќе знае дека промената го подобрила тоа искуство?

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

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

Прашања што подобруваат нејасно барање

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

Направете ја техничката проценка видлива

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

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

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

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

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

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

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

Лесна белешка за одлука може да биде доволна:

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

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

Претворете ја испораката во циклус на учење

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

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

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

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

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

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

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