Predložak za prikupljanje zahtjeva: 7 trikova koje koristim na projektima

Predložak za prikupljanje zahtjeva zaslužuje svoje mjesto samo ako rano nameće teške razgovore: tko potpisuje, tko može blokirati, kako izgleda uspjeh i koliko brz sustav mora biti. Ovaj je vodič za voditelje projekata, poslovne analitičare i SAP voditelje kojima treba predložak koji izdrži i nakon prvog upravljačkog odbora. U nastavku je cjelovit nacrt koji koristim, s vlasnikom za svaki odjeljak, pet odjeljaka koje nikad ne preskačem i sedam trikova za intervjue, određivanje prioriteta i promjene. Prekopirajte nacrt u vlastiti dokument i popunite ga prije nego što počne oblikovanje.

Jednom sam gledao kako se projekt vrijedan šesteroznamenkastog iznosa urušava jer nitko nije napravio zahtjeve kako treba. Klijent je očekivao jedno. Razvojni tim izgradio je drugo. Svi su bili žrtvovani, i tada su mene pozvali.

Taj obrazac nije neobičan. PMI-jevo izvješće Pulse of the Profession iz 2014. o upravljanju zahtjevima utvrdilo je da 47 % neuspješnih projekata nije ostvarilo ciljeve zbog lošeg upravljanja zahtjevima. Vidio sam to desetke puta.

I sam sam zamalo upao u istu situaciju na velikom uvođenju sustava. Dionici su govorili svatko svoje. Programeri su pogađali. Zaustavili smo se, sastavili pristojan predložak zahtjeva i isporučili ono što je poslovanju trebalo, na vrijeme i u okviru proračuna.

Tvrtka jednog mog prijatelja potrošila je 350 tisuća USD na prilagođeni CRM koji nitko ne koristi. Prodaji je trebalo jedno, marketing je želio drugo, a programeri su izgradili ono što su mislili da svi žele.

Jedan moj klijent iz zdravstva potrošio je 18 mjeseci na implementaciju EMR sustava koju liječnici nisu htjeli koristiti. Nitko ih nije pitao što im treba u svakodnevnom radu. Projekt je odbačen i pokrenut ispočetka.

Kasno otkrivanje je skupo. NASA-ina studija o rastu troška pogrešaka utvrdila je da pogreška u zahtjevima uhvaćena u integraciji i testiranju košta 21 do 78 puta više za popravak nego ona uhvaćena tijekom zahtjeva. Uhvaćena u radu, množitelj se kretao od 29 do više od 1.500. U programu velikog poduzeća to je razlika između radionice i zahtjeva za promjenom vrijednog stotine tisuća.

1. ZahtjeviOsnovni trošak popravkaUhvaćena dok se zahtjevi još pišu
2. Integracija i testiranje21 do 78 puta veći trošakUhvaćena kad je sustav izgrađen i u testiranju
3. Rad29 do više od 1.500 puta veći trošakUhvaćena nakon što je sustav u produkciji

Izvor: NASA-ina studija o rastu troška pogrešaka

Nakon što sam to naučio na teži način, ovo je pet odjeljaka koje nijedan predložak zahtjeva ne bi smio preskočiti.

1. Izvršni sažetak s potpisnim blokom

Zauzeti rukovoditelji neće čitati dokument zahtjeva od 30 stranica. Jednom sam imao sponzora koji je odobrio projekt ne razumijevajući što potpisuje, a zatim se razbjesnio kad je vidio rezultat. Ograničite ga na jednu stranicu: poslovni učinak, rokovi, resursi, očekivana korist i potpisni blok na istoj stranici, kako odobravatelji ne bi mogli tvrditi da su propustili ključne pojedinosti.

2. Mapiranje uloga i utjecaja

Popis imena nije dovoljan. Treba Vam karta moći: tko može potopiti projekt, s kim se treba savjetovati, a kome su dovoljne samo obavijesti. Na jednom ranijem poslu bili smo šest mjeseci u razvoju kad je pravni odjel stigao sa zahtjevima koji su nas natjerali na redizajn. Nitko nije pomislio da ih uključi. Mapirajte svaki zahvaćeni odjel, njegova predstavnika i njegov utjecaj.

3. Poslovni ciljevi, a ne tehnički zahtjevi

Koji problem rješavamo i kako ćemo mjeriti uspjeh? Jedan proizvodni klijent implementirao je softver za zalihe točno prema specifikaciji, a on je usporio rad skladišta za 20 %. Predložak treba natjerati dionike da poslovni uspjeh definiraju uz postojeću osnovnu vrijednost, a ne popisom značajki.

4. Funkcionalni zahtjevi koje programeri mogu iskoristiti

