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

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

Почнете од вистинската задача на корисникот

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

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

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

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

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

Претворете ја намерата на производот во технички избори

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

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

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

requested -> generating -> ready
                    |
                    v
                  failed

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

Градете мали, целосни целини

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

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

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

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

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

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

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

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

Направете ја одговорноста видлива во оддалечените тимови

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

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

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

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

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

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

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

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

Мерете ја корисноста според тоа што станува полесно

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

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

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