Kako pregledati 100 komentara na specifikaciju bez beskonačnih sastanaka

Zamislite situaciju. Naručilac je ugovorio izradu novog IT sistema. Implementator, kao dio svoje obaveze, izrađuje funkcionalnu specifikaciju i dostavlja je naručiocu na pregled. Naručilac za tu svrhu formira Tim od desetak ljudi čiji je zadatak da provjeri da li dokument ispravno i potpuno pokriva ono što je ugovoreno. Svako iz Tima unese svoje primjedbe, implementator na njih odgovori, i nakon nekoliko sedmica na stolu je dokument sa nekoliko desetina, možda i preko stotinu komentara i odgovora.

Sve to treba zatvoriti do fiksnog ugovorenog roka, koji se ne pomjera zato što je pregled trajao duže nego što se planiralo. Na velikim implementacijama jedan loše vođen sastanak lako potroši desetine sati rada ljudi, a svaka sedmica izgubljena na neorganizovanu raspravu često znači kašnjenje projekta.

I onda Tim zakaže sastanak da se to "prođe". Prva primjedba je sitna terminološka nedoumica, riješi se za dva minuta. Druga je suštinsko pitanje koje mijenja arhitekturu cijelog sistema, i o njoj se raspravlja četrdeset minuta jer niko nije došao pripremljen baš za nju. Treća je nešto što implementator kaže da nije predmet ugovora, ali niko na licu mjesta nema tenderski dokument da provjeri da li je to tačno. Sat vremena prođe, obrađeno je petnaest od sto komentara, a najvažnija pitanja, ona koja zaista nose rizik, ostala su neotvorena.

Problem nije u broju primjedbi. Problem je što se svaki komentar tretira na isti način, kao da svi nose istu vrstu odluke i isti nivo rizika. Postoji jednostavan okvir koji ovaj problem rješava: primjedbe se razvrstavaju u tri kolone, prema vrsti odluke koju zahtijevaju, prije nego što iko sjedne za sto.

Ko piše specifikaciju i ko je pregleda

Izrada funkcionalne specifikacije primarno je obaveza implementatora, ali uz obavezno aktivno učešće naručioca. U IT industriji ta podjela odgovornosti obično izgleda ovako:

• Implementator (vodi proces). Odgovoran je za tehničko uobličavanje, pisanje i strukturiranje dokumenta. On prevodi poslovne želje naručioca u detaljne funkcionalne zahtjeve, dakle definiše kako će sistem raditi.
• Naručilac (daje ulazne podatke). Odgovoran je za analizu zahtjeva i definisanje poslovnih ciljeva, dakle šta sistem mora da postigne. Naručilac mora obezbijediti pristup ključnim korisnicima i biznis analitičarima kako bi implementator dobio tačne informacije.

Tim naručioca ne piše dokument, ali njegov posao nije ni pasivno čekanje gotovog proizvoda. Tim je mehanizam kroz koji naručilac aktivno provjerava da li je implementator njegove poslovne zahtjeve tačno preveo u tehnički jezik. Ovo je uobičajen dio upravljanja zahtjevima na svakoj većoj IT implementaciji.

Rješenje su tri kolone

Umjesto da primjedbe obrađujete redoslijedom kojim su stigle, razvrstajte ih unaprijed, prije sastanka, u tri kategorije:

Usvaja se. Implementator je formalno prihvatio primjedbu i unio izmjenu u dokument. Ovdje zadatak nije rasprava, nego provjera. Da li tekst koji je zaista dorađen pokriva ono što je traženo, ili samo zvuči kao da pokriva? Ovo je najbrža kolona kad je usvajanje stvarno, ali i mjesto gdje se najlakše provuku formalno prihvaćene a suštinski prazne izmjene.

Traži pojašnjenje. Ni jedna ni druga strana nemaju dovoljno jasnu sliku da donesu odluku. Ova kolona ide u oba smjera: nekad je nejasna primjedba naručioca, koju treba preformulisati, a nekad je nejasan odgovor implementatora, koji treba dodatno pojasniti ili dokazati.

