Com escriure una proposta de desenvolupament de programari

Com escriure una proposta de desenvolupament de programari reeixida.

Kevin Llenguadoc

L’objectiu d’una proposta de desenvolupament de programari és transmetre una solució que la gent de negocis llegirà, de manera que sigui senzilla i precisa; Mantingueu-vos allunyats dels termes tècnics tant com sigui possible. El següent esquema es pot utilitzar tal qual per preparar una proposta de desenvolupament de programari reeixida. És important tenir en compte que les persones que presentareu la proposta no tenen molt de temps per llegir un document llarg. Me la podeu treure, he escrit centenars de propostes al llarg dels meus vint-i-més anys en tecnologia de la informació: els empresaris volen informació suficient per permetre'ls prendre una decisió informada.

Si responeu a una sol·licitud de proposta (RFP) i heu de respectar un determinat interval de pàgines, perquè les pàgines estan preimpreses o els requisits de contingut obliguen a tenir una proposta excessivament llarga, considereu utilitzar un resum executiu. He afegit una secció que descriu com preparar-ne una a continuació.

Durada de la proposta

He vist plantilles i debats que defensen propostes que tenen una durada de 50 o pàgines. Creieu-me, perdrà l'interès de l'executiu després de la cinquena pàgina. Un cop acceptada la proposta, els documents de disseny seran naturalment més detallats, ja que es destinaran a l'equip del projecte i seran els plànols de treball del sistema. Això s’aplicarà a la majoria de clients, però (sí, sempre hi ha un però) si la proposta respon a una sol·licitud de proposta (RFP), heu d’adherir-vos a la RFP. A més, un govern o una agència militar probablement tindrà directrius estrictes sobre com preparar una proposta de desenvolupament de programari i pot incloure diverses pàgines (10, 20, 30, 50 o més) en funció de la complexitat del sistema.Aquesta regla encara és vàlida per a les grans organitzacions que poden tenir un procés de proposta formal, especialment si són una corporació pública i han de complir qualsevol norma o norma Sarbannes-Oxley o ISO.

Resum executiu

Si la proposta té més de 20 pàgines, podeu considerar proporcionar un resum executiu que sigui una pàgina única de les seccions de la proposta. Fins i tot podeu proporcionar un resum executiu en format PowerPoint. Si teniu previst fer servir un resum executiu a la presentació de la proposta de desenvolupament de programari, presenteu-lo mitjançant el resum executiu i l’executiu podrà llegir la proposta en un moment posterior, com durant un vol empresarial.

La plantilla

El següent esquema és en realitat una bona plantilla que podeu utilitzar per preparar la vostra pròpia proposta de desenvolupament de programari. Sempre tinc present la regla Elevator Pitch a l’hora de preparar una proposta, i tu també ho hauries de fer. Bàsicament, Elevator Pitch estableix que la vostra proposta no hauria de ser molt més llarga que el temps que necessiteu per agafar un ascensor des de la planta baixa fins a la planta superior d’un edifici en el vostre camí per presentar una proposta.

Títol del Projecte

Amb un subtítol o informació resumida sobre la proposta

La proposta ha de tenir un títol i una subapartat que resumeixi el context de la proposta de programari. També incloeu el nom de la divisió, servei, departament o organització a què va destinat el projecte.

Si responeu a una sol·licitud de proposta (RFP), incloeu qualsevol informació que sigui necessària o que aparegui obligatòria a la sol·licitud de proposta. També he vist RFP que us demanaven que poseu les signatures d’aprovació a més del títol a la primera pàgina, però en aquest exemple he posat les signatures a la pàgina amb la secció Canvis.

Taula de continguts

A la pàgina següent, haureu d'incloure una taula de continguts que inclogui les seccions principals de la proposta. Opcionalment, podeu incloure els números de pàgina si la proposta supera les cinc pàgines o si la sol·licitud la sol·licita.

Aprovacions

Aquesta secció és crucial per al procés, tant si es tracta d’una resposta a una RFP, des d’aquesta plantilla o des d’alguna altra font. Aquesta secció documenta les confirmacions que el projecte és una prova i proporciona un acord vinculant entre els diferents membres del projecte. Mai no heu d’iniciar un projecte fins que no hàgiu obtingut totes les signatures necessàries i tingueu el compromís del campió del projecte i de les parts interessades per iniciar el projecte. En cas contrari, és possible que us trobeu en un problema si el projecte es cancel·la o si l'abast del projecte canvia o els lliuraments.

Amb les aprovacions en vigor, els canvis d’abast i de lliuraments són molt més difícils de fer i, si hi ha disputes, la signatura d’aprovacions proporcionarà una clara comprensió del que es va acordar. Per descomptat, sempre hi ha una qüestió d’interpretació.

