Plan razvoja proizvoda često se zamjenjuje za obećanje: uredan slijed funkcionalnosti, datuma i izdanja koji neizvjesnu budućnost čini konačnom. Ta je iluzija utješna, osobito kada je tim pod pritiskom da pokaže napredak. No najkorisniji planovi razvoja čine nešto zahtjevnije. Pomažu ljudima donositi bolje odluke prije nego što neizvjesnost postane skupo iznenađenje.

To je vrijednost anticipativnog dizajna. Ne radi se o ispravnom predviđanju svake promjene. Radi se o oblikovanju proizvoda, tehničkog pristupa i procesa isporuke tako da se vjerojatne promjene lakše prihvate. Plan razvoja postaje manje poput voznog reda vlakova, a više poput navigacijskog sustava: pokazuje smjer, utvrđuje ograničenja i ponovno izračunava put kada se stvarnost promijeni.

Planovi razvoja trebaju izražavati namjeru, a ne lažnu preciznost

Timovima je potrebna jasnoća, ali jasnoća ne znači uvijek točne datume. Na početku inicijative za razvoj proizvoda najveće nepoznanice mogu se odnositi na ponašanje kupaca, kvalitetu podataka, ograničenja integracije, sigurnosne zahtjeve ili napor potreban za pouzdano upravljanje rezultatom. Predstavljanje tih nepoznanica kao fiksnih obveza ne uklanja rizik; samo ga skriva do kasnije.

Snažniji plan razvoja razlikuje ishode, prilike i obveze. Ishod bi mogao biti smanjenje vremena koje timu za podršku treba za rješavanje uobičajenog zahtjeva. Prilika bi mogla biti samostalno upravljanje računom. Obveza je manji skup posla koji je tim spreman isporučiti s definiranim opsegom i razinom sigurnosti.

Ta razlika tehničkim voditeljima daje iskreniji jezik. Umjesto da kažete: „Pokrenut ćemo cijeli tijek rada u trećem tromjesečju”, recite: „Najprije provjeravamo tijek rada s najvećim opsegom; sljedeće izdanje ovisi o tome što saznamo o provjeri identiteta i obradi iznimki.” Druga izjava nije slabija. Ona dionicima govori čime se upravlja.

Predvidite promjene na spojevima

Većina skupih iznenađenja pojavljuje se na granicama: između usluga, timova, dobavljača, platformi ili pretpostavki. Funkcionalnost može izgledati jednostavno u maketi, ali postati zahtjevna kada su joj potrebne dozvole, povijest revizije, obavijesti, migracije, pristupačnost ili alati za podršku.

Anticipativni dizajn postavlja praktična pitanja prije nego što se tim duboko obveže:

• Koja bi nas pretpostavka, ako se pokaže pogrešnom, prisilila da redizajniramo tijek rada?
• Koja vanjska ovisnost ima najdulje vrijeme pripreme ili najmanje predvidljivo ponašanje?
• Gdje će se pojaviti iznimke kupaca?
• Koji podaci moraju ostati točni ako se zahtjev ponovi, odgodi ili djelomično ne uspije?
• Koji će operativni posao postojati nakon objave funkcionalnosti?

Razmotrite stavku plana razvoja za zakazani izvoz izvješća. Vidljivi zahtjev može biti jednostavan: korisnici odaberu izvješće i prime ga e-poštom. Anticipativni rad mjesto je na kojem je vodstvo važno. Može li se izvoz generirati dvaput bez stvaranja zabune? Što se događa ako dostava ne uspije nakon uspješnog generiranja? Jesu li izvješća dostupna korisnicima čiji se pristup promijeni između zakazivanja i dostave? Kako će osoblje za podršku pregledavati neuspjehe bez pristupa osjetljivim podacima?

Ta pitanja ne zahtijevaju izgradnju svakog rubnog slučaja prije nego što saznamo cijene li korisnici tu funkcionalnost. No zahtijevaju odabir implementacije koja za njih ostavlja prostor. Primjerice, odvajanje generiranja izvješća od dostave e-poštom olakšava ponovne pokušaje i vidljivost u odnosu na smještanje obje radnje u jedan krhki put zahtjeva.

Koristite horizonte s različitim razinama detalja

Plan razvoja trebao bi postajati manje precizan što dalje seže u budućnost. Kratkoročni rad može uključivati konkretne isporučive rezultate, uvjete prihvaćanja i operativnu spremnost. Srednjoročni rad trebao bi opisivati probleme koje treba riješiti i sposobnosti koje treba razviti. Dugoročno planiranje obično je najbolje izraziti kao strateški smjer, segmente kupaca ili ograničenja kojima se organizacija očekuje baviti.