Odbacite žargon. Svaki zahtjev neka bude konkretan i provjerljiv. „Sustav treba poboljšati korisničko iskustvo" ne vrijedi ništa. „Korisnici moraju moći obraditi povrat robe i izdati povrat novca za manje od 3 minute" jest zahtjev. Ako ne možete provjeriti je li ispunjen, prepišite ga.

5. Nefunkcionalni zahtjevi

Performanse, sigurnost, usklađenost, dostupnost, skalabilnost. To je odjeljak koji gotovo svi preskaču, a onda sustav pada pod opterećenjem ili ne prolazi sigurnosnu reviziju. Čuo sam za jedan maloprodajni projekt u kojem je sustav savršeno radio do Crnog petka, kada se urušio pod opterećenjem jer nitko nije odredio zahtjeve za performanse. Vremena odziva, dostupnost, vršna opterećenja korisnika i obveze usklađenosti zapišite kao brojke.

Evo cjelovitog nacrta. Pet gornjih odjeljaka nalazi se u njemu, uz evidencije koje ga drže živim nakon potpisivanja.

Odjeljak	Što ulazi u njega	Vlasnik	Potpisuje
1. Izvršni sažetak	Problem, poslovni učinak, rokovi, resursi, očekivana korist. Jedna stranica s potpisnim blokom	Sponzor, nacrt izrađuje voditelj poslovne analize	Sponzor i financije
2. Opseg i osnovica isporuke	Što je unutar opsega i izvan njega, ograničenja. Za SAP: javno izdanje, privatno izdanje ili on-premise	Direktor programa	Upravljački odbor
3. Karta uloga i utjecaja	Odjeli, predstavnici, razina utjecaja, savjetovati ili obavijestiti	Voditelj poslovne analize	Sponzor
4. Poslovni ciljevi	Svaki cilj s KPI-jem, njegovom postojećom osnovnom vrijednošću i ciljnom vrijednošću	Vlasnici procesa	Sponzor
5. Funkcionalni zahtjevi	ID (npr. REQ-FUN-023), opis, podrijetlo, prioritet, kriteriji prihvaćanja, odluka Fit-to-Standard	Funkcionalni voditelji	Vlasnici procesa
6. Nefunkcionalni zahtjevi	Performanse, sigurnost, usklađenost, dostupnost; za SAP, pristup proširenju za svako odstupanje	Arhitekt rješenja	IT, sigurnost i usklađenost
7. Parkiralište	Odgođeni zahtjevi, tko ih je tražio, datum sljedećeg pregleda	Voditelj poslovne analize	Nitko dok se ne unaprijedi
8. Evidencija odbijenog	Što je odbijeno, zašto, kada i tko je odbio	Voditelj poslovne analize	Sponzor
9. Evidencija promjena	Svaka promjena nakon potpisivanja s učinkom na vrijeme i trošak	PMO	Odbor za promjene

1. Koristite Pet zašto u intervjuima s dionicima

Pitajte „što Vam treba?" i dobit ćete popis želja. Umjesto toga pitajte o boli: „Što Vas tjera da poželite baciti računalo kroz prozor?" Zatim pitajte zašto, i opet zašto, pet puta. Pravi je zahtjev obično drukčiji od prvog zahtjeva.

Imao sam dionika koji je inzistirao na složenim mogućnostima izvještavanja. Nakon što smo prošli njegove stvarne slučajeve upotrebe, trebala su mu tri jednostavna dashboarda.

2. Napravite parkiralište zahtjeva

Priličan dio onoga što dionici traže nikad se neće upotrebljavati. Kad netko inzistira na nečemu spornom, ne raspravljam. Stavim to na parkiralište i svaki mjesec pošaljem podsjetnik pitajući treba li to prijeći u aktivne zahtjeve. Većina ostane parkirana zauvijek.

3. Primijenite pravilo trojke na dionike koji stalno mijenjaju mišljenje

Dvaput smiju promijeniti smjer bez posljedica. Pri trećoj promjeni šalju e-poruku svom šefu u kojoj objašnjavaju promjenu i njezin učinak. Nitko ne želi poslati tu poruku. Promjene prestaju.

4. Primijenite tehniku raspodjele sredstava kako biste prisilili na određivanje prioriteta

Svakom dioniku dajte 100 virtualnih dolara za raspodjelu na sve zahtjeve. Ne mogu imati sve, pa novac stavljaju ondje gdje je važno. Napravio sam to s klijentom iz financijskih usluga koji je imao više od 200 „kritičnih" zahtjeva. Unutar sat vremena imali smo pravih 20 najvažnijih.

5. Numerirajte svaki zahtjev

Koristite dosljedan format poput REQ-FUN-023. Time završava zbrka „o kojem zahtjevu govorimo?" koja troši vrijeme na sastancima. Zabilježite podrijetlo, tko je tražio i zašto, kako biste znali koga nazvati kad stavke treba izrezati.

