Kako napisati specifikaciju softvera da ponude budu usporedive

Istu ideju pošaljete trojici dobavljača u mailu od dva odlomka. Dobijete natrag 25.000 €, 70.000 € i 140.000 €. Nitko nije pogriješio. Svaki je procijenio drugi sustav: onaj koji je zamislio čitajući vaš mail.

Specifikacija to rješava. Nije birokracija. Najjeftiniji je način da svi daju ponudu za istu stvar i da dobijete sustav kakav ste zamislili.

Brojke to potvrđuju. Prema istraživanju Project Management Institutea, kad projekti nisu ostvarili ciljeve, glavni uzrok u gotovo polovici slučajeva (47 %) bilo je loše upravljanje zahtjevima, a 5,1 % svakog dolara uloženog u projekte propalo je upravo zbog toga.

Što je specifikacija, a što nije

Opisuje što sustav mora raditi i zašto. Ne kako. Kako je posao dobavljača, a prostor da predloži rješenje jedna je od stvari za koje ga plaćate.

U zemljama njemačkog govornog područja ta razlika ima i imena: naručitelj piše Lastenheft (što i zašto), a dobavljač odgovara Pflichtenheftom (kako i čime), prema normi DIN 69901-5. Na međunarodnoj razini inženjerstvo zahtjeva detaljno opisuje norma ISO/IEC/IEEE 29148.

Za srednju firmu ne treba vam sto stranica. Dovoljno je pet do petnaest stranica koje odgovaraju na prava pitanja.

Što ide u specifikaciju

Dio	Na što odgovara	Primjer
Cilj	Zašto sustav i kako ćete mjeriti uspjeh	“Troje ljudi dva sata dnevno prepisuje narudžbe iz maila. Cilj: manje od 30 minuta.”
Postojeće stanje	Kako radi danas i s kojim alatima	“Narudžbe stižu mailom i u Excelu i ručno se upisuju u ERP.”
Korisnici i uloge	Tko ga koristi i što smije	“Prodaja kreira narudžbe, skladište ih potvrđuje, administratori vide sve.”
Procesi	Glavni tokovi, korak po korak	“Stigne narudžba, provjeri se zaliha, narudžba se potvrdi, šalje se račun.”
Podaci	Koji podaci, odakle i koliko	“Oko 300 narudžbi dnevno i 5.000 kupaca, uvezeno iz ERP-a.”
Integracije	S kojim sustavima mora razgovarati	“ERP preko REST API-ja, mail, računovodstvo.”
Nefunkcionalni zahtjevi	Brzina, sigurnost, dostupnost, zaštita podataka, uređaji	“Prijava preko Microsoft 365, podaci u EU, radi na tabletu u skladištu.”
Kriteriji prihvaćanja	Kako ćete provjeriti da je gotovo	“Narudžba iz maila stigne u ERP unutar pet minuta bez ručnog upisa.”
Opseg isporuke	Što je uključeno osim koda	“Edukacija, dokumentacija, primopredaja, prva tri mjeseca podrške.”
Prioriteti	Što mora biti u prvoj verziji	Mora, trebalo bi, moglo bi

Napišite zahtjeve koji se mogu provjeriti

Najčešća slabost je zahtjev koji nitko ne može provjeriti. “Brzo” znači jedno vama, drugo dobavljaču, a treće korisniku na sporoj vezi. Svaki zahtjev treba biti nešto što možete testirati na primopredaji:

Nejasno	Provjerljivo
Sustav mora biti brz	Popis narudžbi učita se za manje od dvije sekunde uz 10.000 narudžbi
Jednostavan za korištenje	Novi skladištar potvrdi narudžbu bez edukacije, za manje od minute
Siguran	Prijava preko Microsoft 365 s dvofaktorskom autentifikacijom; svaka izmjena narudžbe bilježi se s korisnikom i vremenom
Integracija s ERP-om	Nove narudžbe stignu u ERP unutar pet minuta; ako ERP ne radi, slanje se ponavlja i administrator dobiva obavijest

Što ne pisati

• Dizajn ekrana do piksela, osim ako je stvarno važan. Opišite što korisnik treba napraviti, a ne gdje stoji gumb.
• Izbor tehnologije bez razloga. Ako razlog postoji, napišite ga: “mora raditi na našem SQL Serveru”, “naš tim održava .NET”. Inače neka dobavljači predlože.
• Svaku iznimku u prvoj verziji. Umjesto toga označite otvorena pitanja. Dobar dobavljač će pitati, a odgovori će dokument učiniti boljim.

Mora, trebalo bi, moglo bi

Svakom zahtjevu dodajte prioritet. Mora: bez toga sustav je beskoristan. Trebalo bi: važno, ali postoji zaobilazno rješenje. Moglo bi: lijepo je imati.

To čini dvije stvari. Ponude postaju usporedive, jer svi procjenjuju istu prvu verziju. I dobivate prirodno prvo izdanje: samo ono što mora, brzo u produkciji, a ostatak nakon što ga korisnici vide.

Koliko detaljan dokument treba biti ovisi i o ugovoru. Uz fiksnu cijenu postaje dio ugovora i traži puno više detalja. Više o tome u članku fiksna cijena ili naplata po satu.

Neka AI napiše prvu verziju

Pisanje dokumenta često je ono što projekt zakoči na mjesece. AI to znatno skraćuje. Snimite razgovor s ljudima koji posao danas rade ili svojim riječima zapišite proces, pa ga dajte AI asistentu zajedno s tablicom iznad. Tražite nacrt i popis otvorenih pitanja.

I dalje čitate i ispravljate svaki redak, jer samo vi znate posao. Ali ispravljanje nacrta traje sate, a pisanje od nule tjednima. Jedno pravilo: povjerljive podatke ne lijepite u javni chat alat. Koristite verziju koju je vaša firma odobrila, s vašim postavkama zaštite podataka.

Što dalje

Isti dokument pošaljite trojici dobavljača i tražite da svaki odgovori zahtjev po zahtjev: kako bi ga riješio, koliko košta i što je nejasno. U zemljama njemačkog govornog područja taj odgovor je Pflichtenheft.

Zatim usporedite odgovore, a ne samo ukupne iznose. Dobavljač koji postavlja dobra pitanja pročitao je dokument. Onaj koji ne pita ništa procijenio je nagađanje. Realne raspone cijena pronaći ćete u članku koliko košta izrada poslovne aplikacije.

Kako mi radimo

Upravo ovdje često počinjemo. ProCoding je .NET studio iz Splita: gradimo poslovne aplikacije u .NET-u i Blazoru i uvodimo AI u poslovne procese. U kratkoj analizi prođemo vaše procese s ljudima koji ih poznaju, s vama napišemo specifikaciju i damo procjenu u rasponima. Dokument je vaš i možete ga poslati i drugim dobavljačima. Prvi korak je besplatan razgovor od 30 minuta.

Izvori

• Requirements Management: A Core Competency for Project and Program Success, PMI’s Pulse of the Profession, Project Management Institute, kolovoz 2014.
• Lastenheft, Wikipedia (definicije prema DIN 69901-5)
• ISO/IEC/IEEE 29148:2018, Requirements engineering, ISO