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

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

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

„Што“ е видливо; „зошто“ ја врши вистинската работа

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

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

„Што“ му кажува на тимот од каде да почне. „Зошто“ му кажува дали таа почетна точка вреди да се следи.

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

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

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

Развивач што практикува продуктно размислување може да праша:

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

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

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

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

Користете исходи за да ги направите компромисите јасни

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

„Зошто“ им дава заедничка основа на тие компромиси. Без него, дискусиите стануваат позициони: еден човек сака микросервис, друг сака промена во монолитот; еден сака сеопфатен редизајн, друг сака мала закрпа. Со договорен исход, разговорот станува покорисен: која опција најбезбедно им помага на корисниците да ја завршат предвидената задача?

Практичен пристап е да се напише кратка изјава за исходот пред имплементацијата:

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

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

Одредете точка на запирање

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

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

На оддалечените тимови им е потребно напишано „зошто“

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

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

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

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

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

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

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

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

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

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

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