Blog

(Lean) upravljanje opsegom projekta

Nije slučajno da su tri glavna uzročnika neuspjelih projekata izravno povezana s definicijom opsega projekta. Što se tu da napraviti?
Objavljeno 17.10.2014.

Poznato je da je ključ uspjeha projekta u kontroliranju opsega. Steve McConnell u svojoj knjizi Rapid Development: Taming Wild Software Schedules odlično opisuje arsenal koji nam je na raspolaganju u obrani opsega projekta. Zanimljivo je ove ideje sagledati i iz lean perspektive, tj. kako spasiti projekt (ali i produkt) od nekontroliranog bubrenja.

Čuveni Standish Group Chaos Report kaže da su tri glavna uzročnika neuspjelih projekata redom:

  1. Nedostatak informacija od naručitelja
  2. Nepotpuni zahtjevi i specifikacije
  3. Promjene u zahtjevima i specifikacijama

Nije slučajno da su tri glavna uzročnika neuspjelih projekata izravno povezana s definicijom opsega projekta. Što se tu da napraviti?

Tri su načina upravljanja opsegom:

  1. Rano u projektu tijekom definiranja opsega kako bi bio u skladu sa zadanim vremenskim rokom i budžetom
  2. Tijekom projekta kontroliranjem scope creepa.
  3. Na kraju projekta rezanjem korisničkih zahtjeva kako bi se dostigao rok i budžet

 

Rano u projektu – reduciranje korisničkih zahtjeva

Kontroliranje opsega rano u projektu podrazumijeva eliminiranje nepotrebnih zahtjeva. Tri su načina kako ovo napraviti:

1. Minimalna specifikacija

Polazimo od ideje da tradicionalna (detaljna) specifikacija ima nedostataka: troši vrijeme i novac na specificiranje potencijalno nebitnih stvari, a ne jamči konačni uspjeh projekta, brzo zastarijeva, previše detalja ograničava konkretnu implementaciju.

Rješenje je u kreiranju minimalne specifikacije, tj. minimalne količine informacija dovoljne za razumno specificiranje produkta. Forma takve specifikacije može biti u nekom od sljedećih oblika:

  1. kratki opis u tekstualnom dokumentu
  2. point-of-departure specifikacija – jednokratna aproksimativna specifikacija namijenjena usklađivanju očekivanja projektnog tima i korisnika. Nakon što postigne svoj cilj, specifikacija se više ne ažurira
  3. korisničke upute kao specifikacija
  4. korisničko sučelje kao specifikacija
  5. korisnička iskustva na papirima
  6. vizija koja opisuje što je dio produkta , ali i što nije dio produkta
  7. tema produkta – npr. tema kod izrade Excela 3.0 je bila da produkt mora biti „seksi“

U kojem će obliku uistinu biti specifikacija – nije bitno. Specifikacija je sredstvo, a ne cilj, dakle što god vašem timu više paše.

Benefiti minimalne specifikacije su:

  1. veća motivacija projektnog tima jer im minimalna specifikacija ostavlja slobodu u implementaciji
  2. povećana efikasnost jer implementacija nije strogo ograničena
  3. manje truda potrošenog uludo kod specificiranja beskorisnih stvari
  4. kraća faza definiranja zahtjeva

2. Eliminiranje zahtjeva

Odnosi se na eliminiranje kompletnih zahtjeva. Što prije se eliminiranje dogodi, to bolje. Ne želimo da se vrijeme troši na analizu ovih zahtjeva. Kako se provodi eliminiranje? Tako da se nakon definiranja zahtjeva još jednom s korisnikom prođe kroz sve zahtjeve s ciljem da se:

  • eliminiraju oni koji nisu apsolutno nužni
  • pojednostave oni koji su kompliciraniji nego što je potrebno
  • odabere jeftinija verzija implementacije tamo gdje postoji više verzija

3. Verzioniranje produkta

Odnosi se na raspoređivanje funkcionalnosti po verzijama produkta. Što nije apsolutno bitno ide u sljedeću verziju.

Tijekom projekta – kontroliranje scope creepa

Scope creep dolazi sa svih strana: korisnik hoće nove funkcionalnosti, razvijači žele refaktorirati implementaciju iz prethodne verzije i sl. Tipične su sljedeće situacije:

  1. Killer-app sindrom – radimo savršenu aplikaciju, konkurencija izbaci novu aplikaciju, a mi odgodimo produkciju da bi dodali još tih par konkurentskih featurea.
  2. Nejasno definirani projektni ciljevi – svjesni da nemaju nikakve šanse ostvariti ciljeve koji su nejasni, razvijači će se okrenuti ostvarenju svojih ciljeva (maksimalna fleksibilnost i konfigurabilnost aplikacije, cutting-edge GUI, savršene performanse i sl.)
  3. Korisnik koji lopata nove zahtjeve