Les aprovacions han d’incloure el nom de la persona, el seu títol, seguit de la seva signatura i, finalment, la data en què es va signar el document.



Nom	Títol / Funció	Signatura	Data

Canvis

La secció Canvis proporciona un registre de tots els canvis que es van fer o es faran al document de Proposta de desenvolupament de programari. No documenta cap canvi en l’abast del propi projecte ni en cap altre aspecte del projecte. La secció de canvis hauria d’incloure com a mínim el nom de la persona que fa el canvi, la data del canvi i un comentari o descripció del canvi.



Autor	Data del canvi	Descripció o comentari

Glossari i sigles

Enumereu els termes o les sigles i les seves definicions. No suposeu que tothom conegui el significat dels termes o de les sigles, sobretot si teniu previst utilitzar consultors externs i els termes són interns, integrats a la vostra cultura corporativa i a la vostra llengua. Totes les organitzacions tenen les seves pròpies llengües i sigles. Està bé utilitzar-los a la proposta sempre que estiguin documentats adequadament.

A més, si s’utilitzen sigles específiques de la indústria, també s’han de documentar perquè tothom tingui una clara comprensió del significat dels termes i les sigles i formuli millors interpretacions.

Les següents sigles són de la plantilla actual. Es proporcionen com a exemple.

RFP: sol·licitud de proposta
ROI: retorn de la inversió
CAGR: taxa de creixement anual composta
TI: Tecnologies de la Informació
CAPEX: despesa de capital
UoM: Unitat de mesura

Abast

L’abast de la proposta hauria d’esbossar a un nivell alt els detalls generals del projecte, allò que s’inclou i s’exclou. L’abast hauria de proporcionar una descripció general, la durada del projecte i els objectius principals. Què intenteu aconseguir amb aquesta inversió en el projecte de desenvolupament de programari proposat.

Cronologia

Aquesta secció inclourà les dates d’inici i finalització (estimades). Assegureu-vos de construir un buffer i planificar contingències. Una bona regla general és afegir un buffer del 75% a la vostra cronologia.

Membres del projecte

Els membres del projecte haurien d’incloure el campió del projecte i les parts interessades. El campió sol ser un executiu que dirigeix el projecte i el pressupost general. L’interès general sol ser un promotor o patrocinador intern. També poden ser els defensors en funció de l’abast del projecte o del tipus d’organització que sol·liciti la proposta de desenvolupament de programari. La llista restant conté rols típics que la gent realitza en un projecte.

El següent només es proporciona com a exemple del tipus de rols que poden tenir els participants del projecte. Algunes persones poden tenir més d’un paper. Depenent de l'abast del projecte, la llista de membres del projecte pot ser molt llarga o la mateixa persona pot assumir funcions diferents.

La llista ha de contenir tota la informació que identifiqui adequadament la persona, el seu paper dins del projecte, com arribar-hi i quines són les seves responsabilitats. Podeu incloure altra informació en funció de la RFP o del tipus d’organització amb la qual treballareu i les seves polítiques internes.



Membre de l'equip	Paper	Informació de contacte	Responsabilitats
	Campió
	Interessat
	Cap de projecte
	Arquitecte
	Analista
	Desenvolupador

Oportunitat de negoci

La majoria de les plantilles disponibles defineixen aquesta secció com a "Problema de negoci" o "Declaració de problema", però sovint m'he trobat amb líders empresarials que s'ofenen del fet que tinguin un problema a la seva unitat o procés de negoci. Recordo que una directora em va llançar literalment del seu despatx perquè havia dit que arreglàvem un procés i em va dir que no seria algú de TI (Tecnologia de la Informació) qui dictaria si tenia algun problema. amb els seus processos o no.

Així que tingueu cura amb la redacció. Sempre faig servir el terme "Oportunitat de negoci" perquè, al final, la proposta respon a una oportunitat de negoci per millorar un procés, donar suport a un procés o automatitzar un procés



Declaració de negoci	Com satisfà el sistema el requisit
Procés de negoci afectat, situació, problema	Com millorarà la solució proposada l’àrea de negoci objectiu
Quina necessitat s’està resolent	Com ho abordarà el projecte actual

Visió general de la solució

A la secció Visió general de la solució, podeu proporcionar una visió general del sistema d’alt nivell. Aquesta visió general pot incloure un mapa de navegació si la proposta és per a un lloc web o una aplicació web. També podeu incloure un diagrama de flux del flux de procés. També podeu incloure un diagrama dels components principals del sistema.

L'objectiu aquí és proporcionar a la persona que pren la decisió prou informació perquè entengui què és el sistema, com funcionarà i quins són els principals elements bàsics. Per descomptat, això només és una pauta, ja que una organització pot tenir un format formal que defineixi el que haureu de proporcionar a la proposta, sobretot si esteu tractant amb una agència governamental o el departament de defensa.

Funcions i lliuraments

