Come scrivere una proposta di sviluppo software

Come scrivere una proposta di sviluppo software di successo.

Kevin Languedoc

Lo scopo di una proposta di sviluppo software è trasmettere una soluzione che verrà letta dagli uomini d'affari, quindi mantienila semplice e al punto; stare lontano dai termini tecnici il più possibile. Il seguente schema può essere utilizzato così com'è per preparare una proposta di sviluppo software di successo. È importante tenere presente che le persone a cui presenterai la proposta non hanno molto tempo per leggere un documento lungo. Puoi prenderlo da me, ho scritto centinaia di proposte nel corso dei miei oltre 20 anni nella tecnologia dell'informazione: gli uomini d'affari vogliono informazioni sufficienti per consentire loro di prendere una decisione informata.

Se stai rispondendo a una richiesta di proposta (RFP) e devi rispettare un determinato intervallo di pagine, perché le pagine sono prestampate oi requisiti del contenuto ti costringono ad avere una proposta eccessivamente lunga, considera l'utilizzo di un riepilogo esecutivo. ho aggiunto una sezione che descrive come prepararne uno di seguito.

Lunghezza proposta

Ho visto modelli e discussioni che sostengono proposte che vanno avanti per 50 o pagine. Credimi, perderai l'interesse del dirigente dopo la quinta pagina. Una volta accettata la proposta, i documenti di progetto saranno naturalmente più dettagliati in quanto saranno destinati al team di progetto e saranno i modelli di lavoro per il sistema. Ciò si applicherà alla maggior parte dei clienti ma (sì, c'è sempre un ma) se la proposta è in risposta a una richiesta di proposta (RFP), è necessario aderire alla RFP. Inoltre, un governo o un'agenzia militare avrà probabilmente linee guida rigorose su come preparare una proposta di sviluppo software e potrebbe includere diverse pagine (10, 20, 30, 50 o più) a seconda della complessità del sistema.Questa regola è ancora valida per le grandi organizzazioni che possono avere un processo di proposta formale, specialmente se sono una società pubblica e devono aderire a qualsiasi normativa o standard Sarbannes-Oxley o ISO.

Sintesi

Se la proposta è più di 20 pagine, puoi considerare di fornire un riepilogo esecutivo che è una pagina delle sezioni della proposta. Puoi persino fornire un riepilogo esecutivo in formato PowerPoint. Se si prevede di utilizzare un riepilogo esecutivo nella presentazione della proposta di sviluppo software, presentare la proposta utilizzando il riepilogo esecutivo e il dirigente può leggere la proposta in un secondo momento, come durante un volo d'affari.

Il template

Lo schema seguente è in realtà un buon modello che puoi utilizzare per preparare la tua proposta di sviluppo software. Quando preparo una proposta, tengo sempre a mente la regola della presentazione, e dovresti farlo anche tu. Fondamentalmente il passo dell'ascensore stabilisce che la tua proposta non dovrebbe essere molto più lunga del tempo necessario per prendere un ascensore dal piano terra all'ultimo piano di un edificio sulla strada per presentare una proposta.

titolo del progetto

Con un sottotitolo o informazioni di riepilogo sulla proposta

La proposta dovrebbe avere un titolo e una sottosezione che riassumano il contesto della proposta di software. Includete anche il nome della divisione, del servizio, del dipartimento o dell'organizzazione a cui è destinato il progetto.

Se stai rispondendo a una RFP (Request For Proposal), includi tutte le informazioni richieste o elencate come obbligatorie nella RFP. Ho anche visto RFP che richiedono di inserire le firme di approvazione oltre al titolo nella prima pagina, ma in questo esempio, ho messo le firme nella pagina con la sezione Modifiche.

Sommario

Nella pagina successiva, dovresti includere un sommario che elenca le sezioni principali della proposta. Facoltativamente, puoi includere i numeri di pagina se la proposta supera le cinque pagine o se è richiesto dalla RFP.

Approvazioni

Questa sezione è cruciale per il processo, sia che si tratti di una risposta a una RFP, di questo modello o di un'altra fonte. Questa sezione documenta le conferme che il progetto è un go e fornisce un accordo vincolante tra i vari membri del progetto. Non dovresti mai avviare un progetto finché non hai ottenuto tutte le firme necessarie e hai un impegno da parte del sostenitore del progetto e delle parti interessate a iniziare il progetto. In caso contrario, potresti trovarti in difficoltà se il progetto viene annullato o se l'ambito del progetto cambia o i risultati finali.

Con le approvazioni in atto, le modifiche all'ambito e ai risultati finali sono molto più difficili da apportare e in caso di controversie, aver firmato le approvazioni fornirà una chiara (er) comprensione di ciò che è stato concordato. Ovviamente c'è sempre una questione di interpretazione.

Le approvazioni devono includere il nome della persona, il titolo, seguito dalla firma e infine la data in cui il documento è stato firmato.



Nome	Ruolo principale	Firma	Data

I cambiamenti

