„Ma to je jednostavna aplikacija" - čuvena posljednja riječ svakog projekta

Zove me prijatelj Vladimir, snimatelj po profesiji, i kaže:
„Dejane, treba mi jedna jednostavna aplikacija. Raspored smjena. Ništa komplikovano, tabela, par radnika, ko kad radi. Možeš li to da mi napraviš?”

Ja kažem, hajde, ispričaj mi šta ti treba.

I tu počinje priča.

Sat i po kasnije

Sjeli smo, ja otvorio prazan dokument, i počeo zapisivati. Vladimir priča, ja pitam. On objašnjava, ja opet pitam. Na početku je izgledalo ovako:
„Ima nas 27. Problem je što svi hoće drugu smjenu. Treba nam aplikacija da to riješi.”

Zvuči jednostavno, zar ne? Tabela sa imenima, par kolona za dane u sedmici, i gotovo. Telefon bi bio dovoljan za takav zahtjev.

Ali onda sam počeo postavljati pitanja.

Dva koncepta koja mijenjaju sve

Prije nego što pređem na pitanja, moram objasniti dva koncepta koja su se iskristalisala tokom razgovora sa Vladimirom. Bez njih, ostatak priče nema smisla.

Pohlepa i skromnost. Vladimirova ekipa ima 27 snimatelja. Svi žele drugu smjenu jer im više odgovara. Ali ako svi rade u drugoj smjeni, ko će raditi u prvoj? Niko. Zato je Vladimir definisao prosto pravilo: ako neko traži drugu smjenu svaki dan u sedmici, to je pohlepa. Ako neko traži drugu smjenu samo kad mu zaista treba (recimo u srijedu jer ima obaveze ujutru), to je skromnost. Cilj aplikacije je da nagradi skromnost, a obeshrabri pohlepu.

Prioritet. Iz tog pravila prirodno proizlazi sistem prioriteta. Radnik koji traži drugu smjenu za 1 ili 2 dana u sedmici dobija prednost (prioritet) nad radnikom koji traži drugu smjenu za 3 ili više dana. Čak i ako skromni radnik unese svoj raspored kasnije, aplikacija mu daje prednost i po potrebi izbacuje pohlepnog radnika sa već zauzetog mjesta.

Sad kad znate šta znače pohlepa, skromnost i prioritet u kontekstu ove aplikacije, pogledajte kakva su se pitanja pojavila.

Pitanja koja su se nametala tokom razgovora

Kad radite sa nekim ko ima ideju „u glavi", vaš posao nije da odmah krenete programirati. Vaš posao je da tu ideju izvučete napolje, rastavite je na dijelove, i provjerite da li svi ti dijelovi zaista funkcionišu zajedno.

Evo samo dijela pitanja koja sam postavio Vladimiru tokom našeg razgovora. Svako od njih je otvorilo novu dimenziju koju on u početku nije razmatrao:

O smjenama i kvotama:

• Koliko ljudi mora biti u prvoj smjeni da bi ona uopšte mogla funkcionisati? A koliko smije biti u drugoj?
• Recimo da za drugu smjenu ima mjesta za 4 čovjeka, a prijavi se 5. Da li primamo petog ili je 4 limit?
• Vas je 27 radnika, ali za obje smjene (u jednom danu) treba 15. Šta rade ostalih 12 tog dana?

O prioritetnom algoritmu:

• Rekao si da skromni radnici imaju prednost. Ali šta ako dva skromna radnika traže isti dan, a ostalo je samo jedno mjesto? Ko ga dobija?
• Kad skromni radnik izbaci pohlepnog sa popunjene kvote, šta se dešava sa tim izbačenim? Da li ga obavijestimo? Da li automatski ide u prvu smjenu?
• Ako neko traži 1 dan u drugoj smjeni i 4 slobodna dana, da li je i dalje skroman? Ili slobodni dani mijenjaju kalkulaciju?
• Da li se prioritet računa za svaki dan posebno ili za čitavu sedmicu odjednom?

O vikendu (koji ima potpuno drugačiju logiku):

• Da li radnik za subotu i nedjelju bira jednu opciju, ili kombinaciju prvog i drugog izbora? Npr. „želim slobodan, ali ako ne može, onda prva smjena”?

