• Nebyly nalezeny žádné výsledky

Dušan Chlapek (2005) říká: „Projekt IS/ICT definujeme jako projekt vyvolaný za účelem pořízení nebo adaptace (změny) IS/ICT, směřující k dosažení předem určených cílů.

Komplexnost projektů IS/ICT je dána skutečností, že projekty směřují k realizaci svých cílů ve vyvíjejícím se světě uživatelských cílů, požadavků, průběžně zlepšovaných věcných (business) procesů, rychle se vyvíjejících technologií a integrujících se systémů.“

Základní vlastnosti IS/ICT projektů jsou dle Dušana Chlapka (2005) následující:

1. Unikátnost. Projekt je vždy jednorázový proces. Projekt je vždy neopakovatelný a určuje ho mnoho charakteristických rysů a podmínek, ve kterých se projekt realizuje.

2. Potřeba přesně určených cílů a výstupů projektu.

3. Potřeba realizovat projekt ve stanoveném čase. Potřeba tedy přesného plánování a vytváření rozkladu prací na dílčí činnosti a úkoly.

Václav Řepa, aj. (2006) v rámci kapitoly, Řízení projektů vývoje IS, píše: „úspěch procesu vývoje informačního systému je přímo závislý nejenom na porozumění obsahu prací v jednotlivých fázích a krocích, ale z celé své jedné poloviny i na způsobu řízení

tohoto procesu. Vývoj informačního systému, či jeho části je vždy projektem – jedná se o akci se zjevně definovatelným cílem, časově omezenou a neopakovanou a se zjevně stanoveným a omezeným rozpočtem a se striktními požadavky na kvalitu (z hlediska

18

uživatele je nepřípustné si představovat vývoj IS jako nějakou permanentní a nikdy neukončenou rutinní činnost s nejistým výsledkem - vždy musí být zřetelný okamžik, od kterého bude informační systém sloužit a musí být záruka, že skutečně sloužit bude). To jsou všechno aspekty, které je nutno v postupu projektu řídit.“

Obrázek 1 Životní cyklus IS vs. životní cyklus projektu (Řepa, 2006)

Z Obrázku 1 je patrné, že životní cyklus a jím daná metodika vývoje IS a metodika řízení projektu, které musí platit současně, jsou na druhou stranu zcela různé. Je tedy v procesu vývoje IS vždy důležité vědět, co náleží projektu a co metodice postupu. Je nutné

rozlišovat mezi věcnými činnostmi projektu a činnostmi jejich řízení. (Řepa, 2006) V rámci IT projektů nás zajímají postřehy z oblasti projektů takové, jejichž součástí je i vývoj softwaru, případně jeho záměna či konsolidace stávajícího řešení. Analýza, návrh, design, vývoj a testování nového SW produktu je často hlavní náplní cílů, které jsou požadované k dosažení milníků v rámci takových projektů. (Bělka, 2007, s. 7) Je nutné podotknout, že poměrně malé procento IT projektů je dokončeno se

stoprocentním úspěchem. Často totiž na ramenou projektového manažera IT projektu stojí břímě toho, najít rovnováhu mezi vylučujícími si cíli a riziky, ale zároveň se očekává v maximální míře uspokojit požadavky zákazníka, ať už se jedná o koncového uživatele daného vyvíjeného produktu, nebo uživatele dodávaného řešení v rámci společnosti, případně dodávané řešení pro Business oblast v rámci společnosti. (Bělka, 2007, s. 7) Obecně se za úspěšný projekt považuje takový projekt, v rámci něhož byly dodány

všechny výstupy kvalitně, v rámci daného rozpočtu a včas. Metriky a nápomocné nástroje jsou používány projektovým manažerem k tomu, aby se v projektu lépe zorientoval a dokázal projekt řídit produktivně a nečerpat kapacity svých zdrojů duplicitně. Tyto metriky a nástroje mohou mít číselný, slovní či subjektivní charakter, ale obecně se za základy metrik projektového řízení považují:

• Kvalitu – zabezpečení maximální použitelnosti výstupů

• Kvantitu – vytvoření předem dohodnutého množství výstupů

19

• Termín – předání výstupů v souladu se stanoveným termínem

• Rozpočet – vytvoření výstupů v požadovaném rozpočtu (Bělka, 2007, s. 8)

„Správná aplikace výše uvedených metrik pomáhá manažerovi zhodnotit aktuální stav projektu. Navíc slouží i pro poskytování informací nadřízeným i pro prezentaci průběhu projektu zákazníkovi. Kvalitu výstupu nelze ověřovat až na konci projektu, ale je nutno ji provádět průběžně.“ (Bělka, 2007, s. 8)

I když se zdá, že IT projekty mají své specifické vlastnosti a požadavky, stále lze na

všechny takové projekty pohlížet očima metodiky. Metodika udává směr a řád jakémukoliv procesu a bez ní projekty postrádají právě tento zmiňovaný důležitý řád. Veškeré činnosti v průběhu procesu vývoje nového SW, případně tedy jeho konsolidace či inovace, popisuje právě metodika a určuje jednotlivé fáze procesu a výstupy, které definují úspěšný progres a následně ukončení projektu. Správně uchopena metodika není jen byrokratická záležitost, ale umožňuje průběžnou kontrolu SW vývoje z hlediska dodržení kvantity, kvality, termínu a rozpočtu projektu. (Bělka, 2007, s. 8)

Jelikož ke každému projektu lze přistupovat mnoha způsoby, je několik různých metodik, kterými projekt lze řídit. Každý projekt se zaměřuje a udává prioritu různým částem, tudíž nelze použit jednoznačně definovanou metodiku pro všechna řízení projektů. Metodika se odvíjí především od toho, na co se v rámci projektu zaměřuje a udává správný směr, zároveň pomáhá řídit projekt takovým způsobem, aby nebylo odbočeno od cíle projektu.

(Lukaševič, 2018, s. 16)

Primárně však všechny metodiky, bez ohledu na to, jaký problém řeší, musejí obsahovat minimálně následující skupiny problémů:

• rozklad jednotlivých rizik daného projektu

• určení organizačního rozdělení projektu a definování jednotlivých rolí a vzájemných vztahů

• životní cyklus projektu a rozdělení projektu do dílčích částí k lepší kontrole

• určení odpovědnosti organizačním strukturám případně rolím

• dodržování a stanovení standardů projektu (Lukaševič, 2018, s. 16, cit. podle Doucek, 2006, s. 34)

„Jednou z nejznámějších metodik vývoje softwarových aplikací je RUP. RUP poskytuje flexibilní rámec pro metodický popis organizační struktury a pracovních procesů a postupů v dané organizaci. Je to komplexní sada konceptů, postupů, nástrojů a technik používaných v softwarovém inženýrství. Softwarový vývoj stojí podle RUP na čtyřech základních pilířích – pracovníci, činnosti, pracovní procesy a výstupy. Definuje také šest nejlepších praktik softwarového vývoje – iterativní vývoj softwaru, správu a řízení požadavků, použití komponentové architektury, vizuální modelování, průběžné ověřování kvality a řízení změn.“ (Bělka, 2007, s. 8)

Existuje však spoustu dalších metodik, se kterými se můžeme v rámci projektového řízení setkat, ať už se jedná o mezinárodní normy, které mají za úkol především upravovat životní cykly ICT projektů a zároveň navrhovat základní sady projektových procesů. Nebo

20

se jedná o obecně přijímané standardy projektového řízení, které jsou nápomocné k porozumění projektového řízení. Mezi nejznámější patří PMBOK, dále pak standard IPMA a Prince2. (Lukaševič, 2018, s. 17, cit. podle Oškrdal, Doucek, 2014, s. 98) Projekty informačních technologií, stejně jako projekty z jiných sfér lidské činnosti, například stavebnictví nebo průmyslu, mají svá specifika. Pro oblast informačních technologií mezi ně patří zejména povaha informačních projektů, vlastnosti členů projektových týmů a odlišnost používaných technologií. (Arendáč, 2016, s. 7, cit. podle Schwalbe, 2011, s. 77)

Vzdělání členů projektového týmu je naprosto různorodá. Jedná se o členy různých technických znalostí, ale i o členy, kteří absolvovali ekonomické, matematické či humanitární obory. Tito členové mají důležitý kontext v podobě odlišného pohledu na informační projekty a tím i jakési neobvyklé myšlení pro jiné členy s technickými znalostmi. Tento aspekt napomáhá k různorodosti členů projektu a tím i k progresivitě samotného projektu. Pro projektové týmy je charakteristické i vysoká specializace členů týmu. Často musejí být technické role úzce zaměřené na jakousi specializaci, například programátoři bývají úzce zaměřeni na jednoznačné programovací jazyky. Problém nastává i v tom, že v projektových týmech, zaměřených na IT, dochází k poměrně vysoké fluktuaci členů, jelikož techničtí specialisté v dnešní době nacházejí rozsáhlé využití a uplatnění v mnoha jiných společnostech a často nezastaví ani to, že se jedná o déle trvající projekt.

(Arendáč, 2016, s. 7)

Informační projekty bývají velmi různorodé. Některé se týkají pouze několika lidí instalujících nakoupený HW či SW, jiné zahrnují stovky lidí, analyzujících několik

obchodních procesů organizace a následně společně vyvíjejí nový SW za účelem dosažení podnikových cílů. (Arendáč, 2016, s. 7, cit. podle Schwalbe, 2011, s. 77)

Informační projekty dnes podporují nejrůznější typy průmyslu a obchodu. Řízení informačního projektu v animačním oddělení filmové společnosti bude od projektového manažera a členů týmu vyžadovat jiné znalosti než projekt, jehož cílem bude zlepšit výběr daní či instalovat komunikační infrastrukturu v některé ze zemí třetího světa. (Arendáč, 2016, s. 7, cit. podle Schwalbe, 2011, s. 77)

Rychlé se rozrůstající oblast technologií má za následek další problém, který se vztahuje k IT projektům a jedná se o jakési ohrožení podobných projektů. Často delší IT projekty musejí nést riziko toho, že po ukončení takového projektu a vlastně i po dosažení všech stanovených cílů na začátku, nemusí být projekt a dodaná funkčnost zcela uspokojivá.

Příčinou této situace je to, že rychlost proměny používaných technologií nutí společnost ke zkracování životního cyklu produktu a služeb a služba, která se vyvíjí příliš dlouho nemusí být již na trhu natolik potřebná a inovativní, jak se tomu na začátku projektu zdálo. Tato situace nutí vyvíjet a distribuovat tyto produkty a služby mnohem rychleji, než tomu bylo v minulosti. (Arendáč, 2016, s. 7)