Đavo se krije u detaljima!

Da li vam je poznata ova fraza?

U svetu tradicionalnog razvoja proizvoda, ona ne može biti tačnija. Jedna od glavnih prepreka za kompanije, posebno one ukorenjene u tradicionalnim metodama, jeste način upravljanja zahtevima.

U tradicionalnom razvoju proizvoda, zahtevi se često posmatraju kao nepromenljive, detaljne specifikacije uklesane u kamen. Ovakav rigidan pristup, iako na prvi pogled logičan, donosi brojne izazove. Projektni menadžment pažljivo kreira planove zasnovane na tim zahtevima, ostavljajući razvojne timove pred zahtevnim zadatkom da isporuče unutar tih krutih okvira. Problem? Ovi planovi se često formiraju uz samo površno razumevanje proizvoda – recept za katastrofu.

Šta se dešava kada se dogodi neizbežno i kada se usred projekta zatraže izmene ovih „svetih“ zahteva?

Uključite dramatičnu muziku, jer, prijatelju, ulazimo u zonu ozloglašene procedure kontrole promena. Ovaj birokratski lavirint pun administrativnih prepreka često ostavlja razvojne timove više frustriranim nego ispunjenim, što je u oštroj suprotnosti sa mantri kompanije „Oduševiti kupca“.

Postoje dve strane

Kada smo već kod kupaca, oni se obično uključuju u proces u dve ključne tačke: na samom početku projekta i u napetoj završnici, poznatoj kao korisničko prihvatno testiranje (UAT). Nažalost, upravo u ovoj završnoj fazi dolazi do suočavanja sa realnošću. Kupci se često nađu pred proizvodom koji ne ispunjava njihova očekivanja, bez dovoljno vremena ili budžeta da se situacija popravi. Tada počinje igra prebacivanja krivice, gde kupci upiru prstom u developere uz reči: „Da ste bolje razumeli moje zahteve, ne bismo bili u ovom problemu.“ Ali budimo iskreni – većina kupaca zapravo ne zna šta želi dok to ne vidi u praksi. A evo i jedne zanimljive činjenice: istraživanja pokazuju da čak 65% funkcionalnosti proizvoda korisnici nikada ne koriste.

S druge strane, ni developeri nisu bez zamerki. Njihova mantra? „Zahtevi su pokretna meta, napisani kao hijeroglifi, što dovodi do stalnih nesporazuma.“ To je zamršena mreža loše komunikacije, dodatno otežana stalnim promenama u razvoju softvera.

Kuda dalje?

Kako onda da „ukrotimo“ ove zahtevne zahteve?

Sve počinje kreiranjem product backlog-a – sveobuhvatne liste svega što je potrebno za razvoj proizvoda. Tu spadaju funkcionalni zahtevi, nefunkcionalni zahtevi, unapređenja… Ali evo ključne stvari: nema potrebe da se odmah ulazi u najsitnije detalje. Umesto toga, prioriteti se postavljaju beskompromisno – zahtevi visokog prioriteta dobijaju detaljno razrađene User Stories, dok oni nižeg prioriteta ostaju u formi Epic-a.

Kako razvoj napreduje, User Stories evoluiraju, dobijajući na jasnoći i detaljima kroz kontinuirane razgovore između Product Ownera i razvojnog tima. Svaka priča mora imati svrhu – mora donositi konkretnu poslovnu vrednost, u suprotnom, zašto uopšte postoji?

Tu dolazi Scrum okvir, koji product backlog posmatra kao strateški alat, tampon zonu ili čak simbol slobode. On omogućava fleksibilnost u suočavanju sa izazovima i daje nam mogućnost da promenimo pravac kada je potrebno. Kasnimo? Nema problema – možemo smanjiti obim uklanjanjem manje važnih User Stories. S druge strane, ako se pojavi vredan novi zahtev usred procesa, lako ga možemo ubaciti u backlog i uskladiti sa poslovnim prioritetima.

U suštini, Agilni zahtevi i User Stories predstavljaju spas u nejasnim vodama razvoja proizvoda. Ako vam ovo ima smisla i vidite potencijal da unapredite svoje poslovno okruženje, razmislite o tome da se dodatno edukujete kroz trening Agilni Zahtevi i User Stories.