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

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

Сопственоста почнува со исходот

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

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

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

Визијата за производот е дел од техничката проценка

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

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

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

Прашања што вреди да се постават пред градење

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

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

Сопственоста не е хероизам

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

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

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

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

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

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

На пример, наместо да објави „Работата на API е речиси завршена,“ сопственикот може да напише: „Крајната точка е имплементирана и покриена за очекуваниот тек на барања. Преостанатата одлука е дали извозите над дефинирана големина треба да се извршуваат асинхроно; сегашниот синхрон пристап може да истече по време за големи сметки.“ Ова е конкретно, применливо и искрено за неизвесноста.

Едноставни практики што ги зајакнуваат оддалечените тимови

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

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

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

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

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

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

Градете кариера околу корисна одговорност

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

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

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