Ideja je bila čvrsta. Sredstva su bila osigurana. Tim motiviran. A šest mjeseci kasnije, proizvod još uvijek nije bio lansiran.

To je najčešća priča u razvoju softvera — i gotovo nikada nema veze s lošom idejom. Ima sve veze s lošim procesom.

Ovaj obrazac smo gledali kako se ponavlja kod startupa, scale-up tvrtki i enterprise timova. Različite industrije, različiti budžeti, različiti tehnološki stackovi. Isti uzorak neuspjeha. Negdje između kick-off sastanka i zamišljenog lansiranja, projekt počinje skretati. Rokovi se pomiču. Ljudi se razmještaju. Netko novi se priključi i predloži da se preispita ključna odluka. Kada konačno netko uspori i pogleda gdje smo, originalni plan je neprepoznatljiv, a polovica budžeta je već potrošena.

Brojke su brutalne

Industrijski podaci dosljedno pokazuju da između 60 i 90 posto softverskih projekata ne postiže zacrtane ciljeve. Ne zato što tehnologija nije radila, nego zato što je projekt izgubio smjer, ostao bez budžeta ili jednostavno trajao predugo da bi bio relevantan.

Neuspjeh ovdje ne izgleda uvijek kao otkazani projekt. Ponekad je gore — proizvod se lansira, ali kasno, preko budžeta i bez diferencijatora koji ga je činio vrijednim gradnje. Postaje zombi proizvod: tehnički živ, komercijalno irelevantan. Timovi ga nastavljaju održavati jer ga ugasiti znači priznati poraz, iako je tržište odavno krenulo dalje.

Razlozi su predvidivi. I baš zato su sprječivi. Svaki obrazac koji ćemo opisati nešto je što smo gledali uživo na stvarnim projektima, i svaki se može prepoznati u prvih nekoliko tjedana ako znate što tražiti.

Razlog 1: Opseg koji nikad ne staje rasti

Svaki neuspješan projekt ima trenutak u kojem je netko rekao “kada smo već tu, možemo li još i…” — a nitko nije rekao ne.

Razrastanje opsega ne događa se odjednom. Događa se kroz male, razumno zvučne dodatke koji svaki uzmu po par dana, pomaknu nekoliko prioriteta i odgađaju lansiranje za još koji tjedan. Nakon dovoljno takvih, proizvod više nije ono što ste krenuli graditi. To je naduveni kompromis koji pokušava raditi sve, a ne radi ništa dobro.

Ono što čini ovaj problem teškim za zaustaviti jest činjenica da svaki pojedini zahtjev zvuči razumno. Stakeholder vidi konkurentsku značajku. Prodaja klijentu obeća nešto što proizvod još ne radi. Dizajner usred sprinta dobije pametnu ideju. Pojedinačno, ništa od toga ne djeluje besmisleno. Skupno, to je razlog zašto se lansiranje pomiče s drugog kvartala na četvrti, a s četvrtog na “nekad iduće godine”.

Rješenje: Definirajte tvrdi opseg prije nego što razvoj uopće krene. Napišite što proizvod radi. Napišite što proizvod ne radi. Vraćajte se tom dokumentu svaki tjedan. Ako novi prijedlog značajke ne rješava ključni problem koji ste odredili, ide u backlog — ne u trenutni build. Backlog nije groblje, to je čekaonica. Dobre ideje ne nestaju, samo čekaju svoj red. Ta razlika je ono što tim drži u načinu isporuke umjesto u načinu rekonstrukcije.

Razlog 2: Razvoj u izolaciji

Drugi najčešći obrazac neuspjeha jest mjesecima graditi bez da se ikome od stvarnih korisnika išta pokaže. Tim nestane u razvoju, izroni s “gotovim” proizvodom i otkrije da nitko ne želi koristiti ono što su sagradili na način na koji su to sagradili.

To je waterfall zamka u modernom ruhu. Nije bitno koristite li agile ceremonije ako krajnji korisnik ne vidi ništa što radi sve do posljednjeg sprinta. Standupi, retrospektive i sprint reviewi su korisni — ali samo kada je u petlji stvarni korisnik. Bez toga, tim samo koordinira mišljenja umjesto da ih provjerava na stvarnosti.

Opasnost je u tome da izolirani timovi postanu jako dobri u rješavanju krivog problema. Engineering postane interno konzistentan. Codebase je čist. Arhitektura elegantna. I ništa od toga ne odgovara onome kako stvarni korisnici razmišljaju o poslu koji pokušavaju obaviti.

Rješenje: Stavite radni softver pred korisnike unutar tjedana, ne mjeseci. To ne znači lansirati — to znači testirati. Pokažite prototipove. Gledajte kako ljudi koriste. Skupljajte povratne informacije prije nego što se obvežete na arhitekturu koju je skupo mijenjati. Pet kratkih razgovora s pravim korisnicima preoblikovat će roadmap brže od pedeset internih sastanaka za planiranje.

Razlog 3: Previše ljudi u prostoriji

Veliki timovi stvaraju režijski trošak komunikacije. Svaka dodatna osoba na projektu povećava broj odnosa kojima treba upravljati, broj sastanaka koji se moraju održati i broj mišljenja koja treba uskladiti.

Tim od 3 do 5 fokusiranih inženjera gotovo će uvijek isporučiti više od tima od 15. Ne zato što manji tim radi više, nego zato što troši manje vremena na koordinaciju, a više na gradnju. Brooks je o ovome pisao prije pedeset godina i ništa u ljudskoj komunikaciji od tada se nije promijenilo. Udvostručiti tim ne znači udvostručiti učinak. Obično znači dodati mjesec rasporedu i sloj procesa koji svi tiho prezreh.

Postoji povezan problem: kada je previše stakeholdera, odluke postaju mekše. Svaka odluka postane kompromis između suprotstavljenih preferencija, što proizvodi proizvod koji nitko aktivno ne mrzi i nitko stvarno ne voli. Značajke koje proizvod čine oštrim — promišljeni, hrabri izbori — bivaju izglačani u review ciklusima.

Rješenje: Držite jezgreni razvojni tim malim. Dajte mu vlasništvo. Smanjite broj stakeholdera koji mogu mijenjati smjer. Ako svatko ima ulaz, nitko nema odgovornost. Jedna osoba treba biti vlasnik vizije proizvoda, jedna osoba vlasnik tehničkog smjera, a tim mora biti dovoljno malen da stane oko jednog stola bez mikrofona.

Razlog 4: Odabir tehnologije prije razumijevanja problema

Birati tehnološki stack prije razumijevanja problema isto je što i birati građevinski materijal prije nego što ste nacrtali tlocrt. Previše timova kreće s “koristit ćemo React i Node” prije nego što su definirali što proizvod uopće treba raditi.

Tehnološki izbori trebaju slijediti zahtjeve proizvoda, ne obratno. Ali privlačnost stack-first razmišljanja je jaka jer se osjeća produktivno. Birati framework je konkretno. Raspravljati o bazama podataka osjeća se kao napredak. U međuvremenu, nitko u prostoriji ne može u dvije rečenice objasniti tri stvari koje proizvod mora raditi bolje od bilo koje alternative na tržištu.

Vidjeli smo timove koji su tri mjeseca trošili na izradu custom mikroservisne arhitekture za proizvod koji je nakon lansiranja imao manje od dvjesto korisnika. Isti problem mogao se riješiti monolitom i managed bazom u dva tjedna. Stack je bio optimiziran za skalu koju proizvod još nije zaslužio.

Rješenje: Definirajte problem, korisnike i ključnu funkcionalnost prije svega. Zatim odaberite stack koji najbolje služi tim zahtjevima. Ponekad je to React. Ponekad WordPress. Ponekad tablica i Zapier integracija. Dosadan izbor često je pravi izbor jer vam dosadan izbor dopušta da se fokusirate na jedinu stvar koja je u verziji jedan važna — je li proizvod zapravo koristan.

Razlog 5: Nema definicije gotovog

“Lansirat ćemo kada bude spremno” nije plan. Bez jasne definicije onoga što “gotovo” znači, projekti vječno plove. Uvijek postoji još jedna značajka koju treba dodati, još jedan bug koji treba popraviti, još jedan rubni slučaj o kojem treba misliti.

Lansiranje je vještina, a kao i svaka vještina atrofira ako se ne vježba. Timovi koji često lansiraju postaju bolji u malim odlukama koje čine sljedeće lansiranje lakšim — opsegu, prioritetima, rezovima. Timovi koji odgađaju gube taj mišić. Svaki dodatni tjedan iza planiranog lansiranja čini sljedeći tjedan malo lakšim za opravdati, dok “još jedan sprint” ne postane standardni odgovor na sve.

Rješenje: Definirajte kriterije lansiranja prije nego što počnete graditi. Koji je minimalni skup značajki potreban da proizvod isporuči vrijednost svojim prvim korisnicima? To je vaš cilj lansiranja. Sve ostalo dolazi poslije. I kada zadovoljite te kriterije, lansirate — čak i ako proizvod nije savršen, čak i ako postoje poznate sitnice. Savršeno je neprijatelj isporučenog, a isporučeno je jedino što proizvodi povratne informacije koje vam trebaju da nastavite poboljšavati.

Što uspješni razvojni projekti imaju zajedničko

Projekti koji se isporučuju na vrijeme i unutar budžeta dijele nekoliko osobina koje su gotovo dosadne za nabrojati:

  • Jasan opseg definiran prije početka razvoja
  • Mali timovi s direktnim vlasništvom
  • Česte povratne informacije korisnika kroz cijeli proces gradnje
  • Tehnološki izbori vođeni zahtjevima, a ne trendovima
  • Tvrdi datum lansiranja s definiranim minimalnim setom značajki

Ništa od ovoga nije revolucionarno. Ali zapanjujuće je koliko se često ove osnove ignoriraju u korist uzbudljivijih distrakcija. Timovi radije raspravljaju o novom frameworku nego što se vraćaju pitanju je li problem koji rješavaju i dalje pravi. Radije dodaju značajku nego što ih režu tri. Disciplina nije glamurozna, dijelom zato i jest tako rijetka.

Uspješni projekti dijele i nešto što je teže opisati — neku vrstu nesumnjivog fokusa. Tim ne pokušava graditi najveću ili najpametniju verziju proizvoda. Pokušava graditi verziju koja najbrže stiže do korisnika koji plaćaju. To ograničenje mijenja svaku odluku nizvodno.

Suština

Proizvodi ne propadaju jer timovi nemaju talenta. Propadaju jer timovi nemaju fokusa. Razlika između proizvoda koji se lansira i onoga koji se ne lansira obično se svodi na proces — ne na ljude, ne na tehnologiju, ne na novac.

Ako uskoro krećete u razvoj proizvoda, najvrjednije što možete učiniti jest provesti tjedan dana u nemilosrdnom razjašnjavanju što gradite, za koga i kako “gotovo” izgleda. Zatim štitite tu jasnoću svim sredstvima. Svaki sastanak, svaki zahtjev za novom značajkom, svaki primamljivi obilazak test je hoćete li održati liniju.

Ideja je laki dio. Izvršenje je proizvod.