Sadržaj:
- Duljina prijedloga
- Sažetak
- Predložak
- Naziv projekta
- Sadržaj
- Odobrenja
- Promjene
- Rječnik i kratice
- Opseg
- Vremenska Crta
- Članovi projekta
- Poslovna prilika
- Pregled rješenja
- Značajke i isporuke
- Proračun i povrat ulaganja
- Prednosti
- Ograničenja
Kako napisati uspješan prijedlog za razvoj softvera.
Kevin Languedoc
Svrha prijedloga za razvoj softvera je prenijeti rješenje koje će čitati poslovni ljudi, pa neka bude jednostavno i precizno; klonite se tehničkih uvjeta što je više moguće. Sljedeći se pregled može koristiti kao takav za pripremu uspješnog prijedloga za razvoj softvera. Važno je imati na umu da ljudi kojima ćete predstaviti prijedlog nemaju puno vremena za čitanje podužih dokumenata. Možete mi to uzeti, napisao sam stotine prijedloga tijekom svojih 20 i više godina u informacijskoj tehnologiji: poslovni ljudi žele tek toliko informacija da im omoguće donošenje utemeljene odluke.
Ako odgovarate na zahtjev za prijedlog (RFP) i morate poštivati određeni raspon stranica, jer su stranice unaprijed ispisane ili vas zahtjevi za sadržajem natjeraju na pretjerano dugačak prijedlog, razmislite o upotrebi sažetka. dodao sam odjeljak u kojem je opisano kako pripremiti jedan u nastavku.
Duljina prijedloga
Vidio sam predloške i rasprave koji zagovaraju prijedloge koji traju 50 stranica ili stranica. Vjerujte, izgubit ćete interes poslovnog rukovoditelja nakon pete stranice. Jednom kada se prijedlog prihvati, projektni će dokumenti prirodno biti detaljniji jer će biti namijenjeni projektnom timu i bit će radni nacrti sustava. To će se odnositi na većinu klijenata, ali (da uvijek postoji ali, ali) ako je prijedlog odgovor na zahtjev za prijedlog (RFP), tada se morate pridržavati RFP-a. Također, vlada ili vojna agencija vjerojatno će imati stroge smjernice o tome kako pripremiti prijedlog za razvoj softvera i može sadržavati nekoliko stranica (10, 20, 30, 50 ili više), ovisno o složenosti sustava.Ovo pravilo i dalje vrijedi za velike organizacije koje mogu imati formalni postupak prijedloga, posebno ako su javna korporacija i moraju se pridržavati bilo kojih propisa ili standarda Sarbannes-Oxleyja ili ISO-a.
Sažetak
Ako prijedlog ima više od 20 stranica, možete razmotriti davanje sažetka koji je jedan pager odjeljaka u prijedlogu. Možete dati i sažetak u PowerPoint formatu. Ako planirate koristiti sažetak u prezentaciji prijedloga za razvoj softvera, predstavite ga pomoću sažetka i izvršni direktor može pročitati prijedlog kasnije, na primjer tijekom poslovnog leta.
Predložak
Sljedeći je prikaz zapravo dobar predložak koji možete koristiti za pripremu vlastitog prijedloga za razvoj softvera. Uvijek imam na umu pravilo visine dizala prilikom pripreme prijedloga, a trebali biste i vi. U osnovi Elevator Parce predviđa da vaš prijedlog ne bi trebao biti dulji od vremena potrebno dizalom od prizemlja do gornjeg kata zgrade na putu da predstavite prijedlog.
Naziv projekta
S podnaslovom ili sažetim informacijama o prijedlogu
Prijedlog treba imati naslov i pododjeljak koji sažima kontekst prijedloga softvera. Uključujete i naziv odjeljenja, službe, odjela ili organizacije kojem je projekt namijenjen.
Ako odgovarate na RFP (Zahtjev za prijedlog), tada u RFP uključite sve podatke koji su potrebni ili su navedeni kao obvezni. Također sam vidio RFP-ove koji zahtijevaju da potpise odobrenja dodate pored naslova na prvoj stranici, ali u ovom primjeru potpise stavljam na stranicu s odjeljkom Promjene.
Sadržaj
Na sljedećoj stranici trebali biste uključiti sadržaj koji sadrži glavne odjeljke prijedloga. Po želji možete uključiti brojeve stranica ako prijedlog premašuje pet stranica ili ako to zahtijeva RFP.
Odobrenja
Ovaj je odjeljak presudan za postupak, bez obzira radi li se o odgovoru na RFP ili iz ovog predloška ili iz nekog drugog izvora. Ovaj odjeljak dokumentira potvrde da je projekt u tijeku i pruža obvezujući sporazum između različitih članova projekta. Nikada ne biste trebali započeti projekt dok ne nabavite sve potrebne potpise i ako se zapovjednik projekta i dionici ne obvežu da započnu projekt. U suprotnom, mogli biste se naći u obvezi ako je projekt otkazan ili ako se opseg projekta promijeni ili isporuke.
S postojećim odobrenjima, promjene opsega i isporuka mnogo je teže izvršiti, a ako postoje sporovi, potpisivanjem odobrenja pružit će se jasno (e) razumijevanje dogovorenog. Naravno, uvijek postoji pitanje tumačenja.
Odobrenja trebaju sadržavati ime osobe, njen naslov, nakon čega slijedi njihov potpis i na kraju datum kada je dokument potpisan.
Ime | Naslov / uloga | Potpis | Datum |
---|---|---|---|
Promjene
Odjeljak Promjene sadrži zapisnik o svim promjenama koje su unesene ili će se izvršiti u dokumentu Prijedlog za razvoj softvera. Ne dokumentira nikakve promjene opsega samog projekta ili bilo kojeg drugog aspekta projekta. Odjeljak Promjene trebao bi sadržavati najmanje ime osobe koja vrši promjenu, datum promjene i komentar ili opis promjene.
Autor | Datum promjene | Opis ili komentar |
---|---|---|
Rječnik i kratice
Navedite sve pojmove ili kratice i njihove definicije. Nemojte pretpostavljati da svi znaju značenje izraza ili kratica, pogotovo ako planirate koristiti vanjske savjetnike, a izrazi su unutarnji, ugrađeni u vašu korporativnu kulturu i žargonizam. Svaka organizacija ima svoj jezik i kratice. U redu je koristiti ih u prijedlogu sve dok su pravilno dokumentirani.
Također, ako se koriste bilo koji akronimi specifični za određenu industriju, oni ih također trebaju dokumentirati kako bi svi imali jasno razumijevanje značenja pojmova i akronima i formulirali bolja tumačenja.
Sljedeći su kratice iz trenutnog predloška. Navedeni su kao primjer.
- RFP: Zahtjev za prijedlog
- ROI: Povrat ulaganja
- CAGR: Složena godišnja stopa rasta
- IT: Informacijska tehnologija
- CAPEX: Kapitalni izdaci
- UoM: Mjerna jedinica
Opseg
Opseg prijedloga trebao bi na visokoj razini iznijeti sveukupne detalje projekta, što je uključeno i isključeno. Opseg treba pružiti cjelovit opis, duljinu projekta i glavne ciljeve. Što pokušavate postići ovom investicijom u predloženi projekt razvoja softvera.
Vremenska Crta
Ovaj će odjeljak sadržavati datume početka i završetka (procijenjeni). Obavezno ugradite međuspremnik i planirajte nepredviđene slučajeve. Dobro pravilo je dodati vremenski slijed 75% međuspremnika.
Članovi projekta
Članovi projekta trebaju uključivati prvaka projekta i dionike. Prvak je obično izvršni direktor koji upravlja cjelokupnim projektom i proračunom. Dionik je obično interni promotor ili sponzor. Oni također mogu biti prvak, ovisno o opsegu projekta i / ili vrsti organizacije koja traži prijedlog za razvoj softvera. Preostali popis sadrži tipične uloge koje ljudi obavljaju u projektu.
Sljedeće je navedeno samo kao primjer vrste uloga koje sudionici projekta mogu imati. Neki ljudi mogu imati više uloga. Ovisno o opsegu projekta, popis članova projekta može biti vrlo dugačak ili ista osoba može preuzeti različite uloge.
Popis bi trebao sadržavati sve informacije koje ispravno identificiraju osobu, njezinu ulogu u projektu, kako doći do njih i koje su njihove odgovornosti. Možete uključiti i druge podatke ovisno o RFP-u ili vrsti organizacije s kojom ćete surađivati i njihovim internim pravilima.
Član tima | Uloga | Podaci za kontakt | Odgovornosti |
---|---|---|---|
Prvak |
|||
Sudionik |
|||
Voditelj projekta |
|||
Arhitekt |
|||
Analitičar |
|||
Programer |
Poslovna prilika
Većina dostupnih predložaka definira ovaj odjeljak kao “Poslovni problem” ili “Izjavu problema”, no često sam susretao poslovne lidere koji se vrijeđaju zbog činjenice da imaju problema u svojoj poslovnoj jedinici ili procesu. Sjećam se da me je jedna direktorica doslovno izbacila iz svog ureda jer sam rekao da popravljamo postupak, a ona mi je rekla da to neće biti netko iz IT-a (Informacijska tehnologija) koji će diktirati ako ima problema s njezinim procesima ili ne.
Stoga budite oprezni s formulacijama. Uvijek koristim izraz „poslovna prilika“ jer je na kraju prijedlog odgovor na poslovnu priliku za poboljšanje procesa, potporu procesu ili automatizaciju procesa
Izjava o poslovanju | Kako će sustav zadovoljiti zahtjev |
---|---|
Pogođeni poslovni proces, situacija, problem |
Kako će predloženo rješenje poboljšati ciljno poslovno područje |
Rješava se ono što treba |
Kako će se sadašnji projekt baviti njime |
Pregled rješenja
U odjeljku Pregled rješenja možete pružiti pregled sustava na visokoj razini. Ovaj pregled može sadržavati navigacijsku kartu ako se prijedlog odnosi na web mjesto ili web aplikaciju. Također možete uključiti dijagram toka tijeka procesa. Također, možete uključiti dijagram glavnih komponenata sustava.
Cilj je dati osobi koja donosi odluku dovoljno informacija kako bi razumjela kakav je sustav, kako će raditi i koji su glavni građevni blokovi. Naravno, ovo je samo smjernica jer organizacija može imati formalni format koji definira što ćete sve morati pružiti u prijedlogu, pogotovo ako imate posla s vladinom agencijom ili Ministarstvom obrane.
Značajke i isporuke
Ovaj odjeljak pruža mehanizam za mapiranje značajke predloženog sustava u opipljivi rezultat. Također sam vidio kako ovaj odjeljak sadrži vremensku procjenu za završetak isporuke, ali ne volim je upotrebljavati, jer je previše restriktivna i stvara nejednakost. Tijekom rada na projektu, rezultati se možda neće poravnati točno onako kako je zapisano, pa ako ste se na papiru obvezali završiti isporuku u određeno vrijeme, to uklanja ili smanjuje elastičnost kasnije kada zapravo radite projekt.
Sljedeći je stupac koji se može dodati izdanje kojem pripada Isporuka. To je zgodno ako će se projekt isporučivati kroz dulje vremensko razdoblje i bit će nekoliko izdanja. To se također može odnositi na Agile ili Lean projekt na kojem svaka značajka ili Korisnička priča pripada izdanju.
Koncept je jednostavan; za svaku značajku u sustavu navedite naziv značajke, kratki opis i koja će isporuka zadovoljiti zahtjev značajke.
Značajka | Opis | Isporučivo |
---|---|---|
Proračun i povrat ulaganja
Proračun i povraćaj ulaganja nekim su rukovoditeljima vjerojatno najvažniji dio. Svi oni žele znati koliko će ih sustav koštati ili koliki će utjecaj ovaj projekt imati na njihov proračun odjela. To je osobito istinito ako projekt nije bio uključen u Capex na početku fiskalne godine.
Ponekad, čak i ako je projekt predviđen proračunom, drugi projekt može imati prednost nad trenutnim prijedlogom i sredstva se mogu preusmjeriti iz predviđenog izvora. Često se događaju politička prepucavanja na izvršnoj i upravljačkoj razini kako bi se projekt pokrenuo s terena, a često postoje nepredviđene okolnosti koje mogu imati prednost nad planiranim projektima.
Stoga budite spremni surađivati sa svojim dionicima kako biste pomogli u pregovorima ili budite fleksibilni i proaktivni u pružanju djelotvornog rješenja ako proračunska situacija krene postrani. Bolje je projekt prilagoditi proračunskoj stvarnosti, čak i šireći isporuke sustava kroz dulje vremensko razdoblje ili čak otići od projekta. Mnogo je bolje otići, nego raditi na projektu, ne primati plaću i morati pribjeći parnici.
Sljedeća je tablica samo u svrhu demonstracije kako bi vam dala ideju kako pripremiti proračun. Naravno, morat ćete dodati vlastite stavke retka kako bi odgovarale vašem projektu. Zatim popunite količinu, jediničnu cijenu, mjernu jedinicu i ukupan iznos stavke. Zatim zbrojte ukupne stavke na dnu.
To će pružiti dobru sliku ulaganja potrebnog za izradu softverskog projekta. Većina rukovoditelja s kojima sam surađivao vole znati kolika će biti stopa povrata ili koliko će ovaj projekt s vremenom koštati, tako da također uključujem jednostavnu vrijednost ROI-a i CAGR, bilo koristeći vlastite procjene i pretpostavke (koje moraju biti objašnjeno) u prijedlogu ili koristeći ponuđene procjene i pretpostavke.
Stavka projekta | Iznos | Jedinična cijena | UoM | Ukupno |
---|---|---|---|---|
Licenca za softver |
||||
Strojevi |
||||
Licenca za poslužitelj |
||||
Licenca baze podataka |
||||
Savjetnik za razvoj |
||||
Upravljanje projektima |
||||
Trening (vrijeme + materijali) |
ROI
Izračun ROI-a vrlo je jednostavan. U osnovi je formula dobit - trošak podijeljen s troškom. Formula je navedena u nastavku:
Jedina je mana što se u izračunu ne uzima u obzir vrijeme, tako da je ROI dobar za kratkoročne projekte, ali za dugoročne projekte obično uvrštavam CAGR (složena godišnja stopa rasta). Izračun CAGR-a je stopa povrata iz godine u godinu za određeni trenutak.
CAGR
Formula CAGR je:
Prvi dio je podjela krajnje vrijednosti s početnom vrijednošću. Rezultat se podiže na snagu 1 tijekom broja uloženih godina. Dobivena vrijednost oduzima se 1.
Prednosti
U ovom odjeljku navodite poslovne prednosti koje će pružiti softverski projekt. Oni se mogu navesti u nabrajanju dok su povezani s ukupnim ciljevima. Trebali bi pokazati kako će softver ili sustav povećati poslovnu vrijednost.
Ukratko, kako će predloženo rješenje pomoći poduzeću da bude uspješnije i postigne ciljeve izjave? Koristite pozitivne riječi i rečenice.
Ograničenja
Odjeljak ograničenja treba navesti sva materijalna i nematerijalna ograničenja koja možete predvidjeti. To se može odnositi na opremu, neki sezonski faktor kao što je zatvaranje proizvodnog pogona, što većina postrojenja radi kao primjer.
Pokušajte umanjiti ograničenja ili ih obojiti kao minimalna. Nemojte navoditi negativne aspekte softvera ili sustava, a ako morate, pružite rješenja za zaobilaženje.
© 2012 Kevin Languedoc