6. Vratite zahtjeve dioniku njegovim jezikom

Nakon dokumentiranja pročitajte zahtjeve dionicima njihovim vlastitim riječima. Za sve složeno prije početka razvoja napravite brzi prototip ili wireframe. Nesporazumi izlaze na vidjelo dok su još jeftini.

7. Dokumentirajte što je odbijeno

Netko će u petom mjesecu vratiti odbijeni zahtjev. „O tome smo razgovarali u travnju i evo zašto smo odlučili protiv" brzo završava taj razgovor. Bez evidencije imate istu raspravu ponovno.

Sedam trikova radi na svakom projektu. SAP programima u predlošku trebaju tri dodatne stvari.

Model isporuke ide u osnovicu

Zabilježite model isporuke prije prikupljanja funkcionalnih zahtjeva: S/4HANA Cloud Public Edition (putem GROW with SAP ili RISE-a), Private Edition (obično putem RISE-a) ili on-premise. On određuje što je moguće. Public Edition ne dopušta izmjenu jezgre, pa se zahtjevi koji ovise o nestandardnim procesima moraju preoblikovati ili odbiti. Private Edition i on-premise dopuštaju više, uz cijenu napora pri nadogradnji.

Ako zahtjeve prikupljate prije te odluke, mnoge ćete prepisivati kad ona stigne.

Odluka o proširenju za svako odstupanje

SAP-ov pristup Clean Core znači da svako odstupanje treba zabilježenu odluku: konfigurirati ga, proširiti ga pomoću objavljenih API-ja (on-stack s ABAP Cloud ili side-by-side na SAP BTP-u) ili ga odbiti. U javnom izdanju to nameće sam proizvod. U privatnom izdanju i on-premise to je SAP-ova snažna smjernica, a svaka izmjena koju dopustite kasnije postaje posao oko nadogradnje. Odluku upišite u odjeljak 6 predloška, uz performanse i sigurnost, i jednom arhitektu dajte ovlast da je odobri. Moj vodič kroz Clean Core objašnjava razine.

AI izrađuje nacrte, ljudi odlučuju

AI sada pomaže oko papirologije. SAP Cloud ALM nudi značajku generiranja zahtjeva koja iz transkripata radionica Fit-to-Standard izrađuje nacrte zahtjeva u predlošku, a plaća se putem AI jedinica. Opći asistenti, kao što je Microsoft Copilot, izrađuju sažetke i zapisnike iz bilješki sa sastanaka.

Alati za AI nacrte štede stvarno vrijeme na papirologiji kad je izvorni materijal čist. Ne mijenjaju intervju. Čovjek i dalje postavlja Pet zašto. I nijedan alat neće natjerati voditelja odjela da potpiše izvršni sažetak. Validacija, određivanje prioriteta i potpisivanje ostaju ljudski posao.

Razvoj softvera. Dodajte tehnička ograničenja, točke integracije, korisničke tokove (stvarne korake koje korisnici poduzimaju, a ne samo značajke) i kriterije prihvaćanja prolazi/ne prolazi. To smo propustili na projektu korisničkog portala i tri smo mjeseca raspravljali rade li značajke „kako treba".

Poboljšanje procesa. Mapirajte trenutno stanje sa svim neurednim zaobilaznim rješenjima koja ljudi ne spominju na sastancima, procijenite učinak po ulozi i zabilježite čvrste osnovne vrijednosti performansi. Jedan proizvodni klijent temeljito je preuredio proces skladišta bez osnovnih vrijednosti. Šest mjeseci kasnije nije mogao dokazati poboljšanje ni opravdati potrošeno.

Odabir isporučitelja. Odvojite obavezno od poželjnog, ponderirajte kriterije bodovanja i bolno detaljno opišite očekivanja za podršku i implementaciju. Gledao sam kako je jedna tvrtka isporučitelja odabrala gotovo isključivo prema značajkama i dojmovima s demonstracije. Zanemarila je zahtjeve za podršku i završila sa sustavom koji nije mogla implementirati bez velikih dodatnih troškova savjetovanja.

Za manje projekte: Trello za provođenje zahtjeva kroz faze odobravanja, Google Docs s komentarima za pregled i Miro za mapiranje procesa na radionicama.

Za programe velikih poduzeća: Jira s dodatkom za upravljanje zahtjevima, Confluence za žive dokumente (njegove AI značajke sada se nalaze pod Atlassianovom markom Rovo) i Modern Requirements ako koristite Azure DevOps. Na SAP programima SAP Cloud ALM drži zahtjeve, korisničke priče i testne slučajeve na jednom mjestu, povezane s planom SAP Activate.

