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

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

Градете за исходи, не за редица од функционалности

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

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

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

Прашања што вреди да се постават пред кодирањето

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

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

Архитектурата е одлука за испорака

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

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

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

Избирајте повратни одлуки кога целта е учење

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

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

Сопственоста значи грижа по спојувањето

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Претворете ја испораката на вредност во навика на техничкото лидерство

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

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