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

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

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

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

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

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

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

Направете ја видлива целта на производот

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

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

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

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

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

Градете за промени без да градите катедрала

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

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

Корисен стандард е следниов: дали друг развивач може да направи насочена промена без да треба да го реконструира целиот систем во својата глава?

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

Почитувајте ја оперативната патека

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

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

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

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

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

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

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

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

Преземањето одговорност е кариерна вештина, не само тимска вредност

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

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

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

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

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

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

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