Cum se scrie o propunere de dezvoltare software

Cum se scrie o propunere de dezvoltare software de succes.

Kevin Languedoc

Scopul unei propuneri de dezvoltare software este de a transmite o soluție care va fi citită de oamenii de afaceri, deci păstrați-o simplă și la obiect; stai cât mai mult posibil de termenii tehnici. Următorul schiță poate fi folosit ca atare pentru a pregăti o propunere de succes de dezvoltare software. Este important să rețineți că persoanele pe care urmează să le prezentați nu au prea mult timp pentru a citi un document lung. Puteți să-l luați de la mine, am scris sute de propuneri de peste 20 de ani în tehnologia informației: oamenii de afaceri doresc doar suficiente informații pentru a le permite să ia o decizie în cunoștință de cauză.

Dacă răspundeți la o cerere de propunere (RFP) și trebuie să respectați un anumit interval de pagini, deoarece paginile sunt pre-tipărite sau cerințele de conținut vă obligă să aveți o propunere excesiv de lungă, atunci luați în considerare utilizarea unui rezumat executiv. Am adăugat o secțiune care descrie cum să o pregătiți mai jos.

Lungimea propunerii

Am văzut șabloane și discuții care susțin propuneri care rulează pe 50 sau pagini. Credeți-mă, veți pierde interesul executivului de afaceri după pagina a cincea. Odată ce propunerea este acceptată, documentele de proiectare vor fi în mod firesc mai detaliate, deoarece vor fi destinate echipei de proiect și vor fi planurile de lucru ale sistemului. Acest lucru se va aplica majorității clienților, dar (da, există întotdeauna un dar) dacă propunerea răspunde la o cerere de propunere (RFP), atunci trebuie să respectați RFP. De asemenea, un guvern sau o agenție militară va avea probabil îndrumări stricte cu privire la modul de pregătire a unei propuneri de dezvoltare software și poate include mai multe pagini (10, 20, 30, 50 sau mai multe) în funcție de complexitatea sistemului.Această regulă este valabilă în continuare pentru organizațiile mari care pot avea un proces formal de propunere, mai ales dacă sunt o corporație publică și trebuie să adere la orice reglementări sau standarde Sarbannes-Oxley sau ISO.

Rezumat

Dacă propunerea are peste 20 de pagini, atunci vă recomandăm să furnizați un rezumat executiv care să fie un singur pager al secțiunilor din propunere. Puteți furniza chiar și un rezumat executiv într-un format PowerPoint. Dacă intenționați să utilizați un rezumat executiv în prezentarea propunerii de dezvoltare software, prezentați propunerea utilizând rezumatul executiv, iar executivul poate citi propunerea într-un moment ulterior, ca în timpul unui zbor de afaceri.

Șablonul

Următorul schiță este de fapt un șablon bun pe care îl puteți utiliza pentru a vă pregăti propria propunere de dezvoltare software. Întotdeauna țin cont de regula Elevator Pitch atunci când pregătesc o propunere și ar trebui să o faci și tu. Practic, Elevator Pitch stipulează că propunerea dvs. nu ar trebui să fie mult mai lungă decât timpul necesar pentru a lua un lift de la parter până la ultimul etaj al unei clădiri pe drumul dvs. de a prezenta o propunere.

Titlul proiectului

Cu un subtitlu sau informații rezumate despre propunere

Propunerea ar trebui să aibă un titlu și o subsecțiune care să rezume contextul propunerii de software. De asemenea, includeți numele diviziei, serviciului, departamentului sau organizației pentru care este destinat proiectul.

Dacă răspundeți la o cerere de ofertă (Cerere de propunere), atunci includeți toate informațiile necesare sau listate ca obligatorii în cererea de ofertă. Am văzut și RFP-uri care vă solicită să puneți semnăturile de aprobare pe lângă titlul de pe prima pagină, dar în acest exemplu, am pus semnăturile pe pagina cu secțiunea Modificări.

Cuprins