Aquesta secció proporciona un mecanisme per assignar una característica del sistema proposat a un producte tangible. També he vist aquesta secció que conté una estimació de temps per completar el lliurament, però no m'agrada fer-lo servir perquè és massa restrictiva i crea una vinculació. Quan treballeu al projecte, és possible que els lliuraments no s'alineïn exactament tal com s'ha escrit., per tant, si us heu compromès en un paper a acabar un lliurament en un temps determinat, elimineu o disminuïu qualsevol elasticitat més endavant quan realment realitzeu el projecte.

Una altra columna que es pot afegir és la versió a la qual pertany el lliurable. Això és útil si el projecte es lliurarà durant un període de temps més llarg i hi haurà diverses versions. Això també es pot aplicar a un projecte basat en Agile o Lean en què cada característica o User Story pertany a una versió.

El concepte és senzill; per a cada característica del sistema, proporcioneu el nom de la característica, una breu descripció i quin lliurament satisfarà els requisits de la funció.



Funció	Descripció	Lliurable

Pressupost i ROI

El pressupost i el ROI són probablement la part més important per a alguns executius. Tots estan ansiosos per saber quant els costarà el sistema o quina repercussió tindrà aquest projecte en el pressupost del seu departament. Això és especialment cert si el projecte no es va incloure al Capex al començament de l'any fiscal.

De vegades, fins i tot si es va pressupostar el projecte, un altre projecte pot tenir prioritat sobre la proposta actual i es poden desviar els fons de la font prevista. Sovint s’està produint una mica de baralla política a nivell executiu i directiu per tirar endavant un projecte i sovint hi ha circumstàncies imprevistes que poden prevaler sobre els projectes previstos.

Per tant, estigueu preparats per treballar amb els vostres grups d'interès per ajudar-vos en les negociacions o sigueu flexibles i proactius per proporcionar una solució de treball si la situació pressupostària va de costat. És millor adaptar el projecte a la realitat pressupostària, fins i tot estenent els lliuraments del sistema durant un període de temps més llarg o fins i tot allunyant-se del projecte. És molt millor allunyar-se que haver treballat en un projecte, no cobrar i haver de recórrer a un litigi al llarg de la carretera.

La taula següent només té finalitats de demostració per donar-vos una idea de com preparar un pressupost. Naturalment, haureu d'afegir les vostres pròpies línies de comanda per adaptar-les al vostre projecte. A continuació, empleneu la quantitat, el preu unitari, la unitat de mesura i el total de la línia de comanda. A continuació, suma els totals de la línia de comanda a la part inferior.

Això proporcionarà una bona imatge de la inversió necessària per fer el projecte de programari. A la majoria dels executius amb els quals he treballat els agrada saber quina serà la taxa de rendiment o quant costarà aquest projecte al llarg del temps, de manera que també incloc un valor de ROI simple i un CAGR, ja sigui mitjançant les meves pròpies estimacions i suposicions (que han de ser explicat) a la proposta o utilitzant les estimacions i els supòsits proporcionats.



Article del projecte	Import	Preu unitari	UoM	Total
Llicència de programari
Màquina (s)
Llicència de servidor
Llicència de base de dades
Consultor de desenvolupament
Gestió de projectes
Formació (Temps + Materials)

ROI

El càlcul del ROI és molt fàcil. Bàsicament la fórmula són els guanys: cost dividit per cost. A continuació es proporciona la fórmula:

L’únic inconvenient és que el càlcul no té en compte el temps, de manera que el ROI és bo per a projectes a curt termini, però per a projectes a llarg termini generalment incloc un CAGR (taxa de creixement anual composta). El càlcul del CAGR és una taxa de rendiment interanual per a un moment determinat.

CAGR

La fórmula CAGR és:

La primera part és la divisió del valor final pel valor inicial. El resultat s’eleva a la potència d’1 en el nombre d’anys invertits. El valor resultant es resta per 1.

Beneficis

En aquesta secció, enumereu els avantatges empresarials que proporcionarà el projecte de programari. Es poden llistar en format de vinyeta sempre que coincideixin amb els objectius generals. Han de demostrar com el programari o el sistema milloraran el valor empresarial.

En poques paraules, com va la solució proposada per ajudar el negoci a tenir més èxit i assolir els seus objectius de declaració? Utilitzeu paraules i frases positives.

Restriccions

La secció de restriccions hauria d’enumerar qualsevol restricció tangible i intangible que pugueu preveure. Això es pot relacionar amb els equips, alguns factors d’estacionalitat, com ara la parada d’una planta de producció, que la majoria de plantes fan almenys un cop a l’any com a exemple.

Intenteu minimitzar les restriccions o pinteu-les com a mínimes. No enumereu cap aspecte negatiu del programari o del sistema o, si cal, proporcioneu solucions alternatives.