Jak napsat návrh vývoje softwaru

Jak napsat úspěšný návrh vývoje softwaru.

Kevin Languedoc

Účelem návrhu vývoje softwaru je poskytnout řešení, které bude čitelné podnikateli, takže je jednoduché a věcné; držte se co nejvíce od technických podmínek. Následující obrys lze použít jako takový k přípravě úspěšného návrhu vývoje softwaru. Je důležité mít na paměti, že lidé, kterým hodláte předložit návrh, nemají mnoho času na přečtení zdlouhavého dokumentu. Můžete si to vzít ode mě, během mých více než 20 let v oblasti informačních technologií jsem napsal stovky návrhů: podnikatelé chtějí jen tolik informací, aby jim umožnili učinit informované rozhodnutí.

Pokud odpovídáte na žádost o nabídku (RFP) a musíte respektovat určitý rozsah stránek, protože stránky jsou předtištěny nebo vás obsahové požadavky přinutí k vytvoření příliš dlouhého návrhu, zvažte použití shrnutí. níže jsem přidal část s popisem, jak ji připravit.

Délka návrhu

Viděl jsem šablony a diskuse, které obhajují návrhy, které běží na 50 nebo stránkách. Věřte mi, že po páté stránce ztratíte zájem manažera. Jakmile bude návrh přijat, budou návrhové dokumenty přirozeně podrobnější, protože budou určeny projektovému týmu a budou funkčními plány systému. To bude platit pro většinu klientů, ale (ano, vždy existuje, ale), pokud je návrh odpovědí na žádost o nabídku (RFP), musíte ji dodržovat. Vládní nebo vojenská agentura bude pravděpodobně mít přísné pokyny, jak připravit návrh vývoje softwaru, a může zahrnovat několik stránek (10, 20, 30, 50 nebo více) v závislosti na složitosti systému.Toto pravidlo stále platí pro velké organizace, které mohou mít proces formálního návrhu, zejména pokud jsou veřejnou společností a musí dodržovat jakékoli předpisy či normy Sarbannes-Oxley nebo ISO.

Shrnutí

Pokud má návrh více než 20 stránek, můžete zvážit poskytnutí shrnutí, které je jednostránkovým výběrem částí návrhu. Můžete dokonce poskytnout shrnutí ve formátu PowerPoint. Pokud plánujete použití shrnutí v prezentaci návrhu vývoje softwaru, předložte návrh pomocí shrnutí a výkonný ředitel může návrh přečíst později, například během obchodního letu.

Šablona

Následující obrys je ve skutečnosti dobrá šablona, kterou můžete použít k přípravě vlastního návrhu vývoje softwaru. Při přípravě návrhu vždy pamatuji na pravidlo výšky výtahu a vy byste měli také. Elevator Pitch v zásadě stanoví, že váš návrh by neměl být mnohem delší, než je čas potřebný k vyvezení výtahu z přízemí do nejvyššího patra budovy na vaší cestě k předložení návrhu.

Název projektu

S podtitulem nebo souhrnnými informacemi o návrhu

Návrh by měl mít název a pododdíl shrnující kontext návrhu softwaru. Rovněž uvedete název divize, služby, oddělení nebo organizace, pro kterou je projekt určen.

Pokud odpovídáte na žádost o nabídku (RFP), uveďte všechny informace, které jsou v žádosti o nabídku vyžadovány nebo uvedeny jako povinné. Také jsem viděl žádosti o nabídku, které požadují, abyste kromě názvu na první stránku vložili podpisy schválení, ale v tomto příkladu jsem dal podpisy na stránku s částí Změny.

Obsah

Na další stránce byste měli zahrnout obsah se seznamem hlavních částí návrhu. Volitelně můžete zahrnout čísla stránek, pokud návrh přesahuje pět stránek nebo pokud to požaduje RFP.

Schválení

Tato část je pro proces zásadní, ať už se jedná o odpověď na žádost o nabídku, nebo z této šablony nebo z jiného zdroje. Tato část dokumentuje potvrzení, že projekt je funkční, a poskytuje závaznou dohodu mezi různými členy projektu. Nikdy byste neměli zahájit projekt, dokud nezískáte všechny potřebné podpisy a nebudete mít závazek od projektanta a zúčastněných stran zahájit projekt. V opačném případě se můžete ocitnout ve vazbě, pokud je projekt zrušen nebo pokud se změní rozsah projektu nebo výsledky.

Se zavedenými schváleními je mnohem těžší provést změny v rozsahu a výsledcích, a pokud dojde ke sporům, bude mít podepsané schválení jasnou představu o tom, na čem bylo dohodnuto. Samozřejmě vždy existuje otázka výkladu.

Schválení by měla obsahovat jméno osoby, její titul, následovaný jejím podpisem a nakonec datum podpisu dokumentu.



název	Název / role	Podpis	datum

Změny

Sekce Změny poskytuje protokol všech změn, které byly provedeny nebo budou provedeny v dokumentu Návrh vývoje softwaru. Nezdokumentuje žádné změny rozsahu samotného projektu ani žádného jiného aspektu projektu. Sekce Změny by měla obsahovat minimálně jméno osoby provádějící změnu, datum změny a komentář nebo popis změny.



Autor	Datum změny	Popis nebo komentář

Glosář a zkratky

Seznam všech termínů nebo zkratek a jejich definic. Nepředpokládejte, že každý zná význam pojmů nebo zkratek, zvláště pokud plánujete využití externích konzultantů a tyto pojmy jsou interní a jsou zakomponovány do vaší podnikové kultury a jazyka. Každá organizace má své vlastní žargon a zkratky. Je v pořádku je použít v návrhu, pokud jsou řádně zdokumentovány.

Pokud se také používají nějaké akronymy specifické pro dané odvětví, je třeba je také zdokumentovat, aby každý jasně pochopil význam termínů a akronymů a formuloval lepší interpretace.

Následující akronymy pocházejí z aktuální šablony. Jsou uvedeny jako příklad.

Žádost o nabídku
ROI: Návratnost investic
CAGR: Složená roční míra růstu
IT: Informační technologie
CAPEX: Kapitálové výdaje
MJ: měrná jednotka

Rozsah

Rozsah návrhu by měl na vysoké úrovni nastínit celkové podrobnosti projektu, co je zahrnuto a vyloučeno. Rozsah by měl poskytovat celkový popis, délku projektu, hlavní cíle. Co se snažíte dosáhnout touto investicí do navrhovaného projektu vývoje softwaru.

Časová osa

Tato část bude obsahovat počáteční a konečné datum (odhad). Nezapomeňte vytvořit vyrovnávací paměť a naplánovat nepředvídané události. Dobrým pravidlem je přidat na časovou osu vyrovnávací paměť 75%.

Členové projektu

Mezi členy projektu by měli patřit vítěz projektu a zúčastněné strany. Šampiónem je obvykle manažer, který řídí celkový projekt a rozpočet. Zúčastněnou stranou je obvykle interní promotér nebo sponzor. Mohou také být šampiónem v závislosti na rozsahu projektu a nebo typu organizace, která požaduje návrh vývoje softwaru. Zbývající seznam obsahuje typické role, které lidé v projektu vykonávají.

Následující text je uveden pouze jako příklad typu rolí, které mohou mít účastníci projektu. Někteří lidé mohou mít více než jednu roli. V závislosti na rozsahu projektu může být seznam členů projektu velmi zdlouhavý nebo stejná osoba může převzít různé role.

Seznam by měl obsahovat veškeré informace, které řádně identifikují osobu, její roli v projektu, jak se k ní dostat a jaké jsou její odpovědnosti. Můžete uvést další informace v závislosti na požadavcích na RFP nebo typu organizace, se kterou budete pracovat, a jejich interních zásadách.



Člen týmu	Role	Kontaktní informace	Odpovědnosti
	Mistr
	Zúčastněná strana
	Projektový manažer
	Architekt
	Analytik
	Vývojář

Obchodní příležitost

Většina šablon, které jsou k dispozici, definuje tuto část jako „Obchodní problém“ nebo „Prohlášení o problému“, často jsem se však setkal s vedoucími pracovníky, kteří se urážejí tím, že mají problém ve své obchodní jednotce nebo procesu. Vzpomínám si, jak mě jedna ředitelka doslova vyhodila ze své kanceláře, protože jsem uvedl, že opravujeme proces, a ona mi řekla, že to nebude někdo z IT (informační technologie), kdo bude diktovat, jestli má problém s jejími procesy nebo ne.

Při formulaci tedy buďte opatrní. Vždy používám výraz „obchodní příležitost“, protože nakonec je návrh reakcí na obchodní příležitost vylepšit proces, podpořit proces nebo automatizovat proces



Obchodní prohlášení	Jak systém uspokojí požadavek
Ovlivněný obchodní proces, situace, problém	Jak navrhované řešení zlepší cílovou oblast podnikání
Jaká potřeba se řeší	Jak se k tomu postaví současný projekt

Přehled řešení

V části Přehled řešení můžete poskytnout podrobný přehled o systému. Tento přehled může obsahovat navigační mapu, pokud je návrh pro web nebo webovou aplikaci. Můžete také zahrnout vývojový diagram toku procesu. Můžete také zahrnout diagram hlavních komponent systému.

Cílem je poskytnout osobě, která rozhoduje, dostatek informací, aby pochopil, o jaký systém jde, jak bude fungovat a jaké jsou hlavní stavební kameny. Jedná se samozřejmě pouze o vodítko, protože organizace může mít formální formát, který definuje, co budete muset v návrhu poskytnout, zejména pokud jednáte s vládní agenturou nebo ministerstvem obrany.

Funkce a výstupy

Tato část poskytuje mechanismus k mapování vlastností navrhovaného systému na hmatatelné plnění. Také jsem viděl tuto část, která obsahuje časový odhad pro dokončení dodávky, ale nerad ji používám, protože je příliš omezující a vytváří vazbu. Při práci na projektu se nemusí výstupy přesně shodovat tak, jak je uvedeno, takže pokud jste se na papíře zavázali dokončit dodávku do určité doby, odstraní nebo sníží jakoukoli pružnost později, když projekt skutečně děláte.

Další sloupec, který lze přidat, je Release, ke kterému patří Dodávka. To je užitečné, pokud bude projekt doručen po delší dobu a bude vydáno několik verzí. To platí také pro agilní nebo štíhlé projekty, kde každá funkce nebo uživatelský příběh patří k vydání.

Koncept je jednoduchý; u každé funkce v systému uveďte její název, krátký popis a to, která dodávka splní požadavek dané funkce.



Vlastnosti	Popis	Doručitelný

Rozpočet a návratnost investic

Rozpočet a návratnost investic jsou pravděpodobně nejdůležitější částí některých vedoucích pracovníků. Všichni touží vědět, kolik je systém bude stát nebo jaký dopad bude mít tento projekt na rozpočet jejich oddělení. To platí zejména v případě, že projekt nebyl zahrnut do Capexu na začátku fiskálního roku.

Někdy, i když byl projekt v rozpočtu, může mít před aktuálním návrhem přednost jiný projekt a prostředky mohou být odkloněny od zamýšleného zdroje. Na výkonné a manažerské úrovni často probíhá trochu politických hádek, aby se projekt dostal do praxe, a často existují nepředvídané okolnosti, které mohou mít přednost před plánovanými projekty.

Buďte tedy připraveni spolupracovat se zúčastněnými stranami na pomoci s vyjednáváním nebo buďte flexibilní a proaktivní a poskytněte funkční řešení, pokud situace v rozpočtu půjde stranou. Je lepší přizpůsobit projekt rozpočtové realitě, a to i rozložením výstupů systému na delší časové období nebo dokonce od projektu odejít. Je mnohem lepší odejít, než pracovat na projektu, nedostávat zaplaceno a uchýlit se k soudním sporům.

Následující tabulka slouží pouze pro demonstrační účely a poskytuje představu o tom, jak připravit rozpočet. Přirozeně budete muset přidat vlastní řádkové položky, aby se vešly do vašeho projektu. Poté vyplníte množství, jednotkovou cenu, měrnou jednotku a celkovou částku řádkové položky. Poté ve spodní části srovnejte součty řádkových položek.

To poskytne dobrý obraz o investici potřebné k provedení softwarového projektu. Většina vedoucích pracovníků, se kterými jsem pracoval, ráda vědí, jaká bude míra návratnosti nebo kolik bude tento projekt v průběhu času stát, takže zahrnuji také jednoduchou hodnotu ROI a CAGR, buď s využitím vlastních odhadů a předpokladů (které musí být vysvětleno) v návrhu nebo s využitím poskytnutých odhadů a předpokladů.



Položka projektu	Množství	Jednotková cena	UoM	Celkový
Softwarová licence
Stroje
Licence serveru
Licence databáze
Poradce pro rozvoj
Projektový management
Školení (čas + materiály)

ROI

Výpočet ROI je velmi snadný. Vzorec je v zásadě zisk - náklady dělené náklady. Vzorec je uveden níže:

Jedinou nevýhodou je, že výpočet nebere v úvahu čas, takže návratnost investic je dobrá pro krátkodobé projekty, ale pro dlouhodobější projekt obecně používám CAGR (Compound Annual Growth Rate). Výpočet CAGR je meziroční míra návratnosti pro určitý časový okamžik.

CAGR

Vzorec CAGR je:

První částí je rozdělení konečné hodnoty počáteční hodnotou. Výsledek se zvýší na 1 v počtu investovaných let. Výsledná hodnota se odečte o 1.

Výhody

V této části uvádíme seznam obchodních výhod, které softwarový projekt poskytne. Mohou být uvedeny ve formátu odrážek, pokud odpovídají celkovým cílům. Měli by předvést, jak software nebo systém zvýší obchodní hodnotu.

Stručně řečeno, jak navrhované řešení pomůže podnikům, aby byly úspěšnější a dosáhly svých cílů? Používejte pozitivní slova a věty.

Omezení

V části omezení by měla být uvedena veškerá hmotná a nehmotná omezení, která můžete předvídat. To se může týkat zařízení, některých sezónních faktorů, jako je odstavení výrobního závodu, což většina závodů například používá alespoň jednou ročně.

Pokuste se omezit omezení nebo je namalovat jako minimální. Neuvádějte seznam negativních aspektů softwaru nebo systému, nebo pokud je to nutné, poskytněte řešení, která lze obejít.