Kā uzrakstīt programmatūras izstrādes priekšlikumu

Kā uzrakstīt veiksmīgu programmatūras izstrādes priekšlikumu.

Kevins Langedoks

Programmatūras izstrādes priekšlikuma mērķis ir sniegt risinājumu, kuru lasīs biznesa cilvēki, tāpēc saglabājiet to vienkāršu un saprotamu; maksimāli atturieties no tehniskajiem noteikumiem. Lai sagatavotu veiksmīgu programmatūras izstrādes priekšlikumu, var izmantot šādu izklāstu. Ir svarīgi paturēt prātā, ka cilvēkiem, ar kuriem jūs iepazīstināsiet priekšlikumu, nav daudz laika, lai lasītu garu dokumentu. Jūs varat to ņemt no manis, es esmu uzrakstījis simtiem priekšlikumu vairāk nekā 20 gadus ilgā informācijas tehnoloģiju jomā: biznesa cilvēki vēlas tikai tik daudz informācijas, lai ļautu viņiem pieņemt apzinātu lēmumu.

Ja jūs atbildat uz piedāvājuma pieprasījumu (RFP) un jums jāievēro noteikts lapu diapazons, jo lapas ir iepriekš izdrukātas vai satura prasības liek jums iesniegt pārāk garu priekšlikumu, apsveriet iespēju izmantot kopsavilkumu. Es esmu pievienojis sadaļu, kurā aprakstīts, kā to sagatavot.

Priekšlikuma garums

Esmu redzējis veidnes un diskusijas, kas aizstāv priekšlikumus, kas ilgst 50 vai lappuses. Ticiet man, jūs zaudēsiet uzņēmuma vadītāja interesi pēc piektās lapas. Pēc priekšlikuma pieņemšanas projekta dokumenti, protams, būs detalizētāki, jo tie būs paredzēti projekta komandai un būs sistēmas darba rasējumi. Tas attieksies uz lielāko daļu klientu, bet (jā, vienmēr ir, bet) ja priekšlikums ir atbilde uz priekšlikuma pieprasījumu (RFP), jums jāievēro RFP. Tāpat valdībai vai militārajai aģentūrai, iespējams, būs stingras vadlīnijas par to, kā sagatavot programmatūras izstrādes priekšlikumu, un atkarībā no sistēmas sarežģītības tās var ietvert vairākas lappuses (10, 20, 30, 50 vai vairāk).Šis noteikums joprojām attiecas uz lielām organizācijām, kurām var būt oficiāls priekšlikumu iesniegšanas process, it īpaši, ja tās ir valsts kapitālsabiedrība un tām ir jāievēro visi Sarbannes-Oxley vai ISO noteikumi vai standarti.

Kopsavilkums

Ja piedāvājums pārsniedz 20 lappuses, varat apsvērt iespēju sniegt kopsavilkumu, kas ir viena priekšlikuma sadaļu peidžeris. Jūs pat varat sniegt kopsavilkumu PowerPoint formātā. Ja jūs plānojat programmatūras izstrādes priekšlikuma prezentācijā izmantot kopsavilkumu, iesniedziet priekšlikumu, izmantojot kopsavilkumu, un izpilddirektors vēlāk var to izlasīt, piemēram, biznesa lidojuma laikā.

Veidne

Šis izklāsts faktiski ir laba veidne, kuru varat izmantot, lai sagatavotu savu programmatūras izstrādes priekšlikumu. Sagatavojot priekšlikumu, es vienmēr paturēju prātā lifta piķa noteikumu, un arī jums tas būtu jādara. Būtībā Elevator Pitch nosaka, ka jūsu priekšlikumam nevajadzētu būt daudz ilgākam par laiku, kas nepieciešams, lai iesniegtu priekšlikumu ar liftu no ēkas pirmā stāva līdz augšējam stāvam.

Projekta nosaukums

Ar apakšvirsrakstu vai apkopotu informāciju par priekšlikumu

Priekšlikumam jābūt nosaukumam un apakšsadaļai, kurā apkopots programmatūras piedāvājuma konteksts. Jūs pievienojat arī nodaļas, dienesta, nodaļas vai organizācijas nosaukumu, kurai paredzēts projekts.

Ja atbildat uz RFP (Request For Piedāvājums), iekļaujiet tajā visu informāciju, kas RFP ir nepieciešama vai norādīta kā obligāta. Esmu redzējis arī RFP, kas pieprasa, lai jūs papildus nosaukumam pirmajā lapā ievietotu apstiprinājuma parakstus, bet šajā piemērā es parakstus ievietoju lapā ar sadaļu Izmaiņas.

