Jak přeměnit projekt na výrobek

-- 18.10.11 21:00

Proměnit projekt IT ve výrobě v úspěšný výrobek vyžaduje úsilí navíc. Níže uvádíme několik doporučení, jak to provést. (Uvažujete-li o programovém vybavení, které vypadá nebo se chová jako projekt, raději se poohlédněte po jiném.)

Jedním ze způsobů, jak vytvořit skvělý produkt pro IT ve výrobě, je vyjít ze skvělého projektu pro IT ve výrobě. Dokončení úspěšného projektu bývá velmi uspokojující. Koneční uživatelé jsou spokojeni, rozumí systému a vše bylo dokončeno včas a v rámci rozpočtu. Mnoho systémových integrátorů, konečných uživatelů a dodavatelů chce učinit další krok a proměnit výsledky projektu na výsledný programový produkt – výrobek. Při tomto kroku je důležité nepodcenit úsilí navíc potřebné k přeměně úspěšného projektu na úspěšný výrobek. Transformace projektu na výrobek vyžaduje, aby práce provedené na jednom pracovišti s　velmi specifickými požadavky, místními odhodlanými uživateli a implementačním týmem odborníků mohly být replikovány na mnoha jiných pracovištích s široce se lišícími požadavky, omezeným odhodláním konečného uživatele a omezenými nebo žádnými zdroji odborníků, kteří by pomohli při instalaci, kontrole a uvedení do provozu.

Projekty mívají dobře definovaný a ověřitelný rozsah pokrývající specifický problém nebo oblast. Výsledné produkty musejí pokrývat širokou škálu různorodých, avšak podobných problémů. Často je nutno požadavky rozšířit, což vede k revizi návrhu a přepracování projektového kódu. U projektů se často ponechává alespoň určitá část dokumentace u konečného uživatele, avšak jen s málo projekty se dodává kompletní soubor dokumentace, který běžně bývá součástí výrobku. Dodané výrobky mívají automatizovanou instalaci, kdežto instalace projektů bývá manuální. U projektů se často uplatňuje přístup typu „děláme to jen jednou, usnadňování nestojí za námahu“ anebo „je snadnější kroky pouze dokumentovat, než je automatizovat“. Výrobky mívají chybová hlášení s　doporučenými následnými akcemi. Tato chybová hlášení radí uživatelům, co musejí udělat, aby problém vyřešili.

Těmito akcemi může být náprava konfiguračních problémů, náprava zabezpečeného přístupu nebo kontaktování technické podpory. U většiny projektů jsou chybová hlášení nesrozumitelná a uživateli nepomáhají s　vyřešením problému. Chybová hlášení u projektů jsou často určena k tomu, aby pomáhala vývojářům při ladění, a nikoli uživatelům při nápravě problému. Dodávané výrobky obvykle nabízejí „bezpečná selhání“ (angl. graceful failures). Bezpečné selhání je takové, kdy systém nezamrzne, informace jsou uloženy pro pozdější ladění, systém může běžet v omezeném, ale stále použitelném režimu, uživateli se zobrazí zprávy doporučující kroky k nápravě problému a systém se může restartovat bez nutnosti zásahu uživatele. Výrobky jsou testovány v　mnoha prostředích, pokrývají širokou paletu použití a konfigurací, jsou zátěžově testovány pro stanovení mezí systému a jsou ověřovány v minimálních prostředích.

Projekty jsou často zkoušeny jen v　jednom prostředí s omezeným počtem konfigurací. Výrobky mívají technickou podporu uživatelů, zatímco u projektů dostanete telefonní čísla na vývojáře. Produkty obvykle obsahují příklady a po spuštění neuvidíte prázdnou obrazovku. Obsahují také dokumentaci, průvodce a příklady potřebné k počáteční konfiguraci systému. Výrobky při spuštění kontrolují použitelnost své konfigurace, aby se nedostaly do nefunkční situace. Produkty mají dobře napsaný a dobře zdokumentovaný kód. U projektů bývá obvykle jen stručná dokumentace ke kódu. Kvůli rozdílům mezi projekty a výrobky může být úsilí potřebné k transformaci projektového kódu na produkt 3- až 10krát větší než úsilí věnované původnímu projektu. Mnoho systémových integrátorů, konečných uživatelů a dodavatelů plně nedoceňuje tyto nároky na úsilí navíc a zbrkle nabízí projektový kód, jako by to byl hotový výrobek. Pokud přeměňujete projekt na výrobek, nezapomeňte na důležité rozdíly mezi nimi a počítejte s úsilím potřebným pro vývoj robustního konečného výrobku.

Dennis Brandl je prezident společnosti BR&L Consulting se sídlem v Cary v Severní Karolíně, www.brlconsulting.com. Jeho společnost je zaměřena na IT pro výrobu. Můžete jej kontaktovat na e-mailové adrese dbrandl@brlconsulting.com.