Takav pristup sprječava čest obrazac neuspjeha: trošenje tjedana na usavršavanje planova na razini funkcionalnosti za rad koji ovisi o otkrićima koja još nisu učinjena. Također čini preglede plana razvoja produktivnijima. Rasprava se pomiče s obrane zastarjelih procjena na odlučivanje o tome koji bi dokazi opravdali sljedeće ulaganje.

Praktičan pregled plana razvoja

Na redovitom pregledu proučite svaku značajnu inicijativu kroz četiri leće:

• Vrijednost: Koji problem kupca ili poslovanja ovo treba poboljšati?
• Dokazi: Što smo naučili što podupire predloženi smjer?
• Sigurnost: Koje pretpostavke ostaju neprovjerene i koliko su važne?
• Spremnost: Jesu li dizajn, inženjering, sigurnost, operacije i podrška spremni za sljedeći korak?

Ako se inicijativa ne može objasniti kroz te leće, možda je i dalje valjana ideja. Jednostavno još nije spremna biti predstavljena kao obveza isporuke.

Učinite odgovornost vidljivom u udaljenim timovima

Udaljenim i distribuiranim timovima potrebni su planovi razvoja koji funkcioniraju bez stalnog tumačenja. Slajd koji ima smisla samo kada je prisutan njegov autor stvara skrivene troškove koordinacije. Ljudi popunjavaju praznine razumnim, ali različitim pretpostavkama, a te se razlike pojavljuju kasno.

Za svaku aktivnu stavku plana razvoja učinite lako dostupnima mali skup činjenica: namjeravani ishod, odgovornog vlasnika, glavne ovisnosti, trenutačnu razinu sigurnosti, datume odluka i sljedeću prekretnicu u učenju. Vlasnik nije nužno osoba koja piše kod ili upravlja svakim zadatkom. Vlasništvo znači da netko održava povezanost problema, kompromisa i komunikacije.

Pisani zapisi odluka posebno su vrijedni kada se plan razvoja promijeni. Kratak zapis može navesti što se promijenilo, zašto se promijenilo, koji su dokazi utjecali na odluku i koje posljedice tim prihvaća. Time se čuva kontekst za kolege u drugim vremenskim zonama i sprječava da se promjene smjera pogrešno protumače kao neuspjeh.

Dobra udaljena suradnja također znači odvajanje dijeljenja informacija od donošenja odluka. Ažuriranje statusa može biti asinkrono. Odluka koja uključuje velik kompromis zaslužuje definiranog vlasnika, rok za donošenje odluke i izričit doprinos pogođenih osoba. Ne zahtijeva svaka rasprava sastanak, ali svaka važna odluka zahtijeva jasan zaključak.

Gradite za reverzibilan napredak

Održiva isporuka ne znači izbjegavanje rizika. Znači preuzimanje rizika u koracima koji se mogu promatrati, ispraviti ili zaustaviti. Planovi proizvoda i inženjeringa trebali bi davati prednost malim izdanjima, mjerenom usvajanju, zastavicama funkcionalnosti gdje je to prikladno i putovima migracije koji se mogu pratiti.

Za novi tijek naplate tim bi najprije mogao podržati interno testiranje, zatim ograničenu skupinu kupaca, pa širu dostupnost nakon potvrđivanja procesa usklađivanja i podrške. Plan razvoja može ih prikazati kao faze učenja i uvođenja umjesto da se pretvara kako funkcionalnost ima samo dva stanja: nedovršeno i dovršeno.

Takav način razmišljanja mijenja tehničke izbore. Timovi mogu rano ulagati u zapisivanje, idempotentne operacije, jasne postupke povrata i granice domene ne zato što svaki proizvod zahtijeva razrađenu arhitekturu, nego zato što ti izbori smanjuju trošak pogreške. Prava razina pripreme razmjerna je vjerojatnom učinku neuspjeha i težini oporavka.

Plan razvoja je instrument vodstva

Plan razvoja ne uklanja dvosmislenost za tim. Njegov je posao učiniti dvosmislenost predmetom rasprave, odgovornosti i djelovanja. Kada voditelji izlože pretpostavke, uče prije skaliranja i štite prostor za prilagodbu, stvaraju organizaciju za razvoj proizvoda koja se može kretati sa svrhom bez postajanja krutom.

Plan razvoja koji se pamti nije onaj koji je predvidio svaki zaokret. To je onaj koji je timu pomogao prepoznati zaokret dovoljno rano da ga dobro izvede.