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

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

Почнете со проблемот, а не со побараната функционалност

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

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

Корисен разговор за истражување разјаснува четири работи:

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

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

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

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

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

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

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

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

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

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

Испорачувајте делови што можат да ве научат нешто

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

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

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

Дефинирајте „завршено“ надвор од споен код

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

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

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

Дајте му практично значење на сопствеништвото

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

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

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

Јасноста не е контрола. Таа им дава на способните луѓе доволно контекст да дејствуваат без да чекаат постојано одобрување.

Изградете култура што може да отстранува работи

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

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

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

Градете за работата што е важна

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

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

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