Većinu neuspjeha softvera ne uzrokuju nedostajući okvir, nesavršen algoritam ili programer koji nije radio dovoljno naporno. Događaju se kada tim kod tretira kao ciljnu liniju umjesto kao jedan dio životnog ciklusa proizvoda.

Izrada funkcionalnosti važno je postignuće. Preuzimanje odgovornosti za ono što se događa prije i nakon te funkcionalnosti ono je što tehnički rad pretvara u koristan rad. Ta je razlika važna bez obzira na to jeste li individualni suradnik, viši inženjer, tehnički voditelj ili osoba koja se razvija prema odgovornosti za proizvod.

Proizvod nije zahtjev za povlačenje koji ga je uveo. To su problem koji rješava, ljudi koji ga mogu otkriti i razumjeti, sustavi koji ga održavaju pouzdanim te povratne informacije koje timu govore treba li i dalje postojati.

Kod je sredstvo, a ne ishod

Programeri se često nagrađuju za vidljiv rezultat: zatvorene tikete, izgrađene komponente, dovršene migracije, riješene incidente. To su značajni pokazatelji, ali mogu iskriviti prioritete kada postanu cjelokupna definicija napretka.

Zamislite tim koji treba dodati izvoze računa. Pristup usmjeren na kod započinje krajnjom točkom, pozadinskim zadatkom, pohranom datoteka i sučeljem. Pristup usmjeren na životni ciklus najprije postavlja korisnija pitanja: Tko treba izvoz? Koju će odluku podržati? Koliko skup podataka može postati velik? Sadrži li izvoz osjetljive informacije? Kako će osoba znati da je spreman? Što se događa kada generiranje ne uspije na pola puta?

Drugi pristup i dalje može proizvesti istu krajnju točku. No vjerojatnije je da će proizvesti funkcionalnost kojoj ljudi mogu vjerovati i koristiti je bez zahtjeva za podršku.

Vlasništvo ne znači osobno obavljati svaki zadatak. Znači ostati odgovoran za rezultat proizvoda preko granica koje je lako zanemariti: dizajn, operacije, podršku, analitiku, dokumentaciju, pristupačnost, sigurnost i povlačenje iz upotrebe.

Započnite s problemom i njegovim ograničenjima

Prije rasprave o implementaciji, konkretizirajte problem. Nejasni zahtjevi stvaraju tehnički elegantna rješenja za slabo shvaćene potrebe. Kratak razgovor može otkriti je li stvarna potreba brzina, sigurnost, usklađenost, vidljivost ili zaobilazno rješenje za nešto drugo što je pokvareno.

Korisno oblikovanje uključuje četiri dijela:

• Korisnik: Tko doživljava problem, uključujući manje vidljive korisnike poput administratora ili osoblja za podršku?
• Zadatak: Što pokušavaju ostvariti i što im to danas otežava?
• Ishod: Koja bi vidljiva promjena pokazala da je problem bolje riješen?
• Ograničenja: Što mora ostati sigurno, pouzdano, pristupačno, razumljivo ili povratno?

Ovo nije zahtjev za opsežnim dokumentima o proizvodu. To je način da se izbjegne gradnja na pretpostavkama. Tehnički voditelj često može poboljšati projekt jednostavnim preoblikovanjem zahtjeva ovim izrazima i traženjem potvrde od dionika.

Dizajnirajte za cijelo putovanje

Prva uspješna demonstracija obično je najmanje zahtjevan trenutak u životu funkcionalnosti. Stvarni korisnici dolaze s nepotpunim podacima, sporim vezama, neuobičajenim dozvolama, starim zapisima, suprotstavljenim prioritetima i razumnim očekivanjima da će im sustav objasniti sam sebe.

Vlasništvo nad proizvodom znači razmatrati putovanje, a ne samo sretan put. Za asinkroni izvoz to putovanje može uključivati jasnu radnju zahtijevanja, potvrdu da je obrada započela, sigurnu obavijest kada je datoteka spremna, razumljivu pogrešku ako se ne može izraditi i ograničeno razdoblje čuvanja osjetljivih datoteka.

Ovi detalji nisu dotjerivanje dodano nakon „pravog inženjerstva”. Oni su mjesto gdje kvaliteta proizvoda postaje vidljiva.

Učinite neuspjeh osmišljenim iskustvom

Svaka ovisnost može biti spora, nedostupna ili pogrešna. Svaki se red može zagušiti. Svaka implementacija može otkriti pretpostavku koja je lokalno bila nevidljiva. Timovi ne trebaju predvidjeti svaki neuspjeh, ali trebaju odlučiti kako se proizvod ponaša kada se dogode važni neuspjesi.