În pagina următoare, ar trebui să includeți un cuprins care să listeze principalele secțiuni ale propunerii. Opțional, puteți include numerele de pagină dacă propunerea depășește cinci pagini sau dacă este solicitată de cererea de ofertă.

Aprobări

Această secțiune este crucială pentru proces, fie că este un răspuns la o cerere de oferte sau de la acest șablon sau de la o altă sursă. Această secțiune documentează confirmările conform cărora proiectul este un demers și oferă un acord obligatoriu între diferiții membri ai proiectului. Nu ar trebui să începeți niciodată un proiect până nu ați obținut toate semnăturile necesare și nu veți avea un angajament din partea campionului proiectului și a părților interesate de a începe proiectul. În caz contrar, s-ar putea să vă găsiți într-o legătură dacă proiectul este anulat sau dacă domeniul de aplicare al proiectului se modifică sau livrabilele.

Având în vedere aprobările, modificările domeniului de aplicare și ale rezultatelor sunt mult mai greu de realizat și, dacă există litigii, aprobarea semnată va oferi o înțelegere clară a ceea ce sa convenit. Desigur, există întotdeauna o chestiune de interpretare.

Aprobările trebuie să includă numele persoanei, titlul acestora, urmat de semnătura acestora și, în cele din urmă, data la care a fost semnat documentul.



Nume	Rolul titlului	Semnătură	Data

Schimbări

Secțiunea Modificări oferă un jurnal al tuturor modificărilor care au fost făcute sau vor fi aduse documentului Propunerea de dezvoltare software. Nu documentează nicio modificare a sferei proiectului în sine sau a oricărui alt aspect al proiectului. Secțiunea Modificări ar trebui să includă cel puțin numele persoanei care efectuează modificarea, data modificării și un comentariu sau descriere a modificării.



Autor	Data schimbării	Descriere sau comentariu

Glosar și acronime

Enumerați orice termeni sau acronime și definițiile acestora. Nu presupuneți că toată lumea știe semnificația termenilor sau acronimelor, mai ales dacă intenționați să utilizați consultanți externi și dacă termenii sunt interni, încorporați în cultura corporativă și lingo. Fiecare organizație are propriile limbaje și acronime. Este ok să le folosiți în propunere, atâta timp cât sunt documentate corespunzător.

De asemenea, dacă se utilizează acronime specifice industriei, acestea trebuie documentate și pentru ca toată lumea să înțeleagă clar semnificația termenilor și acronimelor și să formuleze interpretări mai bune.

Următoarele acronime sunt din șablonul curent. Acestea sunt oferite ca exemplu.

RFP: Cerere de propunere
ROI: rentabilitatea investiției
CAGR: Rată de creștere anuală compusă
IT: Tehnologia informației
CAPEX: Cheltuieli de capital
UoM: Unitate de măsură

Domeniul de aplicare

Domeniul de aplicare al propunerii ar trebui să prezinte la un nivel înalt detaliile generale ale proiectului, ceea ce este inclus și exclus. Domeniul de aplicare ar trebui să furnizeze o descriere generală, durata proiectului, obiectivele majore. Ce încercați să realizați cu această investiție în proiectul de dezvoltare software propus.

Cronologie

Această secțiune va include datele de începere și de încheiere (estimate). Asigurați-vă că construiți un buffer și planificați situații neprevăzute. O regulă bună este să adăugați un buffer de 75% la cronologia dvs.

Membrii proiectului

Membrii proiectului ar trebui să includă campionul proiectului și părțile interesate. Campionul este de obicei un executiv care conduce proiectul și bugetul general. Părțile interesate sunt de obicei un promotor sau un sponsor intern. De asemenea, pot fi campioni în funcție de sfera proiectului și de tipul de organizație care solicită propunerea de dezvoltare software. Lista rămasă conține roluri tipice pe care oamenii le îndeplinesc într-un proiect.

Următorul este furnizat doar ca exemplu al tipului de roluri pe care le pot avea participanții la proiect. Unele persoane pot avea mai mult de un rol. În funcție de domeniul de aplicare al proiectului, lista membrilor proiectului poate fi foarte lungă sau aceeași persoană își poate asuma roluri diferite.

Lista ar trebui să conțină orice informații care identifică în mod corespunzător persoana, rolul acesteia în cadrul proiectului, modul de a ajunge la aceasta și care sunt responsabilitățile sale. Puteți include alte informații în funcție de cererea de ofertă sau de tipul de organizație cu care veți lucra și politicile lor interne.



Membru al echipei	Rol	Informații de contact	Responsabilități
	Campion
	Părțile interesate
	Manager de proiect
	Arhitect
	Analist
	Dezvoltator

Oportunitate de afaceri

Majoritatea șabloanelor disponibile definesc această secțiune ca „Problemă de afaceri” sau „Declarație de problemă”, totuși am întâlnit deseori lideri de afaceri care se ofensează că au o problemă în unitatea sau procesul de afaceri. Îmi amintesc că un regizor m-a aruncat literalmente din biroul ei pentru că declarasem că reparăm un proces și mi-a spus că nu va fi cineva din IT (Tehnologia informației) care va dicta dacă are o problemă cu procesele ei sau nu.

Deci, aveți grijă cu formularea. Folosesc întotdeauna termenul „Oportunitate de afaceri”, deoarece în final, propunerea răspunde unei oportunități de afaceri de a îmbunătăți un proces, de a sprijini un proces sau de a automatiza un proces



Declarația de afaceri	Modul în care sistemul va satisface cerința
Procesul de afaceri afectat, situația, problema	Cum va îmbunătăți soluția propusă zona de afaceri țintă
Ce nevoie este abordată	Cum va aborda proiectul actual?

Prezentare generală a soluției

În secțiunea Prezentare generală a soluției, puteți oferi o imagine de ansamblu la nivel înalt a sistemului. Această prezentare generală poate include o hartă de navigare dacă propunerea este pentru un site web sau o aplicație web. De asemenea, puteți include o diagramă a fluxului procesului. De asemenea, puteți include o diagramă a componentelor majore ale sistemului.

Obiectivul aici este de a oferi persoanei care ia decizia suficiente informații, astfel încât să înțeleagă ce este sistemul, cum va funcționa și care sunt elementele principale. Desigur, acesta este doar un ghid, întrucât o organizație poate avea un format formal care definește ceea ce va trebui să furnizați în propunere, mai ales dacă aveți de-a face cu o agenție guvernamentală sau cu departamentul de apărare.

Caracteristici și elemente livrabile

Această secțiune oferă un mecanism pentru maparea unei caracteristici a sistemului propus la un produs tangibil. Am văzut, de asemenea, această secțiune care conține o estimare de timp pentru a finaliza livrabilul, dar nu-mi place să folosesc acest lucru, deoarece este prea restrictiv și creează o legătură. Când lucrați la proiect, livrabilele s-ar putea să nu se alinieze exact așa cum sunt scrise, deci, dacă v-ați angajat pe hârtie să finalizați un livrabil până la un anumit timp, acesta va elimina sau reduce orice elasticitate mai târziu atunci când efectuați efectiv proiectul.

O altă coloană care poate fi adăugată este versiunea de care aparține livrabilul. Acest lucru este la îndemână dacă proiectul va fi livrat pe o perioadă mai lungă de timp și vor exista mai multe versiuni. Acest lucru se poate aplica și unui proiect bazat pe Agile sau Lean în care fiecare caracteristică sau User Story aparține unei versiuni.

Conceptul este simplu; pentru fiecare caracteristică din sistem, furnizați numele caracteristicii, o scurtă descriere și care livrare va satisface cerința caracteristicii.



Caracteristică	Descriere	Livrabil

Buget și ROI

Bugetul și rentabilitatea investiției este probabil cea mai importantă parte pentru unii directori. Toți sunt nerăbdători să știe cât le va costa sistemul sau cât de mult impact va avea acest proiect asupra bugetului departamentului lor. Acest lucru este valabil mai ales dacă proiectul nu a fost inclus în Capex la începutul anului fiscal.

Uneori, chiar dacă proiectul a fost bugetat, un alt proiect poate avea prioritate față de propunerea actuală, iar fondurile pot fi deviate de la sursa dorită. De multe ori se întâmplă un pic de luptă politică la nivel executiv și de conducere pentru a pune în practică un proiect și există adesea circumstanțe neprevăzute care pot avea prioritate față de proiectele planificate.

Așadar, fiți pregătiți să colaborați cu părțile interesate pentru a ajuta la negocieri sau fiți flexibili și proactivi pentru a oferi o soluție de lucru în cazul în care o situație bugetară se deplasează lateral. Este mai bine să adaptați proiectul la realitatea bugetară, răspândind chiar livrabilele sistemului pe o perioadă mai lungă de timp sau chiar să vă îndepărtați de proiect. Este mult mai bine să te îndepărtezi decât să lucrezi la un proiect și să nu fii plătit și să apelezi la litigii pe drum.

Tabelul următor are doar scop demonstrativ pentru a vă oferi o idee despre cum să pregătiți un buget. Bineînțeles, va trebui să adăugați propriile elemente rând pentru a se potrivi proiectului dvs. Apoi completați cantitatea, prețul unitar, unitatea de măsură și totalul elementului rând. Apoi, calculați totalul elementelor rând în partea de jos.

Aceasta va oferi o imagine bună a investiției necesare pentru realizarea proiectului software. Cei mai mulți directori cu care am lucrat le place să știe care va fi rata de rentabilitate sau cât va costa acest proiect în timp, așa că includ și o valoare ROI simplă și un CAGR, fie folosind propriile estimări și ipoteze (care trebuie să fie explicat) în propunere sau folosind estimările și ipotezele furnizate.



Elementul proiectului	Cantitate	Preț unitar	UoM	Total
Licență software
Mașini
Licență de server
Licență de bază de date
Consultant în dezvoltare
Management de proiect
Instruire (Timp + Materiale)

ROI

Calculul rentabilității investiției este foarte ușor. Practic formula este câștigurile - costul împărțit la cost. Formula este furnizată mai jos:

Singurul dezavantaj este că calculul nu ia în considerare timpul, deci rentabilitatea investiției este bună pentru proiectele pe termen scurt, dar pentru proiectele pe termen lung includ, în general, un CAGR (Compound Annual Growth Rate). Calculul CAGR este o rată de rentabilitate de la un an la altul pentru un anumit moment.

CAGR

Formula CAGR este:

Prima parte este împărțirea valorii finale la valoarea inițială. Rezultatul este ridicat la puterea de 1 pe parcursul numărului de ani investiți. Valoarea rezultată este scăzută cu 1.

Beneficii

În această secțiune, enumerați avantajele de afaceri pe care le va oferi proiectul software. Ele pot fi listate în format glonț, atâta timp cât sunt corelate cu obiectivele generale. Ar trebui să demonstreze modul în care software-ul sau sistemul vor spori valoarea afacerii.

Pe scurt, cum soluția propusă va ajuta afacerea să aibă mai mult succes și să-și atingă obiectivele declarației? Folosiți cuvinte și propoziții pozitive.

Constrângeri

Secțiunea de constrângeri ar trebui să enumere orice constrângeri tangibile și intangibile pe care le puteți prevedea. Acest lucru se poate referi la echipamente, un anumit factor de sezonalitate, cum ar fi închiderea unei fabrici de producție, pe care majoritatea instalațiilor o fac cel puțin o dată pe an, ca exemplu.

Încercați să minimizați constrângerile sau să le pictați ca fiind minime. Nu enumerați aspecte negative ale software-ului sau sistemului sau, dacă este cazul, furnizați soluții de soluție.