Idealno bi bilo da nema nikakvih promjena u zahtjevima. Međutim, život nije film i u pravilu to nije slučaj. Ponašajući se u takvoj situaciji da će zahtjevi biti zamrznuti je siguran put prema gubitku kontrole nad procesom upravljanja promjenama. Najpragmatičnije bi bilo isprintati zahtjeve i njima prijetiti korisnicima, ali obzirom da više cijenimo suradnju s korisnicima nego pregovaranje oko ugovora, preziremo takav stav, naročito u sljedećim situacijama:

  • Kad korisnik zapravo ne zna što hoće – dio razvoja softvera je i pomaganje korisnicima da shvate što hoće, a korisnici u pravilu ne znaju što hoće dok ne dobiju radeći softver u ruke. Ovdje jako pomažu agilne metodologije koje promoviraju iterativni i inkrementalni pristup razvoju.
  • Kad hoćemo biti agilni u implementiranju zahtjeva i pružiti korisniku sigurnost da ga aplikativno možemo poduprijeti u svim poslovnim inovacijama
  • Kad se tržište brzo mijenja
  • Kad koristimo minimalnu specifikaciju i namjerno prepuštamo razvijačima odluke oko implementacije manje bitnih funkcionalnosti

Kako se boriti protiv scope creepa?

Charlton Heston bi rekao puškom! 🙂 Izvrstan način kako kazati NE nekoj funkcionalnosti je kazati DA, ALI u nekoj sljedećoj verziji. Ponekad se korisnici bore protiv takvog odgovora jer predosjećaju da nakon verzije 1.0 neće biti verzije 2.0. Protiv ovoga se opet efikasno borimo iterativnim i inkrementalnim razvojem kojim korisnika navikavamo da nema samo jedna verzija nego da nove verzije stalno dolaze.

Drugi način je Change Control Board koji će odlučiti prihvaća li se nova funkcionalnost i kako to utječe na prioretizaciju backloga.

Na kraju projekta rezanjem zahtjeva

Ako unatoč svemu projekt upadne u problem s rokovima, moguća opcija je rezanje funkcionalnosti. I to najprije onih niskog prioriteta. Što možemo jednostavno napraviti jer nam je product backlog prioretiziran. Dobro je što rezanjem funkcionalnosti posao postaje jednostavniji jer se eliminiraju sve aktivnosti vezane uz njezin razvoj: analiza, dizajn, implementacija, testiranje, dokumentiranje i sl. Loše je što smo možda već potrošili vrijeme na nešto od ovih aktivnosti prije nego li smo funkcionalnost eliminirali. Zato je efikasnije pametno rezati funkcionalnosti niskog prioriteta već na početku projekta.

Na ranije navedene metode velikog utjecaja ima popularni Lean Startup model koji je snažno protiv izgradnje glomaznog produkta temeljenog na opširnim specifikacijama definiranima prije početka projekta. Lean Startup model zagovara brzu izradu minimalnog radećeg produkta (Minimum Viable Product) te njegovu daljnju evoluciju kroz niz brzih ciklusa tijekom kojih učimo o poslovnoj vrijednosti i eksperimentiramo s novim inkrementima produkta. Ovakvim pristupom empirijski zaokružujemo opseg projekta na način da isporučeni produkt u konačnici donosi maksimalnu poslovnu vrijednost.

Promatramo li dodatno ove metode upravljanja opsegom kroz prizmu preferiranja suradnje s korisnikom u odnosu na pregovaranje oko ugovora, jasno je da je zapravo najbolji pristup agilno ugovaranje koje, za razliku od klasičnih fixed-scope i T&M ugovora, niti jednog dionika u startu ne postavlja u povlašteni položaj. Agilni ugovori u pravilu definiraju troškove i vremenski rok dok je opseg projekta definiran grubo i podložan je promjenama, naravno u granicama ranije definiranog troška. Na taj se način prihvaća činjenica da je praktički nemoguće na početku projekta precizno opisati cjelokupni opseg već se on detaljno razvija tijekom projekta, u suradnji s naručiteljem. Zbog toga su i procjene razvojnog tima preciznije i praktički bez ugrađenog rizika. Projekt postaje puno transparentniji i pošteniji. Klasični win-win za sve dionike.

Tagovi:
Povratak