Za svaki kritični tijek utvrdite što korisnik vidi, što tim može promatrati i kako izgleda oporavak. Poruka o pogrešci trebala bi korisniku reći što se dogodilo i što može učiniti sljedeće. Nadzor bi timu trebao pomoći razlikovati izolirani problem od sustavnog. Oporavak bi trebao izbjeći da netko nepotrebno ponavlja rad.

Takav način razmišljanja također poboljšava odluke o implementaciji. Idempotentne operacije, ograničeni ponovni pokušaji, smisleni zapisnici i eksplicitna stanja lakše se opravdavaju kada je tim opisao putanje neuspjeha koje podržavaju.

Izdavanje je početak učenja

Implementacija potvrđuje da je softver stigao u produkciju. Ne potvrđuje da je proizvod stvorio vrijednost. Tretiranje izdanja kao kraja potiče timove da odmah prijeđu na sljedeći tiket, ostavljajući neodgovorena pitanja iza sebe.

Umjesto toga, prije izdanja odlučite što ćete nakon njega naučiti. To može biti mali skup signala: dovršetak ključnog tijeka rada, vrijeme potrebno za njegov dovršetak, zahtjevi za podršku povezani s promjenom, stope pogrešaka ili izravne povratne informacije ljudi koji ga koriste. Odaberite signale koji se povezuju s namjeravanim ishodom, a ne samo s aktivnošću.

Zatim odredite namjernu točku praćenja. Pregledajte što se dogodilo, usporedite to s izvornom hipotezom i odlučite treba li funkcionalnost doraditi, proširiti, pojednostaviti ili ukloniti. Uklanjanje nekorištene funkcionalnosti može biti izvrstan rad na proizvodu. Smanjuje održavanje, zbunjenost i budući rizik.

Vlasništvo treba jasne granice u udaljenim timovima

Rad na daljinu čini nevidljive pretpostavke skupljima. Pojašnjenje u hodniku postaje odgođena poruka. Odluka koja se čuva u sjećanju jedne osobe postaje nedostupna ostatku tima. Vlasništvo u ovom okruženju manje se odnosi na stalnu dostupnost, a više na to da napredak bude razumljiv.

Dobro vlasništvo na daljinu stvara lagani zajednički kontekst. Zabilježite odluku, razlog za nju, otvorene rizike i sljedećeg vlasnika. Zapišite što znači „gotovo”. Rano istaknite kompromise, osobito kada je zahtjev u sukobu s pouzdanošću, privatnošću ili održivim održavanjem.

Asinkrona komunikacija najbolje funkcionira kada drugima daje dovoljno informacija da promišljeno odgovore. „Odabrao sam opciju A jer smanjuje operativnu složenost; preostala je zabrinutost vraćanje migracije” mnogo je korisnije od „implementirao sam A”. Poziva na odgovarajući pregled i sprječava tiho neslaganje.

Izgradite održive navike isporuke

Vlasništvo od početka do kraja ne bi trebalo postati kultura herojstva. Ako svako izdanje zahtijeva kasnonoćnu budnost istih ljudi, proces nije u vlasništvu; krhak je.

Održivi timovi odgovorno ponašanje čine lakim putem. Automatiziraju ponovljive provjere, održavaju implementacije povratnima gdje je to praktično, dokumentiraju rutinske operacije, dijele znanje o domeni i rezerviraju kapacitet za održavanje. Također ograničavaju rad u tijeku kako nove ideje ne bi zatrpale nedovršene obveze.

Tehnički dug pripada ovom razgovoru, ali treba ga opisati pojmovima proizvoda. Krhka integracija nije samo neuredan kod; može usporiti promjenu usmjerenu prema korisnicima, povećati rizik od incidenata ili spriječiti tim da odgovori na stvarnu priliku. Povezivanje duga s posljedicama čini određivanje prioriteta jasnijim.

Razvijte se od implementatora do tehnologa usmjerenog na proizvod

Ne trebate titulu upravljanja proizvodom da biste prakticirali razmišljanje o proizvodu. Počnite proširivanjem pitanja koja postavljate oko svojeg sljedećeg dijela posla. Pročitajte razgovore s podrškom. Prisustvujte razgovoru s korisnikom kada je prikladno. Pitajte kako će se procjenjivati uspjeh. Pregledajte ponašanje onoga što ste isporučili.

S vremenom to mijenja vaš ugled. Ljudi vas prestaju vidjeti kao nekoga tko prima zahtjeve i počinju vas vidjeti kao nekoga tko pomaže oblikovati dobre odluke. To nije zato što napuštate tehničku dubinu. To je zato što tu dubinu primjenjujete ondje gdje ima najveći učinak.

Najjači tehnološki stručnjaci ne posjeduju svaku liniju koda zauvijek. Posjeduju odgovornost da pomognu proizvodu ostati korisnim, razumljivim, otpornim i vrijednim održavanja. Kod otvara vrata. Vlasništvo nad životnim ciklusom proizvoda ono je što čini rad važnim nakon što prođete kroz njih.