Satura rādītājs

Nākamajā lapā jāiekļauj satura rādītājs, kurā uzskaitītas galvenās priekšlikuma sadaļas. Pēc izvēles varat iekļaut lapu numurus, ja priekšlikums pārsniedz piecas lapas vai ja to prasa RFP.

Apstiprinājumi

Šai sadaļai ir izšķiroša nozīme procesā, neatkarīgi no tā, vai tā ir atbilde uz RFP vai no šīs veidnes, vai no kāda cita avota. Šī sadaļa dokumentē apstiprinājumus, ka projekts ir sākums, un nodrošina saistošu vienošanos starp dažādiem projekta dalībniekiem. Jums nekad nevajadzētu sākt projektu, kamēr neesat ieguvis visus nepieciešamos parakstus un projekta vadītājs un ieinteresētās puses nav apņēmušās sākt projektu. Pretējā gadījumā jūs varat atrasties saistoši, ja projekts tiek atcelts vai mainās projekta darbības joma vai rezultāti.

Ieviešot apstiprinājumus, darbības jomu un rezultātus ir daudz grūtāk mainīt, un, ja ir strīdi, parakstot apstiprinājumus, jūs skaidri (vai) sapratīsit, par ko ir panākta vienošanās. Protams, vienmēr ir jautājums par interpretāciju.

Apstiprinājumos jāiekļauj personas vārds, uzvārds, vārds, paraksts un visbeidzot datums, kad dokuments tika parakstīts.



Nosaukums	Nosaukums / loma	Paraksts	Datums

Izmaiņas

Sadaļā Izmaiņas ir reģistrēts visu izmaiņu žurnāls, kas tika veikts vai tiks veikts programmatūras izstrādes priekšlikuma dokumentā. Tajā nav dokumentētas nekādas izmaiņas paša projekta apjomā vai citā projekta aspektā. Sadaļā Izmaiņas jāiekļauj vismaz izmaiņas veicošās personas vārds, izmaiņu datums un komentārs vai izmaiņu apraksts.



Autors	Izmaiņu datums	Apraksts vai komentārs

Vārdnīca un akronīmi

Uzskaitiet visus terminus vai akronīmus un to definīcijas. Nedomājiet, ka visi zina terminu vai akronīmu nozīmi, it īpaši, ja plānojat izmantot ārējus konsultantus un šie termini ir iekšēji, iekļauti jūsu korporatīvajā kultūrā un lingo. Katrai organizācijai ir savs lingo un akronīmi. Ir pareizi tos izmantot priekšlikumā, ja vien tie ir pienācīgi dokumentēti.

Arī tad, ja tiek izmantoti kādi nozarei raksturīgi saīsinājumi, tie arī ir jādokumentē, lai ikvienam būtu skaidra izpratne par terminu un akronīmu nozīmi un labāk formulētu interpretācijas.

Šie akronīmi ir no pašreizējās veidnes. Tie ir sniegti kā piemērs.

RFP: Pieprasījums iesniegt priekšlikumu
IA: ieguldījumu atdeve
CAGR: Saliktais gada pieauguma temps
IT: informācijas tehnoloģija
CAPEX: Kapitāla izdevumi
UoM: mērvienība

Darbības joma

Priekšlikuma darbības jomā būtu jāprecizē projekta vispārējā informācija, kas ir iekļauts un izslēgts. Darbības jomai jāsniedz vispārējs apraksts, projekta ilgums, galvenie mērķi. Ko jūs mēģināt paveikt ar šo ieguldījumu ierosinātajā programmatūras izstrādes projektā.

Laika skala

Šajā sadaļā tiks iekļauti sākuma un beigu datumi (aptuvenie). Noteikti izveidojiet buferi un plānojiet neparedzētiem gadījumiem. Labs īkšķa noteikums ir pievienot laika grafikam 75% buferi.

Projekta dalībnieki

Projekta dalībniekiem jāiekļauj projekta čempions un ieinteresētās personas. Čempions parasti ir izpilddirektors, kurš vada kopējo projektu un budžetu. Ieinteresētā persona parasti ir iekšējs veicinātājs vai sponsors. Viņi var būt arī čempioni atkarībā no projekta apjoma un organizācijas veida, kas pieprasa programmatūras izstrādes priekšlikumu. Atlikušajā sarakstā ir tipiskas lomas, kuras cilvēki veic projektā.

