Blog Keba Marka: Lov na pretpostavke

crossroadsZbog sastanaka ne stignem završiti posao. Nisam dobio odgovor na e-mail, očigledno ne žele suradnju. Prekratak je sprint pa nismo uspjeli sve istestirati.
Zvuči poznato? Što je zajedničko ovim izjavama?
Radi se o pretpostavkama, u sva tri slučaja. Mogli smo ih čuti u komunikaciji s nekim, ili sami pomisliti nešto slično. U svakoj navedenoj izjavi postoji činjenica, neki problem (ne stignem završiti posao, nisam dobio odgovor na e-mail i nismo uspjeli sve istestirati), i pretpostavka uzroka (sastanak, ne žele suradnju, prekratak je sprint). Vrlo često do veza uzroka i poslijedice dolazimo automatski, bez svjesne analize. Dakle, nesvjesno odabiremo put rješenja našeg problema, bez da smo pogledali na kartu svih mogućih puteva do rješenja. Npr, postoji li još neki mogući uzrok kašnjenja našeg testa? Radi li se o našem planiranju? Ili o naglašenom “waterfallu” unutar sprinta? Ili neadekvatnoj raspodjeli kompetencija članova tima? Naravno, za rješenje opisanog problema Agile nudi retrospektivu, kao mjesto gdje će se problem analizirati i potražiti stvarni uzrok. Što se dešava onda kada nismo svjesni pretpostavki koje radimo pa druge potencijalne puteve i ne tražimo?
Utjecaj pogreške u nekim pretpostavkama biti će mali. Npr. “Nije me pozdravio na hodniku, sigurno mi je nešto zamjerio” ispraviti će se pri nekom sljedećem susretu gdje ćemo saznati da je sve u redu i da se radilo o nepažnji. No, ima i pretpostavki čije su posljedice puno ozbiljnije. Npr. ako je pretpostavka da smo shvatili requiremente za razvoj produkta na temelju nekog dokumenta pogrešna, produkt neće biti ono što je naručitelj zamislio. Čak i kad smo dobro shvatili requiremente, razgovarali s kupcem/naručiteljem, odabrati ćemo put ka rješenju problema. Kako ćemo znati da je taj put pravi, da nas približava cilju? Ukoliko odabani put ne doživljavamo kao pretpostavku koju treba potvrditi, na kraju rezultat opet može biti nezadovoljan kupac.
Nekad je i pretpostavka da kupac zna točno što mu treba pogrešna. Zamislio je da će na određeni način riješiti svoj problem i to nam rješenje prezentira u obliku requiremenata. Koliko nam treba da tu pogrešku otkrijemo? Upravo je to mjera prave agilnosti: biti svjestan same pretpostavke, i tražiti najbrži način da tu pretpostavku potvrdimo ili opovrgnemo. Gojko Adžić u svojoj je prezentaciji “Make Impacts, not Software” odlično upotrijebio metaforu GPS-a i karte grada za objašnjenje analize i testa pretpostavki. Eric Ries je u “Lean Startupu” potvrdu/validaciju pretpostavki postavio kao jedan od temelja svog modela – kako znamo da to što radimo rješava problem naših kupaca, i koliko brzo tu pretpostavku možemo potvrditi.
Male ili velike, komunikacijske ili poslovne, pretpostavke su oko nas, skrivene među činjenicama. Pretpostavljam da ce ovaj tekst pomoći u lovu na neke od njih… :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>