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

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

Визијата станува реална во деталите

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

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

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

Одговорите може да доведат до полесен и посигурен дизајн од општото барање за „реално време“. Тоа не е отпор. Тоа е одговорно управување со производот.

Преземете одговорност за проблемот, не само за задачата

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

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

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

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

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

Направете ги компромисите видливи

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

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

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

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

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

Вградете разбирање за производот во ритамот на тимот

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

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

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

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

Заштитете ја одржливата испорака

Визијата е корисна само ако тимот може да продолжи да ја испорачува. Брзо испорачување додека се акумулира неуправлив оперативен ризик не е брзина; тоа е позајмување од идната работа со неизвесна камата.

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

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

Растете од имплементатор до партнер за производот

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

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

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