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

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

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

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

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

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

Дајте им на луѓето проблем, а не само пропишано решение

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

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

Корисни прашања насочени кон сопственост

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

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

Направете ги правата за одлучување видливи

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

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

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

Поврзете го кодот со луѓето врз кои тој влијае

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

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

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

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

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

Тимовите можат да го направат ова практично со лесен работен ритам:

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

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

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

Создадете психолошка безбедност без да го намалите стандардот

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

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

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

Препознајте ги тивките облици на лидерство

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

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

Културата е насобраниот одговор на „што се случува ако ми е грижа?“

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

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

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