Бизнис

Product Ownership: Building Software AI Can't Ignore

Сопственост на производот: Градење софтвер што ВИ не може да го игнорира

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

Токму во тој јаз сопственоста над производот станува повредна, а не помалку вредна.

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

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

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

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

Ова не значи дека секој развивач мора да дејствува како продукт-менаџер. Значи имплементацијата да се третира како дел од поширока одлука, наместо како изолирана трансакција.

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

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

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

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

ВИ ја зголемува вредноста на контекстот

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

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

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

Практичното прашање не е: „Може ли ВИ да го напише ова?“ Туку: „Кои одлуки сè уште бараат одговорна проценка?“ Често, тие одлуки вклучуваат:

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

ВИ може да ја забрза работата околу овие избори. Сопственоста е подготвеноста тие да станат видливи и да се преземат нивните исходи.

Изградете дефиниција за завршеност обликувана според производот

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

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

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

Користете тенки пресечоци, а не нејасни фази

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

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

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

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

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

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

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

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

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

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

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

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

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

Предноста во кариерата е доверливата проценка

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

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

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

Портрет на автор на блогот

Mihajlo

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