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

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

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

Тикетите ја опишуваат работата; производите создаваат исходи

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

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

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

Дајте им на инженерите доволно контекст за да носат добри одлуки

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

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

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

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

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

Заменете ги предавањата со заедничко разбирање

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

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

Градете во мали целини што можат да ве научат нешто

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

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

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

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

Мерете што се случува по распоредувањето

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

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

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

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

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

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

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

Размислувањето за производот е вештина за кариера, а не работна титула

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

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

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