O vremenskom okviru:

• Za sljedeću sedmicu se otključava unos rasporeda svakog petka u periodu od 08:00 do 12:00. Nakon 12:00 se zaključava.
• Šta ako radnik počne popunjavati ali ne završi na vrijeme?
• Šta ako neko upošte ne popuni?
• Šta ako petak padne na praznik?

O administratoru:

• Može li admin mijenjati raspored nakon što se zaključa?
• Može li admin mijenjati ograničenja za smjene (npr. sa 4 na 5 mjesta za drugu smjenu)?
• Može li brisati radnike koji više ne rade?

O prikazu i korisničkom iskustvu:

• Da li radnik vidi rasporede svih kolega ili samo svoj?
• Da li vidi koliko je mjesta slobodno za drugu smjenu prije nego izabere?
• Kako tačno bira smjenu? Klikom na „Prva"/„Druga" za svaki dan?

I ovo nije ni kompletan spisak. Ovo su samo neka pitanja koja su bila neophodna da bismo uopšte mogli napisati funkcionalni zahtjev, dokument koji opisuje šta aplikacija treba da radi, prije nego što iko napiše i jednu liniju koda.

Vladimirova reakcija

Zanimljiv je bio jedan momenat. Na početku razgovora Vladimir je rekao da će aplikaciju lično finansirati. Ništa veliko, mislio je. Jednostavna stvar, par dana posla, „brzo gotovo".

Ali kako su pitanja nicala jedno za drugim, kako se svaka „jednostavna" stvar pretvarala u tri nove odluke, shvatio je da ovo ipak nije aplikacija koja se može objasniti putem jednog telefonskog poziva.

Na kraju razgovora ponudio mi je kompenzaciju u vidu usluga snimanja. Fer razmjena, on snima, ja analiziram i gradim. Ali poenta priče nije u tome. Poenta je u tom momentu kad je Vladimir shvatio: „Ovo zapravo nije jednostavna aplikacija."

I upravo to je trenutak koji se ponavlja na svakom projektu.

Zašto se ovo uvijek dešava?

Vladimir nije napravio ništa pogrešno. On je stručnjak za svoj posao, snimanje. Ima legitiman problem koji želi riješiti. I u svojoj glavi, rješenje izgleda jednostavno jer on poznaje kontekst.

Ali kontekst koji je u nečijoj glavi i kontekst koji treba pretočiti u softver su dva potpuno različita svijeta.

U Vladimirovoj glavi, „svi hoće drugu smjenu" je jasan problem. Ali softver ne razumije „svi hoće". Softver mora da zna: koliko je „svi"? Šta znači „hoće"? Šta ako hoće ali ne može? Ko odlučuje kad ne može? Po kom kriterijumu? Šta ako se kriterijumi sukobe?

Svako od ovih pitanja je čvor koji treba razmrsiti prije nego što programer sjedne za tastaturu. I ako ih ne razmrsite, programer će ih razmršiti sam, na svoj način, koji vjerovatno neće odgovarati onome što ste zamislili.

Od razgovora do funkcionalnog zahtjeva

Nakon našeg sastanka, pristupio sam izradi prve verzije funkcionalnog zahtjeva. Ali nisam ga odmah finalizovao. Vratio sam se Vladimiru sa novim setom pitanja. Pitanja koja su se pojavila tek kad sam pokušao staviti njegove odgovore u konzistentan dokument.

Jer to je druga stvar koju ljudi ne očekuju: odgovori na prva pitanja rađaju nova pitanja. Vikend logika sa kombinacijama prvog i drugog izbora? To se pojavilo tek u drugoj rundi. Mehanizam istiskivanja, kad skromni radnik automatski izbacuje pohlepnog sa popunjene kvote?

Detalji tog algoritma su se iskristalisali tek kad smo svaki scenario prošli korak po korak.

Na kraju je nastala druga verzija funkcionalnog zahtjeva, dokument od 12 sekcija koji pokriva sve: od prioritetnog algoritma i graničnih slučajeva do dijela konceptualnog rješenja. Ko je zainteresovan, neka mi se javi pa ću rado podijeliti dokument.

Šta je zapravo ispod haube

Da sumiram šta se krije iza „jednostavne aplikacije za raspored smjena":