Odbija se ili nije predmet. Implementator tvrdi da nešto ne spada u obavezu. Ovdje se ne raspravlja usmeno, nego se provjerava prema izvornom dokumentu. Ako osnov postoji, stavka se vraća implementatoru sa konkretnim citatom, kao formalni change request ako mijenja obuhvat. Ako osnova nema, stavka izlazi iz procesa, ne ostaje "otvorena" i ne ide dalje u radionicu.

U praksi to izgleda ovako:

       100 komentara
             │
             ▼
   ┌───────────────────┐
   │  Razvrstavanje     │
   └───────────────────┘
       │        │        │
       ▼        ▼        ▼
  Usvaja se  Pojašnjenje  Odbija se
   (provjera)  (rok+osoba)  (provjera ugovora)
    

Da ilustrujemo razliku brojkama (ilustrativan primjer, ne podaci sa stvarnog projekta): na implementaciji ovog obima, 127 primjedbi bi se moglo razvrstati otprilike ovako, 74 odmah usvojeno uz kratku provjeru formulacije, 31 traži pojašnjenje uz jasno dodijeljenu osobu i rok, 22 zahtijeva provjeru ugovora prije nego što se zatvore. Umjesto četiri višesatna sastanka bez jasnog ishoda, posao se realno može završiti za jedno prijepodne.

Jedno pravilo koje se pokazalo ključnim: dokument koji definiše ŠTA se gradi i sastanak koji rješava KAKO se to implementira ne smiju se miješati. U radionicu smiju ući samo stavke za koje je obuhvat već potvrđen. Ako se u radionicu ubaci pitanje da li je nešto uopšte u obuhvatu ugovora, radionica prestaje da bude mjesto za "kako" i postaje mjesto gdje se obuhvat neformalno pomjera, bez pisanog traga, van formalnog scope managementa koji bi svaku takvu promjenu trebalo da prati.

Zašto se ovo dešava baš u ovom obliku

Cijela situacija opisana gore karakteristična je za Waterfall način rada, gdje se jedan obiman dokument zaključava prije početka razvoja. U Agile/Scrum okruženju klasična funkcionalna specifikacija u jednom fajlu ne postoji, umjesto toga je razbijena na dinamičan Product Backlog koji se gradi tokom cijelog razvoja.

Razlika nije samo formalna. Waterfall FSD se zaključava jednom, a svaka naknadna izmjena postaje formalni change request. Agile Product Backlog se svjesno gradi kao živ dokument. Zato scenario sa stotinom primjedbi na jedan zaključan dokument uopšte nastaje kao problem: cijeli teret preciznosti mora biti riješen unaprijed, prije prve linije koda. Tri kolone su način da se taj jednokratni teret ipak obradi razumno, kad god vas ugovor obaveže na waterfall pristup.

Kako je sa Scrumom

Ovaj problem nije specifičan za IT ugovore. To je isti problem koji Product Owner rješava svake sedmice. Kad stakeholderi zatrpaju backlog idejama i primjedbama, loš Product Owner ih obrađuje redom kojim stignu. Dobar Product Owner pravi trijažu na način da neke stavke su spremne, to je refinement u smislu provjere da li napisano odgovara mišljenom. Neke zahtijevaju pojašnjenje prije nego što uopšte mogu ući u razgovor o prioritetu, to je suština Definicije spremnosti. Neke ne spadaju u proizvod uopšte, i njih treba iskreno odbiti umjesto da se nalaze na dnu backloga.

Granica između specifikacije (ŠTA) i radionice (KAKO) odgovara granici između Product Backlog stavke i Sprint Backloga. Product Owner odlučuje šta ulazi u obuhvat, tim odlučuje kako će to implementirati unutar sprinta. Kad se te dvije odluke pomiješaju, dobijate isti haos kao kad se na tehničkoj radionici odjednom otvori pitanje obuhvata.

I tako...

Ljudi često misle da veliki projekti propadaju zbog lošeg softvera. Mnogo češće propadaju zato što se važne odluke izgube među nevažnim komentarima. Tri kolone nisu samo način organizacije komentara. One su način organizacije pažnje.