Tartalomjegyzék:
- A javaslat hossza
- vezetői összefoglaló
- A sablon
- Projekt címe
- Tartalomjegyzék
- Jóváhagyások
- Változtatások
- Szójegyzék és betűszavak
- Hatály
- Idővonal
- Projekt tagok
- Üzleti lehetőség
- Megoldás áttekintése
- Jellemzők és teljesítések
- Költségvetés és megtérülés
- Előnyök
- Korlátok
Hogyan lehet sikeres szoftverfejlesztési javaslatot írni.
Kevin Languedoc
A szoftverfejlesztési javaslat célja, hogy olyan megoldást közvetítsen, amelyet az üzletemberek elolvasnak, ezért tartsa egyszerűnek és lényegre törőnek; amennyire csak lehetséges, maradjon távol a szakkifejezésektől. A következő vázlat felhasználható a sikeres szoftverfejlesztési javaslat elkészítéséhez. Fontos szem előtt tartani, hogy azoknak az embereknek, akik elõterjesztik a javaslatot, nincs sok idejük egy hosszadalmas dokumentum elolvasására. Elveheti tőlem, több mint 20 évig írtam javaslatokat az informatika területén: az üzletemberek csak annyi információt akarnak, hogy megalapozott döntést hozzanak.
Ha válaszol egy ajánlatkérésre (RFP), és tiszteletben kell tartania egy bizonyos oldaltartományt, mert az oldalak előre vannak kinyomtatva, vagy a tartalmi követelmények túl hosszú ajánlatra kényszerítik, akkor fontolja meg az Összefoglaló használatát. az alábbiakban felvettem egy részt, amely felvázolja az elkészítés módját.
A javaslat hossza
Láttam olyan sablonokat és beszélgetéseket, amelyek 50 vagy több oldalas javaslatokat támogatnak. Hidd el, az ötödik oldal után elveszíti az üzletvezető érdeklődését. A javaslat elfogadását követően a tervdokumentumok természetesen részletesebbek lesznek, mivel azokat a projekt csapatának szánják, és a rendszer működő tervrajzai lesznek. Ez a legtöbb ügyfélre vonatkozik, de (igen, mindig van de), ha az ajánlat egy Ajánlatkérésre (RFP) válaszol, akkor be kell tartania az RFP-t. Valamely kormánynak vagy katonai ügynökségnek valószínűleg szigorú irányelvei lesznek a szoftverfejlesztési javaslat elkészítésére vonatkozóan, és a rendszer összetettségétől függően több oldalt (10, 20, 30, 50 vagy több) tartalmazhat.Ez a szabály továbbra is érvényes azokra a nagy szervezetekre, amelyeknek hivatalos pályázati folyamata lehet, különösen, ha állami vállalatok, és be kell tartaniuk a Sarbannes-Oxley vagy az ISO előírásait vagy szabványait.
vezetői összefoglaló
Ha a javaslat meghaladja a 20 oldalt, akkor fontolóra veheti az Összefoglaló összefoglalását, amely a javaslat szakaszainak egyhívója. Akár összefoglalót is adhat PowerPoint formátumban. Ha tervezi az ügyvezető összefoglaló használatát a szoftverfejlesztési javaslat bemutatójában, akkor az ügyvezető összefoglaló segítségével mutassa be a javaslatot, és az ügyvezető egy későbbi időpontban, például üzleti repülés közben olvashatja el a javaslatot.
A sablon
Az alábbi vázlat valóban jó sablon, amellyel elkészítheti saját szoftverfejlesztési javaslatát. A javaslat elkészítésekor mindig szem előtt tartom a Felvonómagasság szabályt, és neked is kell. Alapvetően a Felvonómagasság előírja, hogy az Ön javaslata nem lehet sokkal hosszabb, mint az az idő, amely egy épület földszintjétől a legfelső emeletéig tartó lifttel felér, hogy előterjessze a javaslatot.
Projekt címe
Felirattal vagy összesített információkkal a javaslatról
A javaslatnak tartalmaznia kell egy címet és egy alszakaszt, amely összefoglalja a szoftverjavaslat kontextusát. Meg kell adnia annak a részlegnek, szolgáltatásnak, osztálynak vagy szervezetnek a nevét is, amelynek a projektet szánják.
Ha válaszol egy RFP-re (ajánlatkérés), akkor adjon meg minden információt, amelyet kötelező vagy kötelezően felsorol az RFP-ben. Láttam olyan RFP-ket is, amelyek azt kérik, hogy az első oldal címe mellett tegye be a jóváhagyási aláírásokat, de ebben a példában az aláírásokat a Változások részhez tartozó oldalra tettem.
Tartalomjegyzék
A következő oldalon tartalmaznia kell egy tartalomjegyzéket, amely felsorolja a javaslat fő szakaszait. Opcionálisan felveheti az oldalszámokat, ha az ajánlat meghaladja az öt oldalt, vagy ha az RFP előírja.
Jóváhagyások
Ez a szakasz kulcsfontosságú a folyamat szempontjából, függetlenül attól, hogy az válasz egy RFP-re, vagy ebből a sablonból származik, vagy más forrásból származik. Ez a szakasz dokumentálja a megerősítéseket arról, hogy a projekt menetrendszerű, és kötelező érvényű megállapodást biztosít a projekt különböző tagjai között. Soha ne indítson projektet, amíg meg nem szerezte az összes szükséges aláírást, és a projekt bajnokától és az érdekelt felektől elkötelezte magát a projekt megkezdése mellett. Ellenkező esetben egy kötésben találhatja magát, ha a projektet törlik, vagy ha megváltozik a projekt köre vagy az eredmények.
A jóváhagyások meglétével a hatókör és az eredmények megváltoztatása sokkal nehezebb, és ha viták merülnek fel, a jóváhagyások aláírása egyértelmű (vagy) megértést nyújt a megállapodásban. Természetesen mindig van értelmezési kérdés.
A jóváhagyásoknak tartalmazniuk kell a személy nevét, címét, majd aláírását és végül a dokumentum aláírásának dátumát.
Név | Cím / szerep | Aláírás | Dátum |
---|---|---|---|
Változtatások
A Változások szakasz naplót tartalmaz minden módosításról, amelyet a Szoftverfejlesztési javaslat dokumentumban végrehajtottak vagy végrehajtani fognak. Nem dokumentálja a projekt terjedelmének vagy a projekt bármely más aspektusának változását. A Változások szakasznak tartalmaznia kell legalább a változtatást végző személy nevét, a változás dátumát és a változáshoz fűzött megjegyzést vagy leírást.
Szerző | A változás dátuma | Leírás vagy megjegyzés |
---|---|---|
Szójegyzék és betűszavak
Soroljon fel minden kifejezést vagy rövidítést és azok meghatározását. Ne feltételezzük, hogy mindenki ismeri a kifejezések vagy a betűszavak jelentését, különösen akkor, ha külső tanácsadók használatát tervezi, és a kifejezések belsőek, beágyazódnak a vállalati kultúrába és a lingóba. Minden szervezetnek megvannak a maga nyelve és betűszavai. Rendben van, ha a javaslatban felhasználják őket, amennyiben megfelelően dokumentálják őket.
Ha valamilyen iparági specifikus rövidítést is használnak, akkor azokat dokumentálni kell, hogy mindenki egyértelműen megértse a kifejezések és rövidítések jelentését, és jobb értelmezéseket fogalmazzon meg.
A következő rövidítések az aktuális sablonból származnak. Példaként szolgálnak.
- RFP: Ajánlatkérés
- ROI: A befektetés megtérülése
- CAGR: Összetett éves növekedési ráta
- IT: Informatika
- CAPEX: Tőkekiadások
- UoM: Mértékegység
Hatály
A javaslat hatályának magas szinten kell felvázolnia a projekt átfogó részleteit, a benne foglaltakat és a kizártakat. A hatókörnek átfogó leírást, a projekt időtartamát és a fő célkitűzéseket kell tartalmaznia. Mit akar elérni ezzel a beruházással a javasolt szoftverfejlesztési projektben.
Idővonal
Ez a szakasz tartalmazza a kezdet és a befejezés dátumát (becsült). Ügyeljen arra, hogy beépítsen egy puffert és megtervezze az esetleges eseményeket. Egy jó szabály a hüvelykujj, hogy hozzáad egy 75% -os puffert az idővonaladhoz.
Projekt tagok
A projekt tagjainak tartalmazniuk kell a projekt bajnokát és az érdekelt feleket. A bajnok általában ügyvezető, aki a teljes projektet és a költségvetést vezérli. Az érintett általában belső promóter vagy szponzor. Ők is bajnokok lehetnek a projekt terjedelmétől és a szoftverfejlesztési javaslatot igénylő szervezet típusától függően. A fennmaradó lista tipikus szerepeket tartalmaz, amelyeket az emberek egy projektben végrehajtanak.
Az alábbiak csak a projektben résztvevők szerepköreinek példájául szolgálnak. Néhány embernek több szerepe is lehet. A projekt terjedelmétől függően a projekt tagjainak listája nagyon hosszú lehet, vagy ugyanaz a személy különböző szerepeket tölthet be.
A listának tartalmaznia kell minden olyan információt, amely megfelelően azonosítja a személyt, a projektben betöltött szerepét, elérési módját és felelősségét. Egyéb információkat is felvehet az RFP-től vagy a szervezet típusától és a belső házirendtől függően.
Csapat tagja | Szerep | Elérhetőség | Feladatok |
---|---|---|---|
Bajnok |
|||
Érintett |
|||
Projekt menedzser |
|||
Építészmérnök |
|||
Elemző |
|||
Fejlesztő |
Üzleti lehetőség
A legtöbb rendelkezésre álló sablon ezt a szakaszt „Üzleti problémának” vagy „Probléma kimutatásnak” definiálja, de gyakran találkoztam olyan üzleti vezetőkkel, akik megsértődnek azon a tényen, hogy problémájuk van az üzleti egységükben vagy folyamatukban. Emlékszem, az egyik igazgató szó szerint kidobott az irodájából, mert kijelentettem, hogy javítunk egy folyamatot, és azt mondta nekem, hogy nem az informatikai (informatikai) személyről lesz szó, aki diktál, ha problémája van folyamataival vagy sem.
Ezért legyen óvatos a megfogalmazással. Mindig az „üzleti lehetőség” kifejezést használom, mert a javaslat végül válaszként szolgál egy üzleti lehetőségre a folyamat javítására, a folyamat támogatására vagy a folyamat automatizálására.
Üzleti nyilatkozat | Hogyan teljesíti a rendszer a követelményt |
---|---|
Érintett üzleti folyamat, helyzet, probléma |
Hogyan javítja a javasolt megoldás a megcélzott üzleti területet |
Milyen igényt kezelnek |
Hogyan fogja kezelni a jelenlegi projekt |
Megoldás áttekintése
A Megoldás áttekintése részben magas szintű áttekintést adhat a rendszerről. Ez az áttekintés tartalmazhat navigációs térképet, ha a javaslat egy webhelyre vagy webalkalmazásra vonatkozik. Felvehet egy folyamatábrát is. Hozzáadhat egy diagramot is a rendszer főbb elemeiről.
A cél itt az, hogy a döntést hozó személynek elegendő információt nyújtson ahhoz, hogy megértse, mi a rendszer, hogyan fog működni, és melyek a fő építőelemek. Természetesen ez csak egy iránymutatás, mivel egy szervezetnek lehet hivatalos formátuma, amely meghatározza, hogy mire lesz szüksége a javaslatban, különösen, ha kormányzati ügynökséggel vagy a védelmi minisztériummal van dolga.
Jellemzők és teljesítések
Ez a szakasz egy mechanizmust biztosít a javasolt rendszer jellemzőinek kézzelfogható teljesítéshez való feltérképezéséhez. Láttam ezt a részt is, amely tartalmaz egy időbecslést a teljesítés befejezéséhez, de nem szeretem ezt használni, mert túl korlátozó és összekapcsolódást eredményez. A projekten dolgozva előfordulhat, hogy az eredmények nem pontosan úgy sorakoznak, ahogyan le van írva., tehát ha papíron elkötelezte magát egy kézbesítés befejezéséért egy bizonyos időre, az eltávolítja vagy csökkenti a rugalmasságot később, amikor ténylegesen végzi a projektet.
Egy másik oszlop, amelyet hozzá lehet adni, az a kiadás, amelyhez a szállítmány tartozik. Ez akkor hasznos, ha a projektet hosszabb ideig szállítják le, és több kiadás lesz. Ez vonatkozhat egy Agile vagy Lean alapú projektre is, ahol minden szolgáltatás vagy felhasználói történet egy kiadáshoz tartozik.
A koncepció egyszerű; a rendszer minden egyes jellemzőjéhez adja meg a jellemző nevét, rövid leírását és azt, hogy melyik teljesíthető lesz a szolgáltatás követelményének.
Funkció | Leírás | Szállítható |
---|---|---|
Költségvetés és megtérülés
A költségvetés és a megtérülés valószínűleg a vezetők legfontosabb része. Mindannyian arra törekszenek, hogy megtudják, mennyibe kerül nekik a rendszer, vagy mekkora hatással lesz ez a projekt az osztályuk költségvetésére. Ez különösen igaz, ha a projekt a pénzügyi év elején nem szerepelt a Capex-ben.
Néha, még akkor is, ha a projektet költségvetésbe szánták, egy másik projekt elsőbbséget élvezhet a jelenlegi javaslattal szemben, és a forrásokat el lehet terelni a tervezett forrásból. A végrehajtás és a menedzsment szintjén gyakran zajlik egy kis politikai csetepaté a projekt elindítása érdekében, és gyakran vannak olyan előre nem látható körülmények, amelyek elsőbbséget élvezhetnek a tervezett projektekkel szemben.
Tehát készüljön fel arra, hogy együttműködjön az érdekeltekkel a tárgyalások elősegítésében, vagy legyen rugalmas és proaktív, hogy működőképes megoldást nyújtson, ha a költségvetési helyzet félreáll. Jobb, ha a projektet a költségvetési valósághoz igazítják, sőt a rendszer eredményeit hosszabb időre terjeszti, vagy akár el is távolodik a projekttől. Sokkal jobb, ha elsétálunk, mint ha egy projekten dolgoztam volna, és nem kapnánk fizetést, és bírósághoz kellene folyamodnunk az úton.
Az alábbi táblázat csak demonstrációs célokat szolgál, hogy képet adjon a költségvetés elkészítéséről. Természetesen hozzá kell adnia saját sorokat, hogy illeszkedjenek a projektjéhez. Ezután kitölti a mennyiséget, az egységárat, a mértékegységet és a sorösszeget. Ezután vegye fel a sor végösszegét az alján.
Ez jó képet nyújt a szoftverprojekt végrehajtásához szükséges beruházásokról. A legtöbb vezető, akikkel dolgoztam, szeretné tudni, hogy mi lesz a megtérülési ráta, vagy mennyibe fog kerülni ez a projekt az idő múlásával, ezért egy egyszerű ROI-értéket és egy CAGR-t is felveszek, vagy saját becsléseim és feltételezéseim alapján (amelyeket meg kell adni magyarázat) a javaslatban, vagy a benyújtott becslések és feltételezések felhasználásával.
Projekt elem | Összeg | Egységár | UoM | Teljes |
---|---|---|---|---|
Szoftver licenc |
||||
Gép (ek) |
||||
Kiszolgálói licenc |
||||
Adatbázis licenc |
||||
Fejlesztési tanácsadó |
||||
Projektmenedzsment |
||||
Képzés (idő + anyagok) |
ROI
A ROI kiszámítása nagyon egyszerű. Alapvetően a képlet nyereség - a költség és a költség osztva. A képletet az alábbiakban adjuk meg:
Az egyetlen hátrány, hogy a számítás nem veszi figyelembe az időt, ezért a megtérülés jó rövid távú projektek esetén, de hosszabb távú projekteknél általában CAGR-t (Összetett éves növekedési ráta) tartalmazok. A CAGR-számítás az adott év bizonyos pontjainak megtérülése.
CAGR
A CAGR képlet:
Az első rész a végérték felosztása a kezdő értékkel. Az eredményt 1 értékre emelik a befektetett évek száma alatt. A kapott értéket kivonjuk 1-gyel.
Előnyök
Ebben a részben felsorolja azokat az üzleti előnyöket, amelyeket a szoftver projekt nyújt. Felsorolással felsorolhatók mindaddig, amíg összhangban vannak az általános célokkal. Bemutatniuk kell, hogy a szoftver vagy rendszer hogyan fogja növelni az üzleti értéket.
Dióhéjban: a javasolt megoldás hogyan segíti a vállalkozást abban, hogy sikeresebb legyen és elérje kijelentési céljait? Használjon pozitív szavakat és mondatokat.
Korlátok
A kényszerek szakasznak fel kell sorolnia minden olyan kézzelfogható és megfoghatatlan korlátozást, amelyet előre láthat. Ez vonatkozhat a berendezésekre, valamilyen szezonalitási tényezőre, például egy leállított gyárra, amelyet a legtöbb üzem évente legalább egyszer megtesz.
Próbálja meg kicsinyíteni a megszorításokat, vagy festeni őket minimálisnak. Ne sorolja fel a szoftver vagy a rendszer negatív vonatkozásait, és ha kell, akkor adjon megkerülő megoldásokat.
© 2012 Kevin Languedoc