Совладување на сопственоста: Усогласување на техничката визија со реалноста на производот
Сопственоста често се опишува како особина на личноста: некои луѓе „преземаат сопственост“, додека други треба да бидат турнати. Тој пристап е погоден, но нецелосен. Во техничката работа, сопственоста е дисциплина. Тоа значи поврзување на исходот од производот со одлуките, компромисите и следењето потребно за да се постигне тоа.
Еден програмер може да ги заврши сите задачи што му се доделени и сепак да го промаши производот. Техничкиот лидер може да предложи елегантна архитектура и сепак да создаде непотребно одложување. Вистинската сопственост се наоѓа помеѓу тие неуспеси. Се поставува прашањето: каков проблем решаваме, за кого, какви докази ни кажуваат дека е важен и каков е наједноставниот одговорен начин да се продолжи напред?
Сопственоста започнува со исходот, не со задачата
Задачите се корисни контејнери за работа, но тие не се самата работа. „Додај филтер“, „препиши ја услугата“ и „подобри ја почетната страница“ се покани да се постават подобри прашања пред да се отвори уредувач.
Размислете за барање за додавање копче за извоз на екран за известување. Одговор фокусиран на задачата е да се имплементира копче и да се генерира датотека. Одговор фокусиран на сопственост е да се разјасни што им е потребно на корисниците од извозот: еднократно преземање, податоци за финансиски работен тек, датотека што може да се отвори во табела или автоматско предавање на друг систем. Тие одговори влијаат на интерфејсот, моделот на податоци, очекувањата за перформансите, дозволите и товарот за поддршка.
Ова не значи претворање на секое мало барање во долг проект за откривање. Тоа значи посветување доволно внимание за да се избегне самоуверено решавање на погрешниот проблем. Корисна навика е да се преформулира парче работа во јазик на исходот: „Им помагаме на менаџерите на сметки да идентификуваат клиенти со задоцнет рок без рачно да проверуваат секоја сметка“. Таа реченица дава подобра основа за одлуки на тимот отколку „изгради филтер за задоцнет рок“.
Техничката визија има потреба од пат до реалноста на производот
Техничката визија е важна бидејќи системите акумулираат последици. Кратенка може да стане трошок за одржување; невнимателен интерфејс може да стане траен товар за поддршка. Но, визијата станува контрапродуктивна кога е одвоена од сегашните ограничувања на производот.
Најсилните технички лидери ги држат двете вистини истовремено: квалитетот е важен, а времето е важно. Тие не ја користат итноста како причина да го игнорираат инженерскиот ризик. Ниту пак ја користат идната елеганција како причина да го одложат корисното, реверзибилно подобрување.
Практичен начин за усогласување на двете е да се направат компромисите експлицитни. При предлагање пристап, објаснете ја одлуката во термини што партнерите на производот можат да ги користат:
- Што овозможува: способноста на корисникот или бизнисот што станува возможна.
- Колку чини: време на испорака, оперативна сложеност или намалена флексибилност на друго место.
- Какви ризици носи: перформанси, интегритет на податоците, безбедност, сигурност или ризик од идна промена.
- Што може да се одложи: подобрувања што се вредни, но не се потребни за безбедно прво издание.
На пример, тимот можеби ќе треба брзо да воведе нов работен тек. Целосно редизајнирање на заедничка платформа може да биде пожелно, но ограничена функција зад јасна граница може да биде помудриот избор. Одговорната одлука не е автоматски побрзата опција или подрастистата опција. Тоа е опцијата чии ограничувања се разбрани, документирани и достапни.
Направете ја неизвесноста видлива рано
Многу проблеми при испорака не се предизвикани од тежок код. Тие се предизвикани од неизговорени претпоставки што опстојуваат предолго. Една функција може да изгледа едноставна додека некој не праша што се случува кога клиентот нема податоци, губи пристап среде работен тек, поднесува иста барање двапати или ја користи функцијата од бавна врска.
Сопственоста значи поставување на овие прашања пред тие да станат инциденти или изненадувања во доцна фаза. Исто така, значи разликување помеѓу неизвесност што бара непосредно решавање и неизвесност што може безбедно да се тестира во производство со соодветни заштитни мерки.
Користете мали, конкретни записи за одлуки
Кратка писмена одлука може да спречи недели на кружни дискусии. Не мора да биде формална. Фатете го проблемот, избраниот пристап, разгледаните алтернативи и условите што би предизвикале тимот повторно да ја разгледа одлуката. Ова е особено вредно во оддалечени тимови, каде што одлуките донесени на состанок инаку можат да исчезнат во меморијата.
Писмениот контекст исто така создава поздрава несогласување. Луѓето можат да ги оспорат претпоставките без да ја третираат претходната одлука како нечија лична територија. Целта не е да се зачува секоја одлука засекогаш; целта е да се направи расудувањето инспективно.
Сопственоста е тимска пракса, а не херојство
Хероичкото сопствеништво изгледа импресивно во моментот: една личност забележува секоја празнина, одговара на секое прашање и спасува секој рок. Исто така е кревко. Тим што зависи од неколку луѓе за носење контекст не може да одржи сигурна испорака.
Техничките лидери треба да ја вградат сопственоста во системот на работа. Тоа вклучува јасни граници, видливи приоритети, достапна документација, значајни прегледи и заедничка оперативна одговорност. Исто така, значи да се направи безбедно за некој да каже: „Не го разбирам влијанието врз корисникот“ или „оваа промена бара план за враќање“.
Во дистрибуирани тимови, јасноста треба да биде дизајнирана, а не претпоставена. Корисното ажурирање не е само список на активности. Тоа наведува што се променило, зошто е важно, што останува неизвесно и каква одлука или влез е потребен следно. Тој стил ги намалува состаноците за статус, истовремено подобрувајќи ја усогласеноста.
Претворете ја испораката во учење
Испораката е пресвртница, а не доказ дека одлуката била точна. Откако функцијата е во употреба, сопственоста продолжува преку набљудување. Дали луѓето го завршуваат предвидениот работен тек? Дали прашањата за поддршка откриваат забуна? Дали новата способност создаде оптоварување, латентност или оперативна работа што не беше предвидена?
На тимовите не им требаат совршени аналитики за да научат. Повратните информации од клиентите, обрасците на поддршка, извештаите за грешки, квалитативното набљудување и податоците за употреба можат да откријат нешто важно. Клучот е однапред да се одлучи како треба да изгледа „подобро“, а потоа да се преиспита таа очекување по ослободувањето.
Овој начин на размислување исто така го менува прегледот на кодот. Прегледот не е само потрага по дефекти; тоа е проверка дека имплементацијата сè уште служи на наменетиот исход. Рецензентот може да праша дали празните состојби се разбирливи, дали откажувањата се обновуваат, дали дизајнот може да се развива и дали тимот може да ја управува функцијата откако ќе биде испорачана.
Трајна предност во кариерата
Луѓето кои развиваат сопственост стануваат повредни бидејќи го намалуваат трошокот за координација. Тие не чекаат пасивно совршени барања, но исто така не донесуваат скриени одлуки за производот сами. Тие идентификуваат двосмисленост, носат опции, објаснуваат последици и му помагаат на групата да донесе одлука.
Тоа е мостот помеѓу техничката визија и реалноста на производот. Не се работи за контролирање на секој детал или носење на секоја одговорност. Се работи за третирање на исходот како реален, ограничувањата како реални, и луѓето погодени од работата како реални. Кога тоа ќе стане навика, подобар софтвер не само што се испорачува побрзо. Се гради со појасна причина за постоење.