• Prioritetni algoritam koji razlikuje skromne od pohlepnih zahtjeva, prati koliko dana druge smjene svaki radnik traži u datoj sedmici, i dinamički preraspoređuje mjesta kad neko sa višim prioritetom uđe u igru. Uključujući automatsko istiskivanje pohlepnog radnika sa već popunjene kvote.
• Različita logika za radne dane i vikend. Radni dani imaju tri opcije (prva smjena, druga smjena, slobodan dan), dok vikend ima sistem kombinacija prvog i drugog izbora.
• Vremenski kontrolisan pristup. Unos se otvara samo petkom od 8 do 12h, za narednu sedmicu. Van tog prozora, sistem je zaključan za sve, uključujući administratora.
• Upravljanje kvotama. Striktna ograničenja broja radnika po smjenama, sa mogućnošću da administrator mijenja ove parametre.
• Korisničke uloge sa različitim pravima. Radnik vidi sve ali mijenja samo svoje, admin upravlja radnicima i kvotama ali ne može mijenjati raspored nakon zaključavanja.

Ovo nije „tabela sa imenima". Ovo je mali poslovni sistem sa svojom logikom, pravilima, izuzecima i graničnim slučajevima.

Lekcija za svaki projekat

Ono što sam radio sa Vladimirom ima formalno ime u svijetu razvoja softvera. Zove se requirements elicitation, proces izvlačenja zahtjeva od korisnika. I to nije nešto što se desi samo od sebe.

U Scrum-u, ovu ulogu igra Product Owner, osoba koja stoji između korisnika (Vladimira) i razvojnog tima. Product Owner zna kako da postavi prava pitanja, kako da prepozna šta je bitno za prvu verziju a šta može čekati, i kako da od nečije ideje napravi specifikaciju koju programer može implementirati.

Npr. Vladimir je u jednom momentu pomenuo da postoji „nekoliko kategorija unutar svake smjene". Mogao sam to uključiti u funkcionalni zahtjev i time zakomplikovati prvu verziju. Ali umjesto toga, pitao sam: da li je to kritično za prvu verziju? Nije. Dovoljno je „Prva" i „Druga". Kategorije mogu doći kasnije. Ovo je klasičan primjer postavljanja prioriteta i zaštite prve verzije od nepotrebne kompleksnosti.

Isto tako, mogao sam insistirati na sistemu notifikacija, eksportu u PDF, istoriji rasporeda. Sve to ima smisla. Ali ništa od toga nije neophodno da bi aplikacija riješila Vladimirov osnovni problem, a svaka dodatna funkcionalnost je dodatno vrijeme, novac i kompleksnost.

Ovu vještinu, da znate šta pitati, šta uključiti, a šta odložiti, detaljno sam obradio u svom kursu User Requirements Course. Ako vas zanima kako da od ideje „u glavi" dođete do specifikacije koju razvojni tim može realizovati, bez nepotrebnih iteracija i nesporazuma, tu ćete naći konkretan okvir i primjere iz prakse.

Šta je sljedeći korak?

Trenutno čekam da Vladimir potvrdi da je funkcionalni zahtjev kompletan i tačan. Nakon toga slijedi:

1. Tehnička specifikacija: dokument za programera koji opisuje kako će se funkcionalni zahtjevi realizovati (struktura baze, arhitektura plugina, pseudokod algoritma).
2. Razvoj: programiranje WordPress plugina prema specifikaciji.
3. Testiranje: provjera svakog scenarija, uključujući granične slučajeve.
4. Puštanje u produkciju: instalacija na WordPress sajt i prvi pravi petkov unos rasporeda.

Od „jednostavnog telefonskog poziva" do ovdje, a još nismo napisali ni jednu liniju koda.

Zaključak

Sljedeći put kad neko kaže „treba mi jednostavna aplikacija", sjetite se Vladimira i njegovih snimatelja. Ne zato što je pogriješio. Naprotiv, imao je jasan problem i legitimnu ideju. Već zato što „jednostavno" gotovo nikada ne znači ono što mislimo da znači.

Između ideje i softvera stoji analiza. Pitanja. Dokumentacija. I neko ko zna kako da vas provede kroz taj proces.
To je posao koji se ne vidi, ali bez njega, svaki projekat je kocka.