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

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

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

Техничкиот долг е производна одлука

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

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

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

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

Направете го долгот доволно видлив за да се управува со него

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

Наместо тоа, опишете го компромисот, неговата последица и активаторот за негово решавање. На пример: „Извозот на наплата се извршува како рачна задача; зависи од една машина со контролиран пристап и ги одложува одговорите на корисничката поддршка. Автоматизирајте го пред да додадете втор формат за извоз.“

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

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

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

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

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

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

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

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

Вклучете ја отплатата во нормалната испорака

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

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

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

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

Користете мали граници за да го намалите ризикот

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

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

1. Заштитете го тековното однесување со насочени тестови, мониторинг или документирани проверки.
2. Одделете една нестабилна граница, како интеграција со трета страна или деловно правило со многу повикувачи.
3. Преместувајте по еден случај на употреба во новата патека.
4. Отстранете ја старата патека дури откако замената ќе се докаже во нормална работа.

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

Сопственоста е поважна во оддалечените тимови

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

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

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

Мерете ги вистинските предупредувачки знаци

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

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

Оставете им подобра одлука на идните тимови

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

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