Alat je manje važan od povezanosti. Povežite zahtjeve s projektnim planom i testnim slučajevima te šaljite automatske obavijesti kad se zahtjev promijeni. „Nisam znao da se to promijenilo" ubija više projekata nego loši alati. Kad su zahtjevi potpisani, moj vodič o izbjegavanju širenja opsega u SAP implementacijama opisuje kako ih takvima zadržati, a SAP kontrolne točke kvalitete pokazuju gdje se potpisivanje zahtjeva uklapa u ciklus upravljanja.

Predložak koji nitko ne otvara nakon potpisivanja predstava je. Oni koji rade kratki su, imaju vlasnika za svaki odjeljak i ažuriraju se svaki put kad netko promijeni mišljenje, što je na svakom programu vrijednom vođenja svaki tjedan.

Koje su 5 faza prikupljanja zahtjeva?

1. Elicitacija: prikupljanje informacija kroz intervjue, radionice i promatranje
2. Analiza: organiziranje, određivanje prioriteta i rješavanje sukoba među zahtjevima
3. Dokumentiranje: pisanje specifikacije (BRD, FRD ili korisničke priče, ovisno o metodi)
4. Validacija: potvrda da zahtjevi odražavaju stvarne potrebe i da se mogu testirati
5. Upravljanje: praćenje promjena do kraja projekta

Svaka faza nadovezuje se na prethodnu. Žurba u elicitaciji, što većina timova radi, stvara probleme u svakoj sljedećoj fazi.

Koja je razlika između BRD-a i FRD-a?

Dokument poslovnih zahtjeva (BRD) obuhvaća poslovne potrebe: pozadinu, ciljeve, dionike, ograničenja i zahtjeve na visokoj razini. Odgovara na pitanje „što poslovanje treba?"

Dokument funkcionalnih zahtjeva (FRD) obuhvaća kako će se sustav ponašati: korisničke priče, ponašanje sustava, sučelja i kriterije prihvaćanja. Odgovara na pitanje „što sustav mora raditi?"

Uvijek počinjem s BRD-om kako bih postigao poslovno usklađivanje prije FRD-a. Timovi koji odmah skoče na FRD često izgrade tehnički ispravan sustav koji rješava pogrešan problem.

Koje su 3 vrste zahtjeva?

1. Poslovni zahtjevi: zašto projekt postoji, njegovi ciljevi i mjere uspjeha
2. Funkcionalni zahtjevi: što sustav mora raditi
3. Nefunkcionalni zahtjevi: koliko dobro to mora raditi (performanse, sigurnost, skalabilnost, usklađenost)

Većina neuspjeha projekata koje sam vidio vuče korijen iz nedostajućih nefunkcionalnih zahtjeva. Sustav radi ono što je traženo, a zatim pada pod stvarnim opterećenjem ili ne prolazi reviziju usklađenosti.

Kako SAP model isporuke mijenja prikupljanje zahtjeva?

Zabilježite ga prvo. S/4HANA Cloud Public Edition ne dopušta izmjenu jezgre, pa se zahtjevi izgrađeni na nestandardnim procesima moraju preoblikovati ili odbiti. Private Edition i on-premise dopuštaju veću fleksibilnost, ali svaka izmjena dodaje napor pri nadogradnji.

Ako funkcionalne zahtjeve prikupljate prije te odluke, mnoge ćete prerađivati. Za svako odstupanje dodajte zabilježenu odluku o proširenju (konfigurirati, proširiti putem objavljenih API-ja ili odbiti).

Što zahtjev čini provjerljivim?

Jasan, mjerljiv uvjet prolazi/ne prolazi. „Sustav treba biti brz" nije provjerljivo. „Rezultati pretraživanja moraju se vratiti za manje od 2 sekunde za 95 % upita pri standardnom opterećenju" jest.

Moj test: možete li odmah napisati testni slučaj s jasnim kriterijima prolazi/ne prolazi? Ako ne, prepišite zahtjev. Neprovjerljivi zahtjevi uzrokuju više sporova pri puštanju u rad nego bilo što drugo što vidim.

Kako spriječiti da se zahtjevi stalno mijenjaju?

1. Kontrola promjena: svaka promjena nakon potpisivanja dokumentira učinak na vrijeme, proračun i resurse prije nego što je itko odobri. Učinite trošak promjene vidljivim.
2. Parkiralište: novi zahtjevi idu na parkiralište, a ne izravno u opseg. Pregledavajte mjesečno. Većina zahtjeva koji se čine hitnima ne preživi čekanje.
3. Kontrolne točke kvalitete: definirajte što znači „zahtjevi dovršeni" i ne počinjite oblikovanje dok to nije ispunjeno.

Na SAP programima odluka o proširenju dodaje tehničku provjeru povrh toga: zahtjev koji traži izmjenu jezgre mora proći arhitekta prije nego što se može odobriti.