Tālāk ir sniegts tikai piemērs tam, kāda veida lomas projekta dalībniekiem var būt. Dažiem cilvēkiem var būt vairāk nekā viena loma. Atkarībā no projekta darbības jomas projekta dalībnieku saraksts var būt ļoti garš vai viena un tā pati persona var uzņemties dažādas lomas.

Sarakstā jāiekļauj visa informācija, kas pareizi identificē personu, tās lomu projektā, kā ar viņu sazināties un kādi ir viņu pienākumi. Jūs varat iekļaut citu informāciju atkarībā no RFP vai organizācijas veida, ar kuru strādāsit, un viņu iekšējām politikām.



Komandas biedrs	Loma	Kontaktinformācija	Pienākumi
	Čempions
	Ieinteresētā persona
	Projektu menedžeris
	Arhitekts
	Analītiķis
	Izstrādātājs

Biznesa iespējas

Lielākā daļa pieejamo veidņu šo sadaļu definē kā “Biznesa problēma” vai “Problēmas izklāsts”, tomēr es bieži esmu saskāries ar uzņēmumu vadītājiem, kuri apvaino to, ka viņu biznesa vienībā vai procesā ir problēmas. Es atceros, ka viena direktore mani burtiski izmeta no kabineta, jo es biju paziņojis, ka mēs salabojam procesu, un viņa man teica, ka tas nebūs kāds no IT (informācijas tehnoloģiju) darbiniekiem, kurš diktēs, ja viņai ir problēmas ar viņas procesiem vai nē.

Tāpēc esiet uzmanīgs ar formulējumu. Es vienmēr lietoju terminu “uzņēmējdarbības iespēja”, jo galu galā priekšlikums ir atbilde uz uzņēmējdarbības iespēju uzlabot procesu, atbalstīt procesu vai automatizēt procesu



Biznesa paziņojums	Kā sistēma apmierinās prasību
Ietekmētais biznesa process, situācija, problēma	Kā piedāvātais risinājums uzlabos mērķa uzņēmējdarbības jomu
Kāda vajadzība tiek risināta	Kā notiek pašreizējā projekta risināšana

Risinājuma pārskats

Sadaļā Risinājumu pārskats varat sniegt sistēmas augsta līmeņa pārskatu. Šajā pārskatā var iekļaut navigācijas karti, ja priekšlikums ir paredzēts vietnei vai tīmekļa lietotnei. Varat arī iekļaut procesa plūsmas blokshēmu. Varat arī iekļaut sistēmas galveno komponentu diagrammu.

Mērķis ir sniegt personai, kas pieņem lēmumu, pietiekami daudz informācijas, lai tā saprastu, kāda ir sistēma, kā tā darbosies un kādi ir galvenie pamatelementi. Protams, tā ir tikai pamatnostādne, jo organizācijai var būt formāls formāts, kas nosaka, kas jums būs jāpiedāvā priekšlikumā, it īpaši, ja jums ir darīšana ar valdības aģentūru vai Aizsardzības departamentu.

Funkcijas un nododamie materiāli

Šajā sadaļā ir sniegts mehānisms, lai ierosinātās sistēmas iezīmi kartētu ar taustāmu rezultātu. Esmu redzējis arī šo sadaļu, kurā ir laika aprēķins, lai pabeigtu piegādi, taču man nepatīk to izmantot, jo tas ir pārāk ierobežojošs un rada saikni. Strādājot pie projekta, rezultāti var nebūt precīzi atbilstoši norakstītiem, tādēļ, ja esat uz papīra apņēmies pabeigt darbu līdz noteiktam laikam, tas noņem vai samazina elastību vēlāk, kad jūs faktiski veicat projektu.

Vēl viena kolonna, ko var pievienot, ir laidiens, kuram pieder piegādājamais. Tas ir ērti, ja projekts tiks piegādāts ilgākā laika periodā un būs vairākas izlaišanas. Tas var attiekties arī uz Agile vai Lean balstītu projektu, kur katra funkcija vai lietotāja stāsts pieder laidienam.

Jēdziens ir vienkāršs; katrai sistēmas iezīmei norādiet funkcijas nosaukumu, īsu aprakstu un to, kurš piegādājamais produkts apmierinās prasības.



Funkcija	Apraksts	Piegādājams

Budžets un IA

Budžets un IA, iespējams, dažiem vadītājiem ir vissvarīgākā daļa. Viņi visi vēlas uzzināt, cik viņiem maksās sistēma vai cik lielu ietekmi šis projekts atstās uz viņu nodaļas budžetu. Tas jo īpaši attiecas uz gadījumiem, ja fiskālā gada sākumā projekts netika iekļauts Capex.

Dažreiz, pat ja projektam ir paredzēts budžets, citam projektam var būt prioritāte pār pašreizējo priekšlikumu, un līdzekļus var novirzīt no paredzētā avota. Izpilddirektora un vadības līmenī bieži notiek neliela politiska ķilda, lai projekts tiktu realizēts, un bieži vien ir neparedzēti apstākļi, kuriem var būt prioritāte pār plānotajiem projektiem.

Tāpēc esiet gatavs sadarboties ar savu ieinteresēto personu, lai palīdzētu sarunās, vai esiet elastīgs un proaktīvs, lai sniegtu efektīvu risinājumu, ja budžeta situācija iet uz sāniem. Labāk ir pielāgot projektu budžeta realitātei, pat sadalot sistēmas rezultātus ilgākā laika posmā vai pat ejot prom no projekta. Daudz labāk ir aiziet prom, nekā strādāt pie projekta un nesaņemt algu, un jums ir jāizmanto tiesvedība pa ceļu.

Šī tabula ir paredzēta tikai demonstrēšanai, lai sniegtu priekšstatu par budžeta sagatavošanu. Protams, jums būs jāpievieno savi rindas elementi, lai tie atbilstu jūsu projektam. Tad jūs aizpildāt daudzumu, vienības cenu, mērvienību un rindas vienības kopsummu. Tad saskaitiet rindas vienību kopsummu apakšā.

Tas sniegs labu priekšstatu par programmatūras projekta veikšanai nepieciešamajiem ieguldījumiem. Lielākajai daļai vadītāju, ar kuriem esmu strādājis, patīk zināt, kāda būs atdeves likme vai cik šis projekts laika gaitā maksās, tāpēc es izmantoju arī vienkāršu IA vērtību un CAGR, vai nu izmantojot savas aplēses un pieņēmumus (kuriem jābūt paskaidrots) priekšlikumā vai izmantojot iesniegtās aplēses un pieņēmumus.



Projekta vienums	Summa	Vienības cena	UoM	Kopā
Programmatūras licence
Mašīna (-as)
Servera licence
Datu bāzes licence
Attīstības konsultants
Projektu vadība
Apmācība (laiks + materiāli)

IA aprēķināšana ir ļoti vienkārša. Būtībā formula ir ieguvumi - izmaksas dalītas ar izmaksām. Formula ir sniegta zemāk:

Vienīgais trūkums ir tas, ka aprēķinos netiek ņemts vērā laiks, tāpēc IA ir laba īstermiņa projektiem, bet ilgāka termiņa projektos es parasti iekļauju CAGR (salikto gada izaugsmes tempu). CAGR aprēķins ir gada un gada atdeves likme noteiktā laika posmā.

CAGR

CAGR formula ir:

Pirmā daļa ir gala vērtības dalīšana ar sākuma vērtību. Rezultāts tiek palielināts līdz 1 jaudai ieguldīto gadu laikā. Iegūto vērtību atņem ar 1.

Ieguvumi

Šajā sadaļā jūs uzskaitāt biznesa priekšrocības, ko nodrošinās programmatūras projekts. Tos var uzskaitīt aizzīmju formātā, ja vien tie atbilst vispārējiem mērķiem. Viņiem vajadzētu parādīt, kā programmatūra vai sistēma palielinās biznesa vērtību.

Īsumā, kā piedāvātais risinājums palīdzēs biznesam būt veiksmīgākam un sasniegt izvirzītos mērķus? Izmantojiet pozitīvus vārdus un teikumus.

Ierobežojumi

Ierobežojumu sadaļā jāuzskaita visi taustāmie un nemateriālie ierobežojumi, kurus varat paredzēt. Tas var attiekties uz aprīkojumu, kādu sezonalitātes faktoru, piemēram, ražotnes slēgšanu, ko vairums rūpnīcu veic kā piemēru vismaz reizi gadā.

Mēģiniet mazināt ierobežojumus vai krāsot tos kā minimālus. Neuzskaitiet programmatūras vai sistēmas negatīvos aspektus, un, ja jums tas ir nepieciešams, sniedziet risinājumus.