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

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

За развивачите и техничките лидери, оваа скала е еден од најпрактичните начини да се подобри производот, додека се гради долготрајна кариера.

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

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

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

Следниот чекор е да се поставуваат подобри прашања пред и во текот на имплементацијата:

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

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

Скалилата на скалата на одговорност

1. Преземете одговорност за своето извршување

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

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

2. Преземете одговорност за квалитетот на промената

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

Разгледајте навидум едноставна промена што испраќа е-пошта за потврда по дејство на клиент. Имплементација насочена кон задачата може директно да ја повика услугата за е-пошта и да прогласи успех кога барањето ќе добие одговор. Одговорноста насочена кон производот прашува што се случува кога давателот на е-пошта е бавен, недостапен или привремено одбива барање. Дали дејството на клиентот сè уште е валидно? Може ли известувањето повторно да се обиде без испраќање дупликати? Може ли поддршката да утврди што се случило?

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

3. Преземете одговорност за проблемот, а не само за решението

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

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

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

4. Преземете одговорност за системот околу работата

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

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

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

Одговорноста не е осамено херојство

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

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

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

Практичен начин за искачување

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

Користете ретроспективи, pull request-и, дискусии за планирање и активности по инциденти како места за подобрување на системот, наместо за доделување вина. Најкорисното прашање често е: „Што би го направило ова полесно да се направи правилно следниот пат?“

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