Повеќето софтвери не пропаѓаат затоа што тимот не можел да напише код. Пропаѓаат затоа што кодот одговорил на прашање што веќе станало ирелевантно.

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

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

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

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

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

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

Кодот е важен. Прашањето на кое одговара е уште поважно.

Дефинирајте го исходот, не само излезот

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

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

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

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

Градете за учење, не само за лансирање

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

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

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

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

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

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

Техничкото лидерство е управување со опциите

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

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

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

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

На далечинските тимови им е потребен експлицитен продуктен контекст

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

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

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

Направете ја сопственоста поширока од сопственоста врз кодот

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

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

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

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