La sezione Modifiche fornisce un registro di tutte le modifiche che sono state apportate o che verranno apportate al documento Proposta di sviluppo software. Non documenta alcuna modifica all'ambito del progetto stesso o qualsiasi altro aspetto del progetto. La sezione Modifiche dovrebbe includere almeno il nome della persona che effettua la modifica, la data della modifica e un commento o una descrizione della modifica.



Autore	Data di modifica	Descrizione o commento

Glossario e acronimi

Elenca eventuali termini o acronimi e le relative definizioni. Non dare per scontato che tutti conoscano il significato dei termini o degli acronimi, soprattutto se hai intenzione di utilizzare consulenti esterni e i termini sono interni, incorporati nella cultura e nel gergo aziendale. Ogni organizzazione ha il proprio gergo e acronimi. È consentito utilizzarli nella proposta purché siano adeguatamente documentati.

Inoltre, se vengono utilizzati acronimi specifici del settore, anche questi devono essere documentati in modo che tutti abbiano una chiara comprensione del significato dei termini e degli acronimi e formulino interpretazioni migliori.

I seguenti acronimi provengono dal modello corrente. Vengono forniti come esempio.

RFP: richiesta di proposta
ROI: ritorno sull'investimento
CAGR: tasso di crescita annuale composto
IT: tecnologia dell'informazione
CAPEX: Spese in conto capitale
UM: unità di misura

Scopo

L'ambito della proposta dovrebbe delineare ad alto livello i dettagli generali del progetto, cosa è incluso ed escluso. Lo scopo dovrebbe fornire una descrizione generale, la durata del progetto, i principali obiettivi. Cosa stai cercando di ottenere con questo investimento nel progetto di sviluppo software proposto.

Sequenza temporale

Questa sezione includerà le date di inizio e di fine (stimate). Assicurati di creare un buffer e pianificare gli imprevisti. Una buona regola pratica è aggiungere un buffer del 75% alla timeline.

Membri del progetto

I membri del progetto dovrebbero includere il sostenitore del progetto e le parti interessate. Il campione è solitamente un dirigente che guida il progetto e il budget complessivi. Lo stakeholder è solitamente un promotore o sponsor interno. Possono anche essere i campioni a seconda dell'ambito del progetto e / o del tipo di organizzazione che richiede la proposta di sviluppo software. L'elenco rimanente contiene i ruoli tipici che le persone svolgono in un progetto.

Quanto segue è fornito solo come esempio del tipo di ruoli che i partecipanti al progetto possono avere. Alcune persone possono avere più di un ruolo. A seconda dell'ambito del progetto, l'elenco dei membri del progetto può essere molto lungo o la stessa persona può assumere ruoli diversi.

L'elenco dovrebbe contenere tutte le informazioni che identificano correttamente la persona, il suo ruolo all'interno del progetto, come raggiungerla e quali sono le sue responsabilità. Puoi includere altre informazioni a seconda della RFP o del tipo di organizzazione con cui lavorerai e delle loro politiche interne.



Membro della squadra	Ruolo	Informazioni sui contatti	Responsabilità
	Campione
	Stakeholder
	Responsabile del progetto
	Architetto
	Analista
	Sviluppatore

Opportunità di business

La maggior parte dei modelli disponibili definisce questa sezione come "Problema aziendale" o "Dichiarazione del problema", tuttavia ho spesso incontrato leader aziendali che si offendono per il fatto di avere un problema nella loro unità o processo aziendale. Ricordo un direttore che mi ha letteralmente buttato fuori dal suo ufficio perché avevo affermato che stavamo fissando un processo e lei mi ha detto che non sarebbe stato qualcuno dell'IT (Information Technology) a dettare se avesse un problema con i suoi processi o no.

Quindi fai attenzione alla formulazione. Uso sempre il termine "opportunità di business" perché alla fine la proposta è in risposta a un'opportunità di business per migliorare un processo, supportare un processo o automatizzare un processo



Dichiarazione aziendale	Come il sistema soddisferà il requisito
Processo aziendale interessato, situazione, problema	In che modo la soluzione proposta migliorerà l'area di business target
Quale esigenza viene affrontata	Come lo affronterà il progetto attuale

Panoramica della soluzione

Nella sezione Panoramica della soluzione è possibile fornire una panoramica di alto livello del sistema. Questa panoramica può includere una mappa di navigazione se la proposta è per un sito web o un'app web. È inoltre possibile includere un diagramma di flusso del flusso del processo. Inoltre, è possibile includere un diagramma dei principali componenti del sistema.

L'obiettivo qui è fornire alla persona che prende la decisione informazioni sufficienti in modo che comprenda cos'è il sistema, come funzionerà e quali sono i principali elementi costitutivi. Naturalmente, questa è solo una linea guida in quanto un'organizzazione può avere un formato formale che definisce ciò che sarà necessario fornire nella proposta, soprattutto se si tratta di un'agenzia governativa o del dipartimento della difesa.

Caratteristiche e risultati finali

Questa sezione fornisce un meccanismo per mappare una caratteristica del sistema proposto in un risultato tangibile. Ho anche visto questa sezione contenente una stima del tempo per completare il deliverable, ma non mi piace usarla perché è troppo restrittiva e crea un legame. Quando si lavora al progetto, i deliverable potrebbero non essere allineati esattamente come scritti, quindi se ti sei impegnato sulla carta a terminare un deliverable entro un certo tempo, rimuove o riduce l'eventuale elasticità in seguito quando stai effettivamente facendo il progetto.

Un'altra colonna che può essere aggiunta è la Release a cui appartiene il Deliverable. Questo è utile se il progetto verrà consegnato per un periodo di tempo più lungo e ci saranno diverse versioni. Ciò può essere applicato anche a un progetto basato su Agile o Lean in cui ogni funzionalità o User Story appartiene a una versione.

Il concetto è semplice; per ogni caratteristica nel sistema, fornire il nome della caratteristica, una breve descrizione e quale deliverable soddisferà i requisiti della caratteristica.



Caratteristica	Descrizione	consegnabile

Budget e ROI

Il budget e il ROI sono probabilmente la parte più importante per alcuni dirigenti. Sono tutti ansiosi di sapere quanto gli costerà il sistema o quale impatto avrà questo progetto sul budget del loro dipartimento. Ciò è particolarmente vero se il progetto non è stato incluso nel Capex all'inizio dell'anno fiscale.

A volte, anche se il progetto è stato preventivato, un altro progetto può avere la precedenza sulla proposta attuale ei fondi possono essere dirottati dalla fonte prevista. Spesso sono in corso un po 'di dispute politiche a livello esecutivo e dirigenziale per far decollare un progetto e spesso ci sono circostanze impreviste che possono avere la precedenza sui progetti pianificati.

Quindi sii pronto a lavorare con i tuoi stakeholder per aiutare nelle negoziazioni o sii flessibile e proattivo per fornire una soluzione di lavoro se una situazione di budget va di lato. È meglio adattare il progetto alla realtà di bilancio, anche diffondendo i risultati del sistema su un periodo di tempo più lungo o addirittura allontanandosi dal progetto. È molto meglio andarsene che aver lavorato a un progetto e non essere pagati e dover ricorrere a contenziosi lungo la strada.

La tabella seguente è solo a scopo dimostrativo per darti un'idea di come preparare un budget. Naturalmente, dovrai aggiungere i tuoi elementi pubblicitari per adattarli al tuo progetto. Quindi inserisci la quantità, il prezzo unitario, l'unità di misura e il totale della voce. Quindi calcola i totali degli elementi pubblicitari in basso.

Ciò fornirà una buona immagine dell'investimento richiesto per realizzare il progetto software. La maggior parte dei dirigenti con cui ho lavorato desidera sapere quale sarà il tasso di rendimento o quanto costerà questo progetto nel tempo, quindi includo anche un semplice valore ROI e un CAGR, utilizzando le mie stime e ipotesi (che devono essere spiegato) nella proposta o utilizzando le stime e le ipotesi fornite.



Elemento del progetto	Quantità	Prezzo unitario	UM	Totale
Licenza software
Macchina (e)
Licenza server
Licenza database
Consulente per lo sviluppo
Gestione di progetto
Formazione (tempo + materiali)

ROI

Il calcolo del ROI è molto semplice. Fondamentalmente la formula è guadagni: il costo diviso il costo. La formula è fornita di seguito:

L'unico svantaggio è che il calcolo non tiene conto del tempo, quindi il ROI è buono per i progetti a breve termine, ma per i progetti a lungo termine generalmente includo un CAGR (Compound Annual Growth Rate). Il calcolo del CAGR è un tasso di rendimento anno su anno per un certo momento nel tempo.

CAGR

La formula CAGR è:

La prima parte è la divisione del valore finale per il valore iniziale. Il risultato viene elevato alla potenza di 1 per il numero di anni investiti. Il valore risultante viene sottratto per 1.

Benefici

In questa sezione vengono elencati i vantaggi aziendali forniti dal progetto software. Possono essere elencati in formato puntato purché siano collegati agli obiettivi generali. Dovrebbero dimostrare come il software o il sistema aumenterà il valore aziendale.

In poche parole, in che modo la soluzione proposta aiuterà l'azienda ad avere più successo e a raggiungere i suoi obiettivi dichiarati? Usa parole e frasi positive.

Vincoli

La sezione dei vincoli dovrebbe elencare tutti i vincoli tangibili e intangibili che puoi prevedere. Questo può riguardare le attrezzature, un fattore di stagionalità come la chiusura di un impianto di produzione, che la maggior parte degli impianti fa almeno una volta all'anno, ad esempio.

Prova a minimizzare i vincoli o dipingerli come minimi. Non elencare alcun aspetto negativo del software o del sistema o, se necessario, fornire soluzioni alternative.