U mrtvim uglovima se kriju problemi koji često previđamo, koji nas hvataju nespremne ili nas prosto iznenade.

Procene koliko nam vremena za nešto treba su čest izvor razočarenja kod ljudi koji se na njih oslanjaju. Desilo se hiljadama puta (i desiće se opet) situacije gde klijent, menadžment kompanije, netehnički suosnivač i slični pitaju programere kada misle da će nešto biti gotovo, ovi odgovore i promaše ne za mali procenat, već i za po nekoliko puta planirano vreme. Situacija je toliko frustrirajuća da postoje struje razmišljanja da se programerima ne može verovati na procenama, da uopšte ne treba procenjivati itd.

U redu je da ne pripadate tim strujama razmišljanja i da smatrate da je neki oblik procenjivanja predstojećeg posla bitan. To i dalje ostavlja niz otvorenih pitanja, pre svega zašto su nam procene uglavnom loše i kako da budu bolje?

Tim pitanjima valja pristupiti iz niza uglova, a jedan od njih su nešto što zovem mrtvim uglovima. U vožnji mrtvi uglovi su deo vidnog polja koji nisu pokriveni retrovizorima. U njima može vrlo lako da se krije vozilo i da imamo ozbiljan problem ako krenemo da se prestrojavamo, skrećemo ili isparkiravamo.

Tipovi mrtvih uglova

Kao i u saobraćaju, kao pojedinci i timovi takođe imamo mrtve uglove u pogledu toga šta vidimo i kako razumemo stvari koje nas okružuju. U našim spoznajnim mrtvim uglovima se kriju stvari koje grubo možemo podeliti u tri grupe:

  1. stvari za koje znamo, ali nas uvek uhvate nespremne,

  2. stvari čijeg postojanja nismo svesni,

  3. stvari za koje ne želimo da znamo jer se kose sa našim uverenjima.

Mrtvi uglovi mogu biti na puno nivoa i u raznim oblicima, tako da ovaj članak može da ide na puno strana. Da ne bih išao previše široko, u ovom članku ću se skocentrisati samo na jednu grupu mrtvih uglova: propusti koje razvojni timovi prave dok rade na softveru koji je potreban znanom korisniku. Ne bih da ulazim u strategije, istraživanje tržišta, traženje "svog mesta pod Suncem" itd. Tržišnu neizvesnost bih ostavio po strani i forkusirao se na stvari vezane za sam proces razvoja, od trenutka kada nešto odlučimo do napravimo, preko same izrade, do trenutka kada je to nešto u rukama korisnika.

Gledajući taj suženi krug, nad kojim bi razvojni timovi trebalo da imaju uticaj, možemo izvući neke praktične tehnike za rad sa mrtvim uglovoma. Različiti tipovi mrtvih uglova povlače različite tehnike.

Tip #1: Poznato, ali uvek iznenadi

Počeo bih od stvari koje su nam poznate, ali koje nas često hvataju nespremne. Npr, dok radim na ActiveCollab web aplikacija, nama je tamna tema često u mrtvom uglu. Kada pravimo prototip, on je uvek u svetloj temi. Ako se desi da preskočimo da koncipiramo izgled u tamnoj temi, često moramo da se vraćamo na doradu kada vidimo da stvari nisu ispale baš kako treba.

Da bi imali što manje ovakvih propusta, mi smo počeli mrtve uglove da zapisujemo na kartice i lepimo u desni ugao na tabli u kancelariji za sastanke:

Vremenom su se uz tamnu temu tu našli i izgled interfejsa na užim ekranima (responsive), lokalizacija, šabloni za projekte itd.

Ta lista je korisna kad pričamo o funkcionalnostima koji tek treba da radimo. Pri kraju razgovora, kada mislimo da smo sve lepo dogovorili i definisali, prođemo i kroz listu mrtvih uglova i proverimo da nismo nešto preskočili. Bolje da problem uhvatimo tad i sa boljim razumevanjem uđemo u razvoj, nego da nas sačeka kad krenemo da radimo, jer baš tada dolazi do širenja obima posla i probijanja rokova.

Ovu praksu smo privremeno napustili kada smo prešli na remote način rada, gde nismo imali listu kartica stalno pred očima. U takvom način rada rešenje može biti da se napravi šablon za nove zadatke koji sadrži i listi mrtvih uglova kroz koje treba proći kada se zadatak specifikuje, vođa projekta može zalepiti sticky belešku na svoj radni sto sa listom mrtvih uglova itd. Poenta je da budu na očima, jer samo tako prestaju biti “mrtvi uglovi“ i postaju prosto “uglovi“.

Tip #2: Nepoznato

Nepoznato kao mrtav ugao je jako širok problem koji prevazilazi okvire onoga što sam hteo ovom člankom da pokrijem - praktične tehnike za smanjenje neprijatnih iznenađenja u projektima. Čak i sa tim na umu, ima par stvari na koje bih u ovom članku pomenuo jer imaju praktičnu korist.

Ne treba na sve iznenadne i neplanirane događaje gledati kao negativne. Često su takvi, ali umeju biti i izuzetno pozitivni. Pandemija COVID19 je negativno uticala na većinu ugostiteljskih poslova, ali je takođe pozitivno uticala na mnoge, Zoom na primer.

U takvim okolnostima, trik je da ne budemo previše investirani ili izloženi negativnim efektima, a otvoreni za moguće pozitivne. Dve stvari pomažu: držanje otvorenih opcija i kontrolisano izlaganje riziku sa velikom šansom za povrat. Opcije držimo otvorene tako što sistematično parčamo posao, polazimo od hipoteza, testiramo u brzim i kratkim iteracijama, ne zadužujemo se prekomerno i nesmotreno.

Barbell strategija je tip investiranja iza koga stoji ideja da većinu resursa treba da uložimo u sigurne aktivnosti, a mali deo tako da se izložimo slabo verovatnom, ali mogućem visokom povratu. Obično se prikazuje kao neravnomerno raspoređen teg (otud barbell):

U ovom tipu investiranja, veći deo naših resursa (90% npr) ulažemo u aktivnosti od kojih očekujem mali, ali siguran povrat. Ostalih 10% ulažemo u visoko rizične aktivnosti kod kojih postoji mala šansa za velikim dobitkom. U sredinu ne ulažemo ništa.

Ako ste proizvodna softverska kompanija na primer, potpuno je razumno posvetiti većinu resursa na razvoj softvera i mogućnosti na osnovu potreba postojećih i njima sličnih korisnika. Sa druge strane, barbell nam kaže da bar 10% resursa uložimo u visoko rizične projekte za koje postoji šansa da će napraviti veliki rezultat.

 

Tip #3: Ne želimo da znamo

Koliko god sebe i svoje organizacije smatrali otvorenim za nove ideje i temeljnim u istraživanju, niz naučnih istraživanja pokazuju da smo podložni velikom broju spoznajnih propusta. Jedno od njih je konfirmacioni bajas, naša sklonost da pronalazimo, tumačimo, favorizujemo i sećamo se informacija koje potvrđuju naše postojeće stavove i uverenja.

Ukratko, u našoj pojedinačnoj i društvenoj prirodi je da razvijemo mrtav ugao ka idejama koje nisu u skladu sa našim uverenjima.

Konfirmacioni bajas je zanimljiva tema koja verovatno zalužuje zaseban članak. U okviru ovog bih pomenuo par tehnike koje razvojni timovi mogu da koriste da spoznaju neke od stvari koje se kriju u “ne želimo da znamo“ mrtvom uglu:

  1. Uzimanje u obzir niza alternativa, čak i onih koje nam se na prvu ne sviđaju. Probajte paralelan razvoj sukoboljenih alternativa i vidite koja se bolje drži. Npr, Apple je pravio dve verzije operativnog sistema za budući iPhone, jednu baziranu na iPod softveru, a drugu na Mac OS-u pre nego što su doneli odluku šta će da koriste,

  2. Postavljanje razvoja oko hipoteze, koju podaci mogu da potvrde ili ospore. Hipotezi zapišite pre razvoja i navedite koji uslovi i do kada treba da budu ispunjeni da bi ste je smatrali potvrđeno ili osporenom.

  3. Usitnjavanje posla sa ciljem da se što više učenja o korisnicima i njihovim potrebama desi što pre, kako ne bismo ulagali previše energije i resursa u stvari koje ne rade. Kao tim uvek imamo stav da će korisnici ono što napravimo koristiti ovako ili onako, ali u stvarnosti ne znamo dok ne počnu da koriste naše rešenje. Neka se to desi što pre,

  4. Debatovanje o dubokim organizacionim uverenjima, uz zauzimanje strane i za i protiv. Agile je dobar za naše timove, a možda i nije? Našem softveru trebaju AI mogućnosti čim pre, a možda i ne? Što tema više polarizuje ljude, bolji je materijal za debatu,

  5. Posvećivanje pažnje slabim signalima. Načuli ste da konkurent radi na nečemu što smatrate pretnjom? U logovima sa sporadično pojavljuju greške koje sad ne prave problem, ali možda ukazuju da isti nastaje? Istražite. Nemojte okretati glavu od takvih stvari. Neki problemi u početku šalju slabe signale, a kada eskaliraju budu puno ozbiljniji i skuplji za opravku,

  6. Upravljanje rizicima. Ovo može biti složen proces, a može biti i prost. Jedan dokument gde navedete rizik, verovatnoću da će da se materijalizuje, šta planirate da uradite da smanjite verovatnoću i šta ćete da uradite ako se rizik materijalizuje.

Zaključak

Ni jedna od ovih tehnika nas neće spremiti za sve mogućnosti, jer su one beskonačne i možemo svo vreme samo o rizicima pričati. To nije način da se napreduje. Sa tim na umu ipak nije zgoreg odvojiti neko vreme i pozabaviti se onim stvarima za koje jesu pod našom kontrolom: redovnim osvrtima na stvari za koje znamo da mogu neprijatno da nas iznenade, dubinom sopstvenih uverenja koja nas zaslepljuju i rad na takav način da promenom okolnosti ne gubimo sve.

Reference

 

Jeffrey K. Liker “The Toyota Way“

Eric Ries “The Lean Startup“

Nassim Nicholas Taleb “Skin in the Game“

Confirmation Bias

…