}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Úprava a nasazení software pro podporu firemní spolupráce D IPLOMOVÁ PRÁCE
Bc. Jan Mayer
Brno, jaro 2013
Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: Mgr. Jiˇrí Koláˇr ii
Podˇekování Chtˇel bych podˇekovat vedoucímu práce Mgr. Jiˇrímu Koláˇrovi za pomoc a rady pˇri vzniku této práce. Dále bych chtˇel podˇekovat všem zamˇestnancum ˚ firmy inQool a.s., pˇredevším Mgr. Petrovi Halmovi, Mgr. Tiborovi Szabovi a Mgr. Matúšovi Zamborskému za pˇríležitost spolupracovat s nimi pˇri vytváˇrení své diplomové práce. V neposlední rˇ adˇe bych chtˇel podˇekovat celé své rodinˇe za neustálou podporu.
iii
Shrnutí Cílem práce je najít vhodné softwarové rˇ ešení pro zaˇcínající IT firmy. Nejprve se proto práce vˇenuje zpusob ˚ um ˚ vedení vývojových týmu. ˚ Následnˇe se v práci projednávají potˇreby tˇechto firem a stanovíme základní podmínky, které by mˇel software pro IT spoleˇcnosti splnovat. ˇ Pro praktické využití software nejprve zanalyzujeme konkrétní IT firmu inQool a.s. a poté navrhneme a formalizujeme procesy, podle kterých se budou ve firmˇe provádˇet nejˇcastˇejší cˇ innosti. Pro modelové cˇ innosti pak stanovíme metriky, podle kterých budeme hodnotit software a najdeme optimální rˇ ešení dle obecnˇe stanovených podmínek i požadavku˚ firmy. Následnˇe softwarové rˇ ešení upravíme pro docílení maximální efektivity a nasadíme pro praktické užití do firmy inQool. Na závˇer zhodnotíme výsledky, které naše práce pˇrinesla.
iv
Klíˇcová slova Projektový management, ERP, agilní metody, Scrum, Redmine, Alfresco, Trello, OpenERP, BPMN
v
Obsah 1
2
3
4
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Struktura práce . . . . . . . . . . . . . . . . . . . . . . . Duležité ˚ pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Malý a stˇrední podnik . . . . . . . . . . . . . . . . . . . 2.2 Open source . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Software as a Service . . . . . . . . . . . . . . . . . . . . 2.4 ERP systém . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 CRM systém . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Systém pro správu verzí . . . . . . . . . . . . . . . . . . 2.7 Lightweight Directory Access Protocol . . . . . . . . . . 2.8 Business Process Modeling . . . . . . . . . . . . . . . . . 2.9 Representational State Transfer . . . . . . . . . . . . . . 2.10 Informaˇcní systém . . . . . . . . . . . . . . . . . . . . . Práce vývojáˇrských týmu˚ . . . . . . . . . . . . . . . . . . . . 3.1 Code and Fix . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Vodopádový model . . . . . . . . . . . . . . . . . . . . . 3.3 Spirálový model . . . . . . . . . . . . . . . . . . . . . . . 3.4 Agilní metody . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Kritiky agilní metodologie . . . . . . . . . . . . . 3.4.2 Základní typy agilních technik . . . . . . . . . . 3.5 Motivace pracovníku˚ . . . . . . . . . . . . . . . . . . . . 3.5.1 Command and Control . . . . . . . . . . . . . . 3.5.2 Motivace založená na odmˇenách . . . . . . . . . 3.5.3 Identity Management Method . . . . . . . . . . 3.5.4 Management 3.0 . . . . . . . . . . . . . . . . . . 3.6 Práce týmu˚ v kontextu softwarových nástroju˚ . . . . . . Pilíˇre menších a stˇrednˇe velkých spoleˇcností . . . . . . . . . 4.1 Firma z pohledu klasického projektového managementu
4 4 5 6 7 7 7 8 9 9 10 10 10 11 11 12 13 13 13 14 15 16 22 22 23 23 23 25 30 30 1
5
4.1.1 Co? . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Jak? . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Kdy? . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4 S kým? . . . . . . . . . . . . . . . . . . . . . . . . 4.1.5 Za kolik? . . . . . . . . . . . . . . . . . . . . . . . 4.2 Stavební kameny IS . . . . . . . . . . . . . . . . . . . . . 4.2.1 Obecné vlastnosti IS . . . . . . . . . . . . . . . . 4.3 Správa projektu˚ . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Duležité ˚ vlastnosti software pro správu projektu˚ 4.3.2 Vhodné vlastnosti software pro správu projektu˚ 4.4 Správa dokumentu˚ . . . . . . . . . . . . . . . . . . . . . 4.4.1 Document Management System (DMS) . . . . . 4.4.2 Duležité ˚ vlastnosti software pro správu dokumentu˚ . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Vhodné vlastnosti software pro správu dokumentu˚ . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Správa kontaktu˚ . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Duležité ˚ vlastnosti software pro správu kontaktu˚ 4.5.2 Vhodné vlastnosti software pro správu kontaktu˚ 4.6 Pˇrechod firmy na nový systém . . . . . . . . . . . . . . 4.6.1 Vyvolání vˇedomí naléhavosti . . . . . . . . . . . 4.6.2 Sestavení koalice schopné prosadit a realizovat zmˇeny . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Vytvoˇrení vize . . . . . . . . . . . . . . . . . . . . 4.6.4 Komunikace transformaˇcní vize . . . . . . . . . 4.6.5 Odbourání pˇrekážek . . . . . . . . . . . . . . . . 4.6.6 Vytváˇrení krátkodobých vítˇezství . . . . . . . . 4.6.7 Využití výsledku˚ a podpora krátkých zmˇen . . . 4.6.8 Zakotvení nových pˇrístupu˚ do firemní kultury . Analýza ve firmˇe . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Firemní struktura . . . . . . . . . . . . . . . . . . . . . . 5.2 Systém pˇridˇelování HW . . . . . . . . . . . . . . . . . . 5.3 Souˇcasnˇe používané programy . . . . . . . . . . . . . . 5.3.1 Organizace a plánování . . . . . . . . . . . . . . 5.3.2 Správa stráveného cˇ asu zamˇestnancu˚ . . . . . . 5.3.3 Ukládání dokumentu˚ . . . . . . . . . . . . . . . 5.3.4 Komunikace s klienty . . . . . . . . . . . . . . . 5.4 Chybˇející prvky a vlastnosti . . . . . . . . . . . . . . . .
30 31 31 31 31 32 32 33 33 34 35 35 36 36 36 37 37 37 38 38 38 38 39 39 39 39 41 41 43 43 43 44 45 47 48 2
5.5 Návrh nových procesu˚ . . . . . . . . . . . Stanovení kritérií pro hodnocení software . . 6.1 Kritéria pro první fázi testování . . . . . . 6.1.1 Kritéria pro správu projektu˚ . . . . 6.1.2 Kritéria pro správu kontaktu˚ . . . 6.1.3 Kritéria pro správu dokumentu˚ . . 6.1.4 Cena rˇ ešení . . . . . . . . . . . . . 6.2 Pˇresnˇejší kritéria pro druhou fázi . . . . . 6.3 Stanovení metriky pro porovnání zlepšení 7 Zhodnocení dostupných produktu˚ . . . . . . . 7.1 První fáze . . . . . . . . . . . . . . . . . . 7.1.1 Systémy pro správu projektu˚ . . . 7.1.2 Systémy pro správu souboru˚ . . . 7.1.3 Systémy pro správu kontaktu˚ . . . 7.2 Druhá fáze . . . . . . . . . . . . . . . . . . 7.2.1 Obchodní scénáˇr . . . . . . . . . . 7.2.2 Projektový scénáˇr . . . . . . . . . . 7.2.3 Scénáˇr po ukládání dokumentu˚ . . Hodnocení scénáˇre . . . . . . . . . 7.3 Výsledky hodnocení . . . . . . . . . . . . 8 Implementace a nasazení systému . . . . . . . 8.1 Spojení Trello a Redmine . . . . . . . . . . 8.2 Použité komponenty . . . . . . . . . . . . 8.2.1 Ruby . . . . . . . . . . . . . . . . . 8.2.2 Redmine . . . . . . . . . . . . . . . 8.2.3 Redis . . . . . . . . . . . . . . . . . 8.2.4 Trello API . . . . . . . . . . . . . . 8.2.5 Redmine API . . . . . . . . . . . . 8.3 Implementace skriptu . . . . . . . . . . . 8.4 Nasazení software . . . . . . . . . . . . . . 8.5 Pˇrechod firmy inQool na nový systém . . 8.6 Srovnání oproti pˇredchozímu rˇ ešení . . . 8.7 Návrhy do budoucna . . . . . . . . . . . . 8.8 Další firmy . . . . . . . . . . . . . . . . . . 9 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . A Obsah CD . . . . . . . . . . . . . . . . . . . . . 6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49 55 55 56 56 56 56 57 59 60 60 60 76 78 82 82 83 84 86 86 87 87 88 88 88 89 90 90 91 91 91 93 93 94 95 104
3
Kapitola 1
Úvod 1.1
Motivace
Posledních nˇekolik let mužeme ˚ považovat za dobu, ve které vzniklo velké množství technologických firem. Významná cˇ ást tˇechto spoleˇcností jsou firmy, které se zabývají vývojem software. Prumˇ ˚ ernˇe každé tˇri mˇesíce vzniká technologická spoleˇcnost, která cˇ asem dosahuje hodnoty miliardy dolaru˚ [31]. Pˇritom všechny tyto firmy na zaˇcátku svého života rˇ eší podobné problémy, které se týkají organizace práce svých pˇribývajících zamˇestnancu, ˚ ukládání a distribuce znalostí, sdílení dokumentu˚ a komunikace s klienty. Protože jsou tyto firmy velice specificky omezeny, musí takovéto softwarové rˇ ešení splnovat ˇ rˇ adu podmínek. Vˇetšinou se jedná o omezení finanˇcní a personální. Proto je potˇreba pˇri hledání firemní softwarové páteˇre klást duraz ˚ na nízkou cenu, rychlé nasazení, jednoduchou škálovatelnost a hlavnˇe efektivní rˇ ešení každodenních rutinních úkolu, ˚ které zamˇestnance nesmí odvádˇet od jejich hlavní práce. Pˇri vedení firmy bývají zamˇestnanci zaneprázdnˇeni naplnováním ˇ cílu˚ firmy, proto je pro nˇe vˇetšinou velmi obtížné uvolnit si dost cˇ asu, aby provedli širokou analýzu trhu. Toto muže ˚ cˇ asto vést k tomu, že pˇri výbˇeru softwarového rˇ ešení nezváží všechny zmínˇené promˇenné. Stejnˇe tak zaˇcínajícím firmám chybí cˇ as na formální definování procesu˚ a jejich optimalizaci, která cˇ asto znamená i úpravu použitého software. Vˇetšina mladých softwarových firem tak stojí pˇred rozhodnutím, zda-li vˇenovat znaˇcné prostˇredky na duslednou ˚ analýzu, nebo se spokojit s rˇ ešením, které nemusí být pro firmu optimální. 4
1. Ú VOD
1.2
Cíle
Práce si klade za cíl definovat potˇreby malých a stˇredních IT firem z pohledu informaˇcních systému˚ a následné nalézt vhodný softwarový produkt, který by tyto potˇreby maximálnˇe naplnoval. ˇ Nalezený software pak bude nasazen do firmy inQool a.s., která svými vlasnostmi odpovídá definici našich cílových firem. Pˇrínosem praktické cˇ ásti práce bude tedy jak nasazení nového softwarového systému a nových pracovních procesu˚ do firmy inQool a.s., tak i popis úpravy a zavedení softwarového rˇ ešení, aby mohlo být jednoduše nasaditelné do dalších firem z naší cílové skupiny. Abychom mohli považovat práci za úspˇešnou, musí být nasazené rˇ ešení pro firmu inQool a.s. efektivnˇejší a výhodnˇejší než rˇ ešení soucˇ asné.
5
1. Ú VOD
1.3
Struktura práce
V prvních dvou kapitolách klademe duraz ˚ na teorii. Budeme se vˇenovat stanovení základních pojmu˚ a zpusobu ˚ práce vývojáˇrských týmu˚ v posledních letech s durazem ˚ na agilní zpusoby ˚ rˇ ízení projektu. ˚ Ve tˇretí kapitole pak vyvodíme závˇery, které jsou duležité ˚ ke stanovení metriky, s jejíž pomocí budeme pomˇerˇ ovat vhodnost software. Probereme zde také operativu softwarových firem z pohledu informaˇcního systému a knowledge managementu. Ve cˇ tvrté kapitole si vysvˇetlíme klady a zápory souˇcasných rˇ ešení ve firmˇe inQool a.s. a zmapujeme aktuální workflow. Pˇri výbˇeru a úpravˇe software musíme brát v potaz souˇcasný zpusob ˚ práce, který ve firmˇe vznikl zcela organicky. Kdyby pˇrechod na nové rˇ ešení pro zamˇestnance znamenal zásadní zmˇenu, kterou by nevnímali jako zmˇenu k lepšímu, mohli by software odmítnout. V páté kapitole stanovíme metriku, podle které budeme urˇcovat vhodnost rˇ ešení. V kapitole s cˇ íslem šest projdeme všechny možnosti, které jsou na trhu k dispozici, a vybereme optimální rˇ ešení pro firmu inQool a.s. s pˇrihlédnutím na všechny dˇríve zmínˇené aspekty. Sedmá kapitola obsahuje hodnocení dostupných softwarových produktu˚ podle stanovených kritérií a postup pˇri výbˇeru vhodného rˇ ešení. V závˇereˇcné cˇ ásti práce pak popíšeme proces úpravy a nasazení softwarového rˇ ešení do firmy inQool a.s. a zhodnotíme výsledky a úspˇešnost, s jakou jsme splnili stanovené cíle práce.
6
Kapitola 2
Duležité ˚ pojmy Pˇred tím, než se dostaneme k samotné problematice, je potˇreba pˇresnˇeji definovat, co si má cˇ tenáˇr pˇredstavit pod nˇekterými základními pojmy, které jsou pro pochopení celé práce nezbytné.
2.1
Malý a stˇrední podnik
ˇ ˇ Analýzy Ceského Statistického Úˇradu (CSÚ, [38]) dokládají, že tyto ˇ podniky tvoˇrí významnou cˇ ást tržní ekonomiky v Ceské republice. V roce 2006 byl podíl malých a stˇredních podniku˚ na celkovém poˇctu podniku˚ roven 99,85% a jejich podíl na výkonech celé podnikatelské ˇ sféry cˇ inil 51,45%. Dle dokumentu vypracovaného CSÚ dˇelíme podniky podle poˇctu zamˇestnancu˚ do 3 základních kategorií: drobné (1 - 9 zamˇestnancu), ˚ malé (10 - 49 zamˇestnancu) ˚ a stˇrední (50 - 250 zamˇestnancu). ˚ V rámci Evropské unie se pro kategorizaci velikosti podniku˚ používají kromˇe poˇctu zamˇestnancu˚ také jiná mˇerˇ ítka (napˇr. vlastnická ˇ struktura a další). Pro naše požadavky je dˇelení podle CSÚ dostaˇcující.
2.2
Open source
Puvod ˚ open source mužeme ˚ datovat už od roku 1985, kdy R. Stallman založil Free Software Foundation. Na tu pozdˇeji v roce 1998 navázala Open Source Foundation, podle níž muže ˚ být software oznacˇ en jako open source pouze pokud splnuje ˇ 10 stanovených podmínek [37]. Tyto podmínky ve zkratce popisují, že software musí mít 7
˚ 2. D ULEŽITÉ POJMY
k dispozici cˇ itelný zdrojový kód, který musí být volnˇe distribuovatelný a v žádné své verzi se nesmí stát tajným. Jakým zpusobem ˚ je možné software a jeho zdrojový kód distribuovat, je stanovené v licenci, se kterou je software vydáván. Mezi nejznámˇejší open-source licence patˇrí tyto: General Public License (GPL) byla vytvoˇrená R. Stallmanem pro projekt GNU. Bˇežný uživatel muže ˚ zdrojový kód zkoumat a upravovat bez potˇreby zveˇrejnˇení, ale odvozené práce si musí zachovat puvodní ˚ svobody. V souˇcasné dobˇe je nejnovˇejší tˇretí verze této licence. Lesser General Public License (LGPL) je volnˇejší úpravou GPL, která autorovi navíc dovoluje spojovat software z otevˇreného i uzavˇreného zdrojového kódu. Affero General Public License (AGPL) vznikla pro potˇreby používat software na síti jako SaaS. Aktuálnˇe je AGPL ve tˇretí verzi. Apache License narozdíl od GPL patˇrí k permisivním licencím. To znamená, že dovoluje, aby byl software postavený na zdrojovém kódu distribuován s jinou licencí. Aktuálnˇe je tato licence ve verzi 2.0. Berkley Source Distribution License (BSDL) je licencí s pomˇernˇe krátkým textem. Primárnˇe se v nˇem snaží chránit autora a nezakazuje jakoukoliv úpravu a distribuci kódu. Massachusetts Institute of Technology License (MITL) pˇredstavuje nejvolnˇejší licenci z našeho výˇctu. Prakticky jen zbavuje autora veškeré zodpovˇednosti. Mozila Public Licence vznikla primárnˇe pro potˇreby distribuce software Mozilla. Pˇredstavuje kompromis mezi BSD a GPL licencí [16].
2.3
Software as a Service
Software jako služba je bˇežnˇe používaný cˇ eský pˇreklad pro tuto anglickou formulaci. Software as a service (SaaS, [13]) si lze jednoduše 8
˚ 2. D ULEŽITÉ POJMY
pˇredstavit jako softwarovou službu, které je placená svými pravidelnými odbˇerateli (tedy zákazníky). SaaS je definovaná tˇremi základními faktory: •
Odbˇeratel si nekupuje žádný software.
•
Odbˇeratel si neinstaluje žádný produkt na svuj ˚ poˇcítaˇc (ani na domácí poˇcítaˇc, ani na server). Pro tento bod jsou definované výjimky v pˇrípadˇe, že si uživatel musí nainstalovat nˇejakou jednoduchou aplikaci, která se serverem komunikuje, ale není jádrem služby.
•
Služba je opakovanˇe placena v daných intervalech. Toto platí, pokud má služba placený model, existují ale i SaaS, které jsou financovány napˇríklad z reklamního systému a pro zákazníky jsou zdarma.
2.4
ERP systém
Anglická zkratka ERP reprezentuje (Enterprise Resource Plannig, [46]), což mužeme ˚ volnˇe pˇreložit jako plánování podnikových zdroju. ˚ Ve zkratce jde o software, jehož úkolem je pokrýt plánování a rˇ ízení všech klíˇcových interních firemních procesu˚ (tedy celou transformaci zdroju˚ na výstupy). Systém pokrývá procesy na všech úrovních od strategie až po operativu.
2.5
CRM systém
Customer relationship management (CRM, [48]) je proces shromažd’ování, zpracování a využití informací o zákaznících, který je podporovaný databázovou technologií. Umožnuje ˇ tak pochopit a pˇredvídat potˇreby zákazníku˚ a podporuje oboustranou komunikaci mezi nimi a firmou. Jako CRM systém je oznaˇcována právˇe softwarová, hardwarová a popˇrípadˇe i personální cˇ ást firmy, která tento úkol naplnuje. ˇ 9
˚ 2. D ULEŽITÉ POJMY
2.6
Systém pro správu verzí
Programátoˇri pˇri vývoji programu vytváˇrí soubory se zdrojovým kódem. Systémy pro správu verzí rˇ eší problémy, kdy je potˇreba, aby na zdrojových kódech spolupracovalo souˇcasnˇe více programátoru. ˚ Systémy mají na starosti sluˇcování ruzných ˚ verzí souboru, ˚ integraci, zálohování všech zmˇen a další. Problém správy verzí rˇ eší programy jako Concurrent Verison System (CVS), Subversion (SVN) nebo GIT. Rozbor práce verzovacích systému˚ a jejich nasazování v kontextu kontinuální integrace je nad rámec této publikace. Více informací k tomuto tématu se nachází v seznamu literatury [18].
2.7
Lightweight Directory Access Protocol
Jedná se o rozšíˇrený protokol (LDAP, [6]), který popisuje správu adresáˇrových služeb pˇres sít’. Adresáˇrové služby zpravidla ukládají velmi komplexní hierarchické struktury záznamu. ˚ Jako jednoduchý pˇríklad pro využití protokolu mužeme ˚ uvažovat aplikaci, která potˇrebuje autentizovat uživatele. Pˇri pˇripojování uživatele se aplikace pomocí LDAP pˇripojí k adresáˇrové službˇe a dotáže se na všechny záznamy o uživatelském úˇctu.
2.8
Business Process Modeling
Modelování business procesu˚ je podle Ryan K. L. Ko (BPM, [25]) definované jako podpora business procesu˚ použitím metod, technik a software pro návrh, kontrolu a analýzu operaˇcních procesu, ˚ jež zahrnují lidi, organizace, dokumenty a další zdroje informací. Standard BPMN (Business Process Model and Notation, [35]) pˇredstavuje unifikovaný zpusob ˚ jak graficky znázornit business procesy. Puvodním ˚ autorem této notace je Business Process Management Initiative (BPMI), která se v roce 2005 stala souˇcástí Object Management Group. Specifikace je aktuálnˇe ve verzi 2.0 a volnˇe dostupná na webu [35]. 10
˚ 2. D ULEŽITÉ POJMY
2.9
Representational State Transfer
První zmínka o této technologii (REST, [42]) pochází již z roku 2000. REST pˇredstavuje architekturu, ve které komunikuje server s klienty pomocí bezstavových pˇripojení. Na serveru je uložen pouze dlouhodobý stav a klient se muže ˚ k jednotlivým prostˇredkum ˚ pˇripojit pouze pomocí pˇresnˇe definované sady indetifikátoru˚ prostˇredku. ˚ V kontextu webu hovoˇríme o tak zvaných Uniform Resource Identifiers (URI, [42]). V praxi se jedná o urˇcení prostˇredku pomocí URI a zavolání jedné ze cˇ tyˇr akcí, které s prostˇredkem mužeme ˚ provést. •
GET stáhne ze serveru aktuální verzi prostˇredku.
•
POST odešle na server data o prostˇredku. Server si je uloží jako nový záznam.
•
PUT odešle na server upravená data dˇríve stáhnutého prostˇredku. Server si uloží novou verzi.
•
DELETE smaže prostˇredek uložený na serveru.
2.10 Informaˇcní systém Pojem informaˇcní systém (IS, [10]) je velice obecné oznaˇcení pro soubor technologických metod a prostˇredku˚ pro sbˇer, pˇrenos a uchování dat. V našem kontextu budeme o IS hovoˇrit jako o kompletním softwarovém rˇ ešení pro uložení, správu a vhodné poskytování veškerých elektronických dat, které jsou významné pro fungování firmy.
11
Kapitola 3
Práce vývojáˇrských týmu˚ Celá spoleˇcnost se vlivem digitální kultury transformuje. Nejedná se pouze o zmˇenu zpusobu, ˚ kterým komunikujeme a ukládáme informace, jedná se hlavnˇe o transformaci toho, jak pˇremýšlíme, žijeme a pracujeme. Posledních nˇekolik let je motivace zamˇestnancu˚ podrobena systematickému vˇedeckému zkoumání. Zamˇestnavatelé se vlivem poznatku˚ na toto téma postupnˇe orientují nejen na uspokojování poˇreb svých zákazníku, ˚ ale i na uspokojování potˇreb svých zamˇestnancu. ˚ Do popˇredí se zaˇcíná dostávat myšlenka, že jen spokojený zamˇestnanec muže ˚ pomáhat k vytváˇrení spokojených zákazníku˚ [34]. Zámˇerem této publikace není detailnˇe vyjmenovat všechny postupy a techniky, kterými se vydávají spoleˇcnosti pˇri vycházení vstˇríc svým zamˇestnancum. ˚ Nicménˇe stojíme pˇred výbˇerem a nasazením informaˇcního systému do moderní spoleˇcnosti. Pro správné uchopení problému musíme tedy zohlednit i faktory urˇcující komfort zamˇestnancu. ˚ Prvním z nich je pˇrívˇetivost programu pro zamˇestnance. Práci s programem by mˇel zamˇestnanec brát – když ne pˇrímo jako zábavnou – tak asponˇ ne jako frustrující. Ruku v ruce s tímto hlediskem jde i efektivita aplikace. Zamˇestnanci musí nabízet rychlé a pˇrehledné prostˇredí pro každodenní práci. V neposlední rˇ adˇe musí systém i v plné šíˇri podporovat zpusoby ˚ práce, které moderní spoleˇcnosti považují za standard. Podívejme se tedy na historický vývoj bˇežnˇe používaných technik práce vývojáˇrských týmu˚ a poté se zamˇerˇ me na agilní metodiky, které jsou v posledních nˇekolika letech pˇrejímány softwarovými spoleˇcnostmi [2]. V našem pˇrehledu se nebudeme pˇríliš orientovat na dopad agilních technik na zvýšení motivace zamˇestnancu˚ ani na kvalitu výsledného produktu. Tato srovnání byla daleko detailnˇeji 12
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
popsána v jiných pracích, jež jsou k nalezení v seznamu literatury.
3.1
Code and Fix
Jedná se o velice jednoduchý intuitivní zpusob ˚ práce (Code and Fix, [33]). Volný pˇreklad by mohl znít jako „programování a opravy“. V zásadˇe se jedná o systém s nulovým plánováním. Programátoˇri vyvíjejí software a pokud v prubˇ ˚ ehu vývoje narazí na chyby nebo problémy, zaˇrídí jejch nápravu. Po opravˇe chyb pokraˇcují opˇet v dalším vývoji. Nevýhodou tohoto systému je minimální návrh architektury projektu. Software vyvinutý touto metodou je obtížnˇe udržovatelný, a proto je použitelný pouze pro jednoduché projekty.
3.2
Vodopádový model
Pˇredchozí model je pˇrirozeným kontrastem k tomuto modelu (Waterfall, [41]). Celý vodopádový model je založený na silném plánování. Dopˇredu se naplánují fáze vývoje produktu i s odhady cˇ asových nároˇcností a bˇehem vývoje produktu se projektový manažer snaží dodržet vytvoˇrený plán. Fáze vodopádového modelu se mohou lišit jak do poˇctu, tak do pojmenování. V zásadˇe ale musí být dodrženo, že se vývoj muže ˚ pˇresunout do další fáze až poté, kdy je souˇcasná fáze plnˇe dokonˇcena. Stejnˇe jako vodopád nemuže ˚ téci nahoru, je cesta do pˇredchozí fáze velice obtížnˇe realizovatelná. Další charakteristickou vlastností vodopádového modelu je absence komunikace se zákazníkem. Zákazník dodá své požadavky a po dokonˇcení vývoje je mu pˇredán hotový produkt. Vodopádový model se mnohokrát ukázal jako ne zcela vhodný pro vývoj software, mimo jiné právˇe z duvodu, ˚ že se požadavky zákazníka neustále vyvíjejí a mˇení [12].
3.3
Spirálový model
Bˇehem osmdesátých let vývojáˇri experimentovali s ruznými ˚ alternativami k vodopádovému modelu. Na oblibˇe zaˇcaly získávat in13
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Obrázek 3.1: Vodopádový model vývoje software krementální a iterativní pˇrístupy. Inkrementální pˇrístupy se vyznacˇ ují pravidelným vytváˇrením a uvolnováním ˇ fungujícího kódu po malých cˇ ástech. Iterativní pˇrístup pak do plánu˚ zahrnuje i nabírání zpˇetné vazby od zákazníku˚ a odhaduje cˇ as potˇrebný k její analýze a implementaci (Spiral model, [12]). V roce 1986 došlo ke zveˇrejnˇení Spirálového modelu pro vývoj software. V tomto modelu je viditelný jak vodopádový pˇrístup, tak i pˇrístup iterativní. Mužeme ˚ v nˇem také najít silnou inspiraci v Demingovˇe cyklu (PDCA, [32]). Software pˇri aplikování spirálového modelu v principu neustále prochází cˇ tyˇrmi fázemi. Nejprve urˇcíme cíle, alternativy a omezení. Následnˇe alternativy vyhodnotíme a vyvodíme rizika, poté dojde k samotnému vývoji s ovˇerˇ ováním a nakonec plánujeme další fáze.
3.4
Agilní metody
V únoru roku 2001 skupina vývojáˇru˚ kladoucích duraz ˚ na rychlý a efektivní vývoj softwaru položila základy agilnímu vývoji pomocí sepsání „Agile manifesto“ [15]. Agilní princip navrhuje vývoj ve 14
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
formˇe po sobˇe jdoucích cyklu, ˚ kdy každý další si bere pouˇcení z cyklu˚ pˇredchozích. Protože si autoˇri velmi zakládali na jednoduchosti návrhu, samotné Agile manifesto v originále sestává z reprezentativních 68 slov. Dále je pak rozvedeno do 12 principu, ˚ kterými by se mˇel vývoj rˇ ídit. Od samého základu klade agilní metodologie duraz ˚ na pˇrímou a pravidelnou komunikaci lidí. At’ se jedná o komunikaci v rámci týmu nebo o komunikaci se zákazníkem. Pˇrímá komunikace totiž, na rozdíl od psaní dlouhé dokumentace a dalších formalit, znaˇcnˇe urychluje a zpˇresnuje ˇ vývoj. V další rˇ adˇe bere agilní manifest zmˇenu zadání jako nˇeco pˇrirozeného a vítaného. Zmˇeny se pˇrirozenˇe stávají a nemá jakýkoliv význam proti nim bojovat. Tímto se staví do pˇrímé konfrontace s vodopádovým modelem. Od roku 2001 prošel agilní vývoj rˇ adou zkoušek a byl rozveden do rozliˇcných smˇeru. ˚ Jádro celé filozofie však zustává ˚ stále atraktivní a firem, jež na agilní vývoj pˇrechází, stále pˇribývá.
3.4.1 Kritiky agilní metodologie Po více než deseti letech od zformulování manifestu upozornují ˇ i samotní zastánci agilních technik na jeho nedostatky a navrhují možné úpravy. Mužeme ˚ zmínit ku pˇríkladu Toma Gilba, který ve své práci (Value-Driven Developlment Principles and Values, [20]) zminuje ˇ deset dalších bodu, ˚ které jsou ve dvanácti principech Agile manifesto bud’ nedotažené nebo opomenuté. Obecnˇe se snaží upozornit spíše na to, že Agile manifesto mluví pouze o samotném vývoji a nikoliv o businessu, který by mˇel být vyvíjeným softwarem podporován. I další body Gilbovy kritiky manifest spíše rozšiˇrují, než že by ho od základu˚ boˇrily, proto se v našem pˇrehledu budeme držet puvodního ˚ znˇení manifestu. Nejlépe totiž vystihuje metodologii, podle které by se mˇel provádˇet celý vývoj softwaru, a tudíž i filozofii, které by se mˇely používané nástroje podˇrídit. 15
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
3.4.2 Základní typy agilních technik Scrum je nejznámˇejší a obecnˇe nejpoužívanˇejší agilní metodou (Scrum, [2]). Je možno jej aplikovat v malých i stˇrednˇe velkých týmech. (Vˇetší týmy jsou obecnˇe nevyhovující pro agilní pˇrístup.) V základní podobˇe Scrumu pro malé týmy mužeme ˚ rozdˇelit tˇri základní role. Du˚ ležité je upozornˇení, že se jedná o dynamické role, nikoliv o pevné pracovní pozice. Proto nˇekdo, kdo zastává jednu roli v týmu A, muže ˚ zastávat jinou roli v týmu B. Stejnˇe tak Scrum nezakazuje zmˇenu rolí za bˇehu, staví se však proti pˇretˇežování rolí - tedy proti tomu, aby lidé v rámci jednoho týmu zastávali nˇekolik rolí zároven. ˇ Product Owner zastupuje zákazníka (dle anglické terminologie je zákazník stakeholder). Tuto roli musí zastávat cˇ len týmu, který je se zákazníkem v kontaktu, zná pˇresnˇe jeho požadavky a je si vˇedom pˇridané hodnoty, kterou pro nˇej produkt má pˇredstavovat. Muže ˚ pak pˇresnˇe formulovat User Stories (budou popsány dále), kontrolovat výstupy dˇríve než jsou pˇredvedeny zákazníkovi a pˇri jakékoliv nejasnosti v zadání rozhodovat sám nebo zákazníka rychle kontaktovat. Scrum Master naopak rˇ eší požadavky a problémy samotného týmu. Organizuje pravidelná jednání a zastává na nich pozici mediátora. Stará se také o vhodné zázemí cˇ lenu˚ týmu a pracuje na odstranˇení jakékoliv pˇrekážky, která ostatním cˇ lenum ˚ brání v práci. Není vedoucím týmu, pouze vytváˇrí bariéru mezi týmem a rušivými vlivy. Také dohlíží na dodržování Scrum metodiky. V žádném pˇrípadˇe se nejedná o manažera týmu. Team Members neboli zbývající cˇ lenové týmu jsou ti, na kterých stojí správné a vˇcasné doruˇcení produktu. Z našeho pohledu IT firmy se jedná o vývojáˇre, grafiky analytiky a další. Doporuˇcený poˇcet cˇ lenu˚ týmu je 3 až 9. Scrum mluví o samoorganizujícím týmu, takže žádné další role není potˇreba pˇresnˇe pˇriˇrazovat, nebot’ vykrystalizují samy. 16
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Kromˇe rolí definuje Scrum i další pojmy, kterým je potˇreba porozumˇet pro správné pochopení a nasazení techniky. V následném popisu si proto zárovenˇ projdeme i další pojmy, které metodologie definuje, abychom mˇeli pˇrehled kompletní. User Stories popisují požadavky na funkcionalitu programu. Na zaˇcátku vývoje je potˇreba získat od zákazníka zadání projektu. Tým toto zadání zanalyzuje a pokusí se ho rozdˇelit na jednotlivé atomické problémy. Tyto problémy oznaˇcuje Scrum jako User Stories. Každé User Story pˇriˇradí cˇ lenové týmu odhadovanou složitost. Protože je každý tým a každý projekt hodnˇe specifický, Scrum striktnˇe zakazuje odhad v hodinách. Doporuˇcuje odhad inspirovaný velikostmi triˇcek. Dostáváme tedy vzestupný seznam: XS, S, M, L, XL, XXL a tak dále. Bˇehem prvních nˇekolika iterací bude Scrum Master schopen pˇriˇradit pˇresnˇejší cˇ asovou nároˇcnost k jednotlivým úkolum. ˚ Product Backlog je seznamem všech analyzovaných User Stories. I tento seznam není pouze statickým plánem. V prubˇ ˚ ehu vývoje se budou mˇenit požadavky zákazníka a muže ˚ docházet jak k mizení funkcí, které se cˇ asem ukázaly jako nepotˇrebné nebo zastaralé, tak i k pˇridávání jiných požadavku, ˚ které novˇe vyvstaly. Sprint je pˇredem stanovená cˇ asová perioda vývoje. Nˇekteré cˇ lánky popisující Scrum vˇenují zásadní význam nultému Sprintu (Sprint Zero), který obsahuje nastavení podmínek, úvodní analýzu a vytvorˇ ení prvního základního produktu. V oficiální knize The Scrum Guide [43] ale žádný takový význam prvnímu bˇehu pˇrikládán není, a proto budeme na všechny Sprinty pohlížet jako na rovnocenné. Délka každého Sprintu je v rámci projektu konstantní a metodologie doporuˇcuje stanovit délku od dvou do cˇ tyˇr týdnu˚ (dle povahy projektu). Plannig Meeting je úvodní poradou Sprintu, na které se vyberou User Stories z Product Backlogu a stanoví se ty, které budou implementovány bˇehem aktuálního Sprintu. Vyberou se takové úkoly, které jsou relevantní pro zákazníka a zárovenˇ jejichž souˇcet obtížností nepˇresahuje odhad, který je tým schopen za Sprint splnit. 17
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Sprint Backlog uchovává seznam User Stories rezervovaných pro aktuální Sprint. Každý cˇ len týmu si na sebe postupnˇe bere úkoly. Po dokonˇcení jednoho si vezme další a tak pokraˇcuje dokud Sprint neskonˇcí. Daily Scrum stanovuje denní operativu. Scrum doporuˇcuje provádˇet každé ráno schuzky ˚ ve stoje (Stand Up Meetings), na kterých si cˇ lenové rˇ eknou, co se jim povedlo za vˇcerejší den implementovat a jaké mají plány pro dnešní den. Na jednání se tedy zhodnotí, jestli tým stíhá cˇ asový plán, nebo jestli vývoji nˇeco stojí v cestˇe a je potˇreba pˇrekážku odstranit. Sprint Review je schuzka ˚ vedená na závˇer Sprintu. Zde je prezentováno, cˇ eho se povedlo za Sprint dosáhnout. Tým a ostatní zúˇcastnˇené strany zde probírají jak výsledky Sprintu, tak i další postup ve vývoji. Sprint Retrospective je další schuzkou ˚ vedenou na závˇer Sprintu. Zde se úˇcastníci domlouvají, co by v pˇríštím Sprintu mohlo být provedeno lépe. Probírané je hlavnˇe fungování týmu s ohledem na komunikaci a procesy. Dynamic Systems Development Method Tato technika je taktéž rˇ azená mezi agilní metodiky, pˇrestože historicky sahá až do roku 1994 (DSDM, [22]). Metoda je filozofií podobná Scrumu. Hlavní rozdíl mezi DSDM a jinými technikami je stanovení cˇ asu jako fixní hodnoty a funkcionality programu jako hodnoty variabilní. Vˇetšina postupu˚ naopak bere zadání funkcionality jako výchozí konstantu, dle které je pak doba trvání vývoje odhadovaná. Na rozdíl od jiných agilních technik se DSDM soustˇredí spíše na rychlé dodání produktu s vysokou pˇridanou hodnotou než na samotnou práci týmu. DSDM popisuje techniky, podle kterých by mˇelo jít jednoduše stanovit, které vlastnosti projektu jsou nezbytné a budou implementované pˇrednostnˇe. Technika DSDM definuje až 10 rolí v týmu, tedy výraznˇe více než dˇríve pˇredstavený Scrum [14]. 18
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Obrázek 3.2: Model techniky Scrum 19
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Obrázek 3.3: Model Sprintu v rámcí techniky Scrum 20
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Kanban Tento systém vznikl jako souˇcást Toyota Production System v první polovinˇe 20. století (Kanban, [44]). Používá se dodnes, aby zabránil zbyteˇcné nadprodukci na výrobních linkách. Jeho hlavní pˇredností je cˇ istá vizuální forma, kterou pˇrevzali a pro své potˇreby upravili i vývojáˇri software. V principu se jedná o tabuli vertikálnˇe rozdˇelenou podle stavu, ˚ ve kterých se mohou jednotlivé úkoly nacházet. V IT se typicky jedná o stavy jako „to do“, „doing“, „done“, „released“. Jednotlivé stavy se samozˇrejmˇe liší podle požadavku˚ konkrétních projektu. ˚ Samotné úkoly se pak ve formˇe „lísteˇcku“ ˚ horizontálnˇe posunují mezi jednotlivými stavy. Toto znázornˇení úkolu˚ a stavu˚ vytváˇrí vizuální zpˇetnou vazbu o celkovém postupu projektu.
Obrázek 3.4: Ukázka kanban tabule, pˇrevzaté z [23] Spojením Agilního vývoje softwaru a kanbanu mužeme ˚ dle [23] hovoˇrit o paradigmatu „Agile kanban“. Na zaˇcátku každé iterace dojde k rozdˇelení všech potˇrebných funkcí na User Stories, které pak rozdˇelíme na jednotlivé úkoly a uložíme je do prvního sloupce. Tím se první sloupec našeho kanbanu stává Sprint Backlogem, ze kterého si programátoˇri berou úkoly, pracují na nich a po dokoncˇ ení je uvolnují. ˇ Když dojde k pˇredˇcasnému ukonˇcení všech úkolu˚ ve Sprintu, mužeme ˚ snadno pˇridat další úkoly tím, že rozdˇelíme další 21
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
User Story z Product Backlogu a úkoly pˇridáme na kanban. Pokud se naopak úkoly dokonˇcit nepodaˇrí, zustanou ˚ na kanbanu i po dokonˇcení Sprintu.
Obrázek 3.5: Hierarchie úkolu˚ v Agile kanban
3.5
Motivace pracovníku˚
Pohled na problém motivace pracovníku˚ se bˇehem existence lidstva dramaticky vyvíjel. Zpusob ˚ vedení lidí odrážel vždy atmosféru dané doby. Každá doba mˇela své „manažery“, kteˇrí vedli své lidi zpusoby, ˚ které vycházely z aktuálních potˇreb historických epoch. Pro zjednodušení mužeme ˚ vývoj rozdˇelit na cˇ tyˇri hlavní typy vedení lidí: 3.5.1 Command and Control Vedení založené na rozkazování a kontrole vyžaduje absolutní poslušnost a slepé následování úkolu, ˚ které od managementu pˇricházejí (C&C, [8]). V historickém vývoji hrálo významnou roli a dominovalo velké cˇ ásti institucí. Jedná se o striktní vojenský typ rˇ ízení, který naprosto odmítá kreativitu a samostatnost podˇrízených . V IT sektoru tento systém nemá prakticky žádné opodstatnˇení. 22
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
3.5.2 Motivace založená na odmˇenách Tato metoda je v dnešní dobˇe cˇ asto používaná pro zvýšení motivace pracovníku. ˚ Zamˇestnanci jsou více odmˇenováni, ˇ pakliže odvádí lepší výsledky. Celý systém stojí na myšlence, že nejvˇetší motivací pro zamˇestnance je cˇ íslo na jeho výplatní pásce. Bylo však opakovanˇe dokázáno, že pro vˇetšinu zamˇestnancu˚ není výše platu rozhodujícím motivaˇcním prvkem [8]. Navíc zamˇestnanec ztrácí zamˇerˇ ení na výsledný produkt a prosperitu firmy. Protože je pracovník postaven do role, kdy by se mˇel zajímat hlavnˇe o svoji odmˇenu, vytváˇrí tato metoda podhoubí pro podvádˇení. Nezáleží-li na samotném produktu, ale pouze na odmˇenˇe za nˇej, není zamˇestnanec tlaˇcen k tomu, aby dodal nejlepší a nejvhodnˇejší produkt, ale k tomu, aby odvedl takovou práci, která bude nejvíce odpovídat hodnoceným kritériím. Napˇríklad odmˇenování ˇ programátoru˚ podle poˇctu odevzdaných rˇ ádku˚ kódu nevede k psaní programu˚ rychleji, ale pouze k tomu, že programátoˇri vytváˇrí rozvláˇcný a dlouhý zdrojový kód. 3.5.3 Identity Management Method Zpusob ˚ motivace zamˇestnancu˚ pˇres sdílení spoleˇcného cíle. Jako pˇríklad efektivity této metody mužeme ˚ vzít spoleˇcnost Apple, která dává svým zamˇestnancum ˚ pocit, že vytváˇrí jedineˇcné produkty (IMM, [47]). Další duležitým ˚ prvkem pro úspˇešné zavedení této motivaˇcní metody jsou cˇ astá setkání zamˇestnancu˚ v mimopracovních podmínkách. Motivovat pracovníky pˇres IMM vˇetšinou vyžaduje, aby manažer dobˇre znal každého svého zamˇestnance a dokázal ho patˇriˇcnˇe smˇerovat a ocenovat. ˇ V neposlední rˇ adˇe musí spoleˇcnost pusobit ˚ dojmem, že svým zamˇestnancum ˚ plnˇe vˇerˇ í a nesmí pˇred nimi skrývat žádné duležité ˚ informace. 3.5.4 Management 3.0 Tento termín byl poprvé pˇredstaven ve stejnojmenné knížce od Jurgena Apella [5]. V této knížce se autor snaží podat ucelenˇejší pohled na celou problematiku motivování zamˇestnancu, ˚ než ji nabízí IMM. 23
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Autor tak popsal 7 bodu, ˚ které vzniknou spojením myšlenek Agilního manifestu s disciplínou managementu. Tyto body jsou: Nabudit lidi Nejvˇetší hodnota, kterou firma vlastní, jsou právˇe její zamˇestnanci, jejich znalosti a jejich touha a schopnost pracovat. Zplnomocnit týmy Agilní vývoj závisí na samoorganizujících týmech. Pouze tyto týmy totiž dokáží plnˇe využít potenciál motivovaných lidí. Nastavit bariéry I kreativní práci musí být správnˇe nastaveny bariéry. S žádnými nebo špatnˇe nastavenými mantinely muže ˚ dojít k chaosu nebo vyhoˇrení. Rozvíjet kompetence Jedním ze základních pˇredpokladu˚ pro úspˇešný agilní vývoj jsou právˇe cˇ lenové týmu, kteˇrí mají potˇrebné dovednosti. Proto se cˇ lenové i manažeˇri musí vzájemnˇe podporovat v dalším vzdˇelávání. Tuto myšlenku prezentuje i Peter Senge v knížce The Fifth Discipline, kde proces nikdy nekonˇcícího rozvíjení kompetencí oznaˇcuje pojmem Personal Mastery (Personal Mastery [45]). Zduraz ˚ nuje, ˇ že lidé, kteˇrí stavu Personal Mastery dosahují, rozvíjí nejen své pracovní, ale i osobní a spoleˇcenské schopnosti. Rust ˚ struktury Je mylnou pˇredstavou, že v agilních týmech není potˇreba žádná struktura. Bez struktury by došlo ke zmatku v zodpovˇednostech a komunikaci. Pro manažery je tedy žádoucí správnˇe nastavit strukturu týmu. 24
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Neustále vylepšovat Jedna z nejduležitˇ ˚ ejších vlastností, která pˇrínáší organizaci stabilitu, je neustálý vývoj a vylepšování. Uˇcení se novému a pouˇcení z vlastních chyb je i podle Petera Senge jednou z pˇeti hlavních disciplín, které vedou k úspˇešnému fungování uˇcících se organizací [45].
3.6
Práce týmu˚ v kontextu softwarových nástroju˚
Po uvedení do souˇcasné problematiky vývoje software a zpusobu ˚ vedení týmu˚ si mužeme ˚ položit otázku, co by mˇel splnovat ˇ nástroj pro vhodnou spolupráci samoorganizujících týmu. ˚ Vezmˇeme tedy 12 principu˚ Agilního manifestu jakožto základ, kterým se inspiruje vˇetšina souˇcasných softwarových spoleˇcností, a podívejme se, jak tyto zásady ovlivní pohled na informaˇcní systém [15]. „Naší nejvyšší prioritou je vyhovˇet zákazníkovi cˇ asným a prubˇ ˚ ežným dodáváním hodnotného softwaru.“ [15, princip 1] Tento bod manifestu je zamˇerˇ ený na schopnosti, disciplínu a správné odhady cˇ lenu˚ týmu. Musíme si tedy položit otázku - jak muže ˚ informaˇcní systém pomoci ke zvýšení tˇechto vlastností týmu? Pˇredevším práce v systému musí být velice rychlá aby programátory nezdržovala od samotného vývoje. Pokud by kvuli ˚ software docházelo ke zbyteˇcným prodlevám, cˇ lenové týmu by ho nevidˇeli jako výhodu a nechtˇeli by s ním pracovat. Z agilního pohledu by s programem mˇeli zamˇestnanci pracovat dobrovolnˇe, protože by si mˇeli uvˇedomovat výhody, které pˇrináší. Systém také musí zjednodušovat odhadování obtížnosti jednotlivých úkolu. ˚ Musí z nˇej být jednoduše a rychle patrné, kde se v rámci vývoje nacházíme, kolik stanovených úkolu˚ máme již za sebou a kolik jich zbývá. Stejnˇe tak musí systém každému zamˇestnanci umožnit ˇ zapsat, kolik cˇ asu na jednotlivých úkolech strávil. Tento záznam pˇrinese výhody jak pro samotný pˇrehled odhadu, ˚ tak pro pˇresnˇejší dokumentaci o odvedené práci pro zákazníka. Vizuální zpˇetnou vazbu a jednoduché mˇenˇení stavu úkolu˚ nejlépe splnují ˇ systémy, se kterými se dá pracovat ve stylu kanbanu. 25
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Pouhým pohledem je možno pˇresnˇe urˇcit, kde se projekt nachází a kdo na cˇ em pracuje. Mˇenit stavy úkolu˚ mužeme ˚ jednoduchým pˇretahováním mezi sloupci. „Vítáme zmˇeny v požadavcích, a to i v pozdˇejších fázích vývoje. Agilní procesy podporují zmˇeny vedoucí ke zvýšení konkurenceschopnosti zákazníka.“ [15, princip 2] Zmínˇená zásada agilního software stojí v opozici proti klasickému plánování a detailním Ganttovým grafum ˚ (Ganttuv ˚ graf, [40]). Nebudeme proto po software vyžadovat možnost plánovat tímto zpusobem ˚ dlouhodobˇe dopˇredu, naopak se zamˇerˇ íme na to, aby bylo vytváˇrení nových a úprava stávajících úkolu˚ co nejjednodušší a nejrychlejší. „Dodáváme fungující software v intervalech týdnu˚ až mˇesícu, ˚ s preferencí kratší periody.“ [15, princip 3] Tato zásada charakterizuje princip agilní práce. V našem informaˇcním systému musí být pro cˇ leny týmu jasnˇe odlišitelné úkoly náležící aktuální iteraci od úkolu, ˚ které tým už nezajímají, bud’ protože už byly splnˇeny, nebo protože se s jejich realizací poˇcítá až v budoucí iteraci. Úkoly hotové z minulých iterací mužeme ˚ v bˇežných programech bud’ archivovat nebo odfiltrovat díky stavu „hotovo“. Pokud ve zvoleném programu pro projektovou zprávu nebude možno odfiltrovat úkoly, které patˇri k budoucím iteracím, je možné tento požadavek rˇ ešit napˇríklad vytvoˇrením dvou projektu. ˚ Jeden pro seznam budoucích úkolu˚ a druhý pro projekt fyzický („Plán pro projekt web“, „Práce na projektu web“). „Lidé z byznysu a vývoje musí spolupracovat dennˇe po celou dobu projektu.“ [15, princip 4] Komunikace je velmi duležité ˚ téma. Je potˇreba organizovat pravidelné osobní schuze, ˚ komunikovat telefonicky, mailem, chatem. Požadavkem na software z tohoto pohledu je pˇredevším agregace kontaktu˚ jak na zákazníka, tak i na cˇ leny firmy (email, telefon, jabber). Dále by systém mohl napomáhat v jednoduché organizaci osobních schuzek ˚ a jako platforma pro zaznamenávání zápisu˚ ze schuzek ˚ s distribucí zúˇcastnˇeným stranám. 26
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
„Budujeme projekty kolem motivovaných jednotlivcu. ˚ Vytváˇríme jim prostˇredí, podporujeme jejich potˇreby a duvˇ ˚ erˇ ujeme, že odvedou dobrou práci.“ [15, princip 5] ˇ Bod pojednává o pˇríjemném prostˇredí. Casto zamˇestnanci upˇrednostnují ˇ svobodu v pohybu. Mnoho pracovníku˚ dnes pracuje z domu, z kaváren, z horských chat a dalších exotických míst. Náš informaˇcní systém tedy musí být stejnˇe pohodlnˇe pˇrístupný z jakékoliv lokace a jakéhokoliv zaˇrízení (poˇcítejme dnešní triádu tablet, telefon, notebook). Software na správu projektu˚ v podobˇe webové aplikace je v dnešní dobˇe logickou volbou. Velkou výhodou by pro informaˇcní systém bylo, kdyby nabízel i plnˇe funkˇcní mobilní aplikaci nebo alesponˇ responsive design web pro zjednodušení práce z mobilních zarˇ ízení (Responsive design, [30]). Dalším ukazatelem, který vytváˇrí pˇríjemné prostˇredí, je samotný vzhled a ovládání aplikace. Jedná se o jednu z nejduležitˇ ˚ ejsích charakteristik jakéhokoliv programu, a proto ji i zahrneme pˇri výbˇeru metriky pro hodnocení software. „Nejúˇcinnˇejším a nejefektnˇejším zpusobem ˚ sdˇelování informací vývojovému týmu z vnˇejšku i uvnitˇr nˇej je osobní konverzace.“ [15, princip 6] Jakým zpusobem ˚ spolu budou komunikovat jednotliví cˇ lenové týmu neovlivníme pˇrímo v software. Vývojáˇri cˇ asto pracují z ruzných ˚ míst po svˇetˇe. V nˇekterých nadnárodních spoleˇcnostech se spolupracovníci v životˇe nevidˇeli. Informaˇcní systém muže ˚ maximálnˇe zjednodušit organizování schuzek ˚ a uchovávat kontakty na všechny cˇ leny, aby spolu mohli pˇrípadnˇe komunikovat pˇrímou formou (telefonicky, domluvit si osobní schuzku). ˚ „Hlavním mˇerˇ ítkem pokroku je fungující software.“ [15, princip 7] Kvalita kódu je ovlivnˇena jak znalostmi a schopnostmi vývojáˇru, ˚ tak i jejich vzájemnou komunikací a vhodnou specifikací. Informaˇcní systém nemuže ˚ pˇrímo ovlivnit schopnosti vývojáˇru, ˚ mˇel by ale poskytnout vhodnou platformu pro komunikaci a ukládání znalostí. 27
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Systém wiki se v posledních letech tˇeší velké oblibˇe jako platforma pro spolupráci pˇri vytváˇrení dokumentu˚ (Wiki, [28]). Snadná editace obsahu a verzování plní všechny požadavky na ukládání znalostí. Informaˇcní systém by proto mˇel ke každému projektu umožnit ukládání správných postupu˚ a duležitých ˚ informací obdobným zpusobem, ˚ jako to umožnuje ˇ systém wiki. „Agilní procesy podporují udržitelný rozvoj. Sponzoˇri, vývojáˇri i uživatelé by mˇeli být schopni udržet stálé tempo trvale.“ [15, princip 8] Sponzoˇri, vývojáˇri i uživatelé cˇ asto pˇripomínkují programy v pru˚ bˇehu jejich používání bez ohledu na agilní metodiky, iterace nebo sprinty. Aby bylo dosaženo udržitelného vývoje a oprav chyb, musí být všechny tyto požadavky uchovávány a pravidelnˇe vyhodnocovány. Je potˇreba vyhodnotit všechny chyby – od tˇech, jež vznikají jen nepozorností uživatele, až po ty, jež jsou naopak chybami kritickými a které musí být opraveny s nejvyšší prioritou. Systém pro zaznamenávání chyb se v angliˇctinˇe nazývá „bug tracker“. Trh obsahuje širokou škálu komplexního softwaru pro zaznamenání chyb. Pro rychlý agilní vývoj nám však staˇcí jen jednoduchá metoda, nicménˇe pˇri stanovení metriky musíme brát v potaz i tento požadavek. „Jednoduchost – umˇení maximalizovat množství nevykonané práce – je klíˇcová.“ [15, princip 9] Toto pravidlo platí jak pro vývoj, tak i pro práci se software. Proto budeme hodnotit jeho minimalismus a jednoduchost. „Agilitu zvyšuje neustálá pozornost vˇenovaná technické výjimeˇcnosti a dobrému designu.“ [15, princip 10] Sebemotivace a touha po neustálem vzdˇelávání a vytváˇrení nejlepších výsledku˚ je nˇeco, co IS nemuže ˚ ovlivnit. Jedná se o vlastnosti vývojáˇru, ˚ které by pro nˇe mˇely být naprosto pˇrirozenými. „Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmu.“ ˚ [15, princip 11] 28
ˇ ˚ 3. P RÁCE VÝVOJÁ RSKÝCH TÝM U
Efektivní fungování samoorganizujícího se týmu je silnˇe ovlivnˇeno správným balancováním se sdˇelování informací. Každý cˇ len týmu musí vˇedˇet, které problémy je vhodné rˇ ešit se kterou skupinou lidí a které informace se vyplatí zaznamenat do databáze znalostí projektu. Pˇri nevhodném nakládání s informacemi muže ˚ dojít jak k zahlcení všech cˇ lenu˚ týmu (pˇri pˇrílišném dokumentování), tak i naopak k chybám vyplývajících z rozhodnutí uˇcinˇených bez kompletní znalosti problému. Typickou chybou tohoto druhu je známé „reinventig the weel“, kdy pracovníci vˇenují cˇ as rˇ ešení problému, který pˇred nimi už nˇekdo vyˇrešil. „Tým se pravidelnˇe zamýšlí nad tím, jak se stát efektivnˇejším, a následnˇe koriguje a pˇrizpusobuje ˚ své chování a zvyklosti.“ [15, princip 12] Pro udržení stability a stabilního rustu ˚ je tento bod velice významný. Je neustále opakován v ruzných ˚ pramenech, již dˇríve jsme zminovali ˇ Learning Organisation od Peter Sange [45] nebo Management 3.0 od Jurgena Apello [5]. Z pohledu IS by bylo vhodné, aby samotný tým pravidelnˇe reflektoval svou práci se systémem. Na základˇe nových poznatku˚ pak tým muže ˚ pˇrípadnˇe sám upravovat zdrojový kód programu, aby IS maximálnˇe odpovídal firemním procesum. ˚ Tohoto muže ˚ být docíleno, pakliže si systém firma vytvoˇrí sama nebo použije již funkˇcní open-source software.
29
Kapitola 4
Pilíˇre menších a stˇrednˇe velkých spoleˇcností Na závˇer minulé kapitoly jsme prošli prvky, které by software mˇel splnovat ˇ z pohledu agilní metodiky. Tu jsme zvolili, protože popisujeme koncept IS, který budou používat firmy, jež se zabývají vývojem software. V následující kapitole projdeme konkrétní vlastnosti, které by software mˇel splnovat. ˇ
4.1
Firma z pohledu klasického projektového managementu
Dle metodologie projektového rˇ ízení se mužeme ˚ na zakládání menší firmy nebo na její jednotlivé zakázky podívat jako na projekty [40]. Tato metodologie nám pˇri plánování projektu klade 5 základních otázek, na které bychom mˇeli pˇred zapoˇcetím práce získat odpovˇed’. Tˇechto 5 otázek projektového rˇ ízení bude mít samozˇrejmˇe pro každou firmu jiné odpovˇedi. Podíváme se, jak se tyto otázky prolínají s agilními technikami a jestli by mohl informaˇcní systém pomoci v hledání pˇríslušných odpovˇedí.
4.1.1 Co? At’ již budeme ve firmˇe vyvíjet zakázkový software nebo jen poskytovat SaaS, musíme vˇedˇet, co a pro koho vytváˇríme. IS by nám mˇel tedy poskytnout vhodné úložištˇe pro dokumenty, které definují zadání a úložištˇe kontaktu˚ na zákazníky a stakeholdery. 30
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
4.1.2 Jak? Klasický projektový management popisuje jako odpovˇed’ na tuto otázku rozdˇelení závislostí jednotlivých cˇ ástí projektu. Z pohledu Agilního vývoje jsou všechny duležité ˚ závislosti cˇ lenum ˚ týmu známé. Závislosti se promítají do poˇradí, podle kterého jsou jednotlivé úkoly seˇrazeny v Backlogu. Opˇet nám zde tedy vyvstává potˇreba definovat v rámci IS úkoly, které se budou rˇ ešit aktuálnˇe, a úkoly, které je potˇreba rˇ ešit v budoucnosti. 4.1.3 Kdy? Srovnáme-li, jak tuto otázku rˇ eší Scrum, a jak na ni odpovídá klasický PM, dostaneme se vždy k závˇeru, že je velmi duležité ˚ ukládat cˇ asové/obtížnostní nároˇcnosti úkolu˚ (popˇrípadˇe User Stories). Obecnˇe je mužeme ˚ pojmenovat jako odhady. Zda je budeme ukládat jako bezrozmˇerná cˇ ísla, nebo jako hodinové odhady, není z pohledu software duležité. ˚ 4.1.4 S kým? Klasický management se dívá na lidskou práci jako na zdroje. Agilní vývoj naopak staví samotné pracovníky více do popˇredí. Protože nás zajímá agilní práce, nechceme centralizovaný direktivní systém s pˇrirˇ azováním práce jednotlivým zdrojum. ˚ Zamˇestnanci musí mít možnost pˇrebírat si úkoly sami. Pro zlepšení psychologického dojmu z komunikace se skuteˇcnými lidmi by bylo vhodné, aby systém nabízel možnost pˇridat fotky ke každému zamˇestnanci. Zvýšila by se tím i podvˇedomá pˇrívˇetivost systému, zamˇestnanec by nemˇel pocit, že pracuje s pouhými daty. 4.1.5 Za kolik? Klasický PM dává odpovˇed’ na otázku „Za kolik?“ až na závˇer, kdy už máme odhadnuto, který pracovník bude na kterých úkolech pracovat. Pˇri aplikaci Scrumu se odhadu trvání úkolu˚ také využívá. Technika je ale navržena tak, aby chybné odhady mˇely co nejmenší negativní dopad na vývoj projektu. V klasickém PM mužou ˚ mít chybné odhady na úspˇech projektu fatální dopad. 31
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
IS muže ˚ pˇrispˇet k upˇresnˇení odhadu˚ tím, že nabídne možnost zapisovat odhadovanou délku trvání jednotlivých úkolu˚ a také každému zamˇestnanci umožní ukládat, kolik cˇ asu na úkolu strávil.
4.2
Stavební kameny IS
Definicí vˇetšiny požadavku, ˚ které jsou v dnešní dobˇe kladeny na IS menších IT firem, se pomalu dostáváme k modelu, jak by mˇel takovýto software skuteˇcnˇe vypadat a co všechno by mˇel splnovat. ˇ 4.2.1 Obecné vlastnosti IS Rozdˇelme požadavky pro systém na dvˇe skupiny. Na ty, které musí být v systému bezpodmíneˇcnˇe obsaženy, a na ty, jenž jsou pro firmu pˇrínosné, ale nejsou nezbytnˇe nutné. Navíc nˇekteré úkony oznaˇcíme za kritické. U tˇech budeme vyžadovat, aby je uživatelé mohli provádˇet s maximální efektivitou a minimální komplexností. Duležité ˚ vlastnosti software Z pˇredchozích kapitol vyplývá, že se v první rˇ adˇe musí jednat o online aplikaci pracující ve webovém prohlížeˇci, která bude nainstalovaná na firemních serverech. Tím bude splnˇena stálá dostupnost aplikace a firma zárovenˇ nebude muset spoléhat na uchování svých nejduležitˇ ˚ ejších dat u tˇretích stran. Tento požadavek zárovenˇ navádí i k tomu, abychom se vˇenovali pˇredevším open-source rˇ ešením, které si mužeme ˚ jak nainstalovat na vlastní server tak i dle vlastní potˇreby upravit. Optimální by bylo nalézt jeden systém, který bude splnovat ˇ všechny naše požadavky. Pakliže se ale nepodaˇrí najít celistvý systém, budeme muset vybrat více programu, ˚ mezi kterými bude jednoduché sdílet data a pˇrihlašovací údaje uživatelu˚ (zamˇestnancu˚ firmy). Vhodné vlastnosti software Bylo by vhodné, aby pro maximální komfort uživatelu˚ informaˇcní systém mˇel i aplikaci pro mobilní zaˇrízení (tablety, mobilní telefony) 32
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
nebo alesponˇ webovou aplikaci pro tato zaˇrízení vhodnˇe uzpusobe˚ nou.
4.3
Správa projektu˚
Jádrem celé firmy je informaˇcní systém, jádrem informaˇcního systému je správa projektu. ˚ Chod firmy se toˇcí kolem plánování, vytvárˇ ení a pˇriˇrazování úkolu. ˚ 4.3.1 Duležité ˚ vlastnosti software pro správu projektu˚ V první rˇ adˇe systém pro projektovou správu musí umožnovat ˇ kompletní správu uživatelských úˇctu˚ a práv. To znamená vytváˇrení nových uživatelu, ˚ správu hesel, správu kontaktu˚ na uživatele, nastavování pˇrístupových práv a nastavení viditelnosti objektu. ˚ Budeme pˇredpokládat nízkou fluktuaci zamˇestnancu, ˚ a proto nebudeme tento proces považovat za kritický. Další podmínkou pro práci se software je vytváˇrení projektu˚ a následné pˇripojování zamˇestnancu, ˚ kteˇrí na projektu spolupracují. Stejnˇe tak by projekty nemˇely být vidˇeny od zamˇestnancu, ˚ kteˇrí k nim pˇripojeni nejsou. U každého projektu je pak potˇreba vytváˇret a upravovat úkoly. Práce s úkoly je kritický úkon, který by mˇel probíhat s maximální efektivitou. Software tedy budeme mezi sebou porovnávat taktéž podle rychlosti, s jakou je možno manipulovat s úkoly. Každý úkol muže ˚ bud’ cˇ ekat bez pˇriˇrazení, nebo být pˇriˇrazen na pracovníka, který na nˇem plánuje pracovat. Software musí být schopen pˇrehlednˇe zobrazit úkoly, na kterých dˇelá zvolený zamˇestnanec. Kritický je úkon, kdy si zamˇestnanec úkol pˇriˇrazuje sám na sebe (bere úkol za svuj ˚ a zaˇcne na nˇem pracovat). Stejnˇe tak musí sytém umožnovat ˇ zamˇestnancum ˚ k úkolum ˚ pˇridávat poˇcet odpracovaných hodin a minut. Zaznamenávání cˇ asu je kritickým úkonem, proto by bylo ideální, aby mˇel u každého úkolu zamˇestnanec tlaˇcítko pro „zaˇcátek práce na úkolu“ a „konec práce na úkolu“, aby docházelo k automatickému zaznamenávání stráveného cˇ asu. Stejnˇe tak systém musí umožnovat ˇ pˇrehledný výpis stráveného cˇ asu na každém projektu a také pro jednotlivé zamˇestnance. 33
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
Tato funkcionalita velmi usnadní jak vyplácení mzdy zamˇestnanci, tak i fakturaci zákazníkovi. Každý úkol bude bˇehem svého životního cyklu procházet nˇekolika stavy. Ty mohou být pro každý projekt nebo alesponˇ pro každou firmu lehce rozdílné, proto by mˇel systém umožnovat ˇ úpravu tˇechto stavu. ˚ Pˇrepínání úkolu mezi stavy je úkon, který se bude opakovat velice cˇ asto, a proto se opˇet jedná o úkon kritický. Systém by mˇel jednoduchým zpusobem ˚ umožnovat ˇ udržování seznamu úkolu, ˚ které jsou pro daný projekt relevantní, ale nepatˇrí do aktuální iterace. Z pohledu Scrumu se tedy jedná o Project Backlog. Tento seznam nesmí být souˇcástí seznamu úkolu˚ patˇrících do aktuální iterace (Sprint Backlogu) mimo jiné i z psychologických duvod ˚ u, ˚ aby se zamˇestnanci necítili „pˇreúkolovanˇe “ pˇri pohledu na všechnu práci, která ještˇe nebyla zapoˇcata. Pokud nebude systém tuto funkci podporovat, bylo by možné ukládat potˇrebné úkoly do vlastního vedlejšího projektu. V tom pˇrípadˇe by mˇel systém podporovat jednoduché pˇresouvání úkolu˚ mezi projekty.
4.3.2 Vhodné vlastnosti software pro správu projektu˚ Pro osobnˇejší pocit pˇri práci se systémem by bylo vhodné udržovat ke každému uživateli jeho fotku. Software by mˇel umožnovat ˇ uložit odhadovanou dobu/složitost každého úkolu. Pokud toto nebude systém umožnovat ˇ explicitnˇe, je možné vždy pˇripsat odhadovanou složitost úkolu k jeho popisu. Pˇrehledný pohled na splnˇené a rozpracované úkoly umožnuje ˇ kanban. Tomuto pˇrístupu jsme se již vˇenovali v pˇredchozí kapitole. I komerˇcní software pro vedení agilních projektu˚ cˇ asto kanban nabízí (napˇríkal GreenHopper od firmy Atlassian nebo Kanban Board v Microsoft Visual Studiu 2012). Bylo by vhodné, aby vybraný software tento pohled podporoval. O pojmu bug tracking jsme se již zminovali. ˇ Znaˇcné urychlení firemních procesu˚ by pˇrineslo, kdyby klienti a uživatelé mohli do systému sami pˇridávat chyby, na které v software narazili. Pokud tuto funkci nebude systém podporovat, muže ˚ být pro klienty vytvoˇren speciální projekt nebo dokument, kam mohou nalezené chyby psát. 34
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
4.4
Správa dokumentu˚
Touto problematikou se zabývá Enterprise Content Management (ECM, [27]). Do cˇ eského jazyka je tento pojem pˇrekládán jako „správa firemního obsahu“. Zatím neexistuje ustálený pohled na to, co všechno do firemního obsahu spadá. Dle [27] mužeme ˚ jako firemní obsah brát prakticky jakýkoliv soubor strukturovaných nebo nestrukturovaných informací. Mužeme ˚ zde proto rˇ adit i emaily, weby, multimédia a znalosti (firemní dokumentace a postupy). Pro velké firmy i státní orgány má správa dokumentu˚ zásadní ˇ význam. Casto je potˇreba do ní zahrnout i skenování a ukládaní tištˇených dokumentu, ˚ pˇrevod skenovaných dokumentu˚ do textové podoby, celý workflow dokumentu˚ a mnoho dalších prvku˚ [24]. V naší práci se však zamˇerˇ ujeme na menší firmy operující v sektoru IT. Ty by se ale mˇely z praktických duvod ˚ u˚ snažit o minimalizaci nedigitální podoby dokumentu˚ (snadnˇejší úprava, manipulace, distribuce atd.). Pro tyto firmy má daleko vˇetší význam rˇ ešit správu souboru˚ v populárních formátech jako je odt, doc, docx, xls, pdf, videa, html cˇ i wiki stránky, obrázky, grafické návrhy a další formy elektronického obsahu. Ke správnému uložení potˇrebujeme znát jak samotná data, tak i jejich kontext (metadata). Napˇríklad cˇ íslo 1205 je pouhou hodnotou a nedává nám žádnou informaci, když nevíme, zda se jedná o letopoˇcet nebo popisné cˇ íslo domu. Pro plné ukládání informací a jejich správné naˇcítání musíme ukládat ke každým datum ˚ i metadata. Požadavky pro ukládání dat jsou tedy z pohledu naší hypotetické firmy velice obecné. Zamˇerˇ íme se primárnˇe na uchovávání digitálních dat, které musí splnovat ˇ nˇekolik bodu. ˚ 4.4.1 Document Management System (DMS) Systém pro správu dokumentu˚ je duležitou ˚ komponentou ECM. Jedná se o program nebo skupinu programu, ˚ která udržuje informace o elektronických dokumentech. Zpravidla takový systém uchovává metadata i všechny verze dokumentu, ˚ zodpovídá za bezpeˇcnost uchování a umožnuje ˇ vyhledávání v dokumentech. Pro komunikaci DMS pˇres internet je definovaný protokol zvaný Content Management Interoperability Services (CMIS, [7]). 35
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
4.4.2 Duležité ˚ vlastnosti software pro správu dokumentu˚ Potˇrebujeme ukládat data k jednotlivým projektum. ˚ Grafické návrhy jednoho projektu by nemˇely kolidovat s návrhy jiného projektu. Proto bude potˇreba k jednotlivým dokumentum ˚ také nastavovat viditelnost dle pˇríslušnosti k projektum. ˚ Data musí být uložena hierarchicky, aby pˇresnˇe reflektovala stromovou strukturu, na kterou jsou uživatelé zvyklí z poˇcítaˇcových souborových systému. ˚ Pro maximální flexibilitu a bezpeˇcnost musí systém archivovat každou zmˇenu dokumentu. Toto chování systému oznaˇcíme jako verzování. Významnou souˇcástí správy dokumentu˚ je také možnost v nich vyhledávat. Software tedy musí mít fulltextové vyhledávní i nad dokumenty v binárních formátech (MS Office, LibreOffice). Pro zjednodušení workflow musí mít zamˇestnanci možnost pˇrihlásit se k odbˇeru informací o zmˇenách souboru. Kdykoliv dojde k nahrání nové verze, budou všichni pˇrihlášení uživatelé na zmˇenu upozornˇeni. 4.4.3 Vhodné vlastnosti software pro správu dokumentu˚ Pro zjednodušení práce s dokumenty by bylo vhodné mít k nim pˇrístup jak pˇres webové rozhraní (popˇrípadˇe mobilní aplikaci), tak i pˇrímo pˇres souborový systém uživatele. Mluvíme tu tedy o možnosti pˇripojit se k dokumentum ˚ pomocí protokolu˚ jako jsou Network File System (NFS, [1]) nebo File Transfer Protocol (FTP, [7]).
4.5
Správa kontaktu˚
Program pro správu kontaktu˚ je v dnešní dobˇe nedílnou souˇcástí jakékoliv spoleˇcnosti. Pro naší softwarovou firmu bude potˇreba aplikace, která svojí funkcionalitou spadá do množiny systému˚ vyvýjených pro CRM neboli obchodní oddˇelení firem. Tyto systémy jsou v podnicích klíˇcové pro správnou funkci obchodních oddˇelení. V CRM systémech zamˇestnanci udržují seznamy osob a firem (tak zvané „leads“), které by bylo vhodné kontaktovat nebo které 36
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
už kontaktovány byly. Ke každé položce v seznamu je potˇreba vést záznamy o tom, jak komunikace s lead probíhá. V systému je potˇreba taktéž uchovávat zápisy z jednání a konkrétní znˇení dohod i s cenovými nabídkami, aby obchodníci mˇeli pˇrehled a firma pusobila ˚ konzistentnˇe. 4.5.1 Duležité ˚ vlastnosti software pro správu kontaktu˚ V nˇekterých pˇrípadech je potˇreba pˇridávat kontakty na jednotlivé osoby, v jiných zase naopak na celé firmy, popˇrípadˇe zamˇestnance do firem sdružovat. Toto jsou tˇri základní vlastnosti, které musí CRM systém splnovat, ˇ aby mohl být plnohodnotnˇe využíván. Dále musí náš CRM umožnovat ˇ ukládání zápisu˚ z jednání, telefonátu˚ a mailu. ˚ Komunikace mezi firmami probíhá neustále – nejen v dobˇe vyjednávání – proto je žádoucí mít kdykoliv k dispozici celou její historii. 4.5.2 Vhodné vlastnosti software pro správu kontaktu˚ Ke komunikaci se zákazníky také patˇrí vytváˇrení a organizování schuzek, ˚ kterých se úˇcasní nˇekolik stran. Proto by bylo vhodné, kdyby náš systém pomohl zorganizovat schuzku, ˚ automaticky na ni všechny cˇ leny pozval a požádal je o potvrzení úˇcasti. Nˇekteré komerˇcní CRM systémy (napˇríklad CapsuleCRM) usnadnují ˇ archivaci emailové komunikace pomocí odesílání její kopie na definovanou emailovou adresu poskytnutou CRM systémem. Jakýkoliv email, který na tuto adresu pˇríjde, je automaticky archivován a pˇriˇrazen odpovídajícímu klientovi v CRM systému.
4.6
Pˇrechod firmy na nový systém
Zavedení nových pracovních postupu˚ a nasazení nového IS ve firmˇe je velmi razantní zmˇenou. Aby se nám povedlo takovou zmˇenu provést úspˇešnˇe, budeme pˇri procesu vycházet z metodologie J. Kottera, který vˇenoval více než 30 let právˇe analýze zmˇeny. Ve své práci prezentuje 8 hlavních kroku˚ pro úspˇešné provedení zmˇeny [26]. Proces úspˇešné zmˇeny dle Kottera prochází všemi tˇemito kroky a vˇetšinou právˇe v tomto poˇradí: 37
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
4.6.1 Vyvolání vˇedomí naléhavosti Zmˇenˇe nejvíce pomuže, ˚ pokud si ji pˇreje celá spoleˇcnost. Proto je du˚ ležité vytvoˇrit pocit potˇreby zmˇeny. Tento pocit je vhodným podnˇetem pro motivaci posouvat vˇeci ve firmˇe dále. Pro vytvoˇrení naléhavosti však nestaˇcí jen ukazovat grafy s kˇrivkami znázornujícími, ˇ jak je souˇcasný stav pro firmu nevýhodný. Kotter navrhuje pˇredevším otevˇrený, upˇrímný a pˇresvˇedˇcivý dialog o tom, co se právˇe dˇeje na trhu a u konkurence. Jakmile o zmˇenˇe zaˇcne mluvit více lidí uvnitˇr firmy, potˇreba zaˇcne stavˇet sama na sobˇe lavinovým efektem.
4.6.2 Sestavení koalice schopné prosadit a realizovat zmˇeny Pˇresvˇedˇcení lidí, že je zmˇena duležitá, ˚ cˇ asto vyžaduje vedení a podporu klíˇcových lidí uvnitˇr firmy. Zmˇenu nestaˇcí jen navrhnout a organizovat, je potˇreba ji i vést. Pro správné prosazení zmˇeny je nezbytné najít výkonné vedoucí napˇríˇc celou firmou z ruzných ˚ firemních pozic a ruznou ˚ expertýzou. Tým zformovaný z takovýchto pˇresvˇedˇcených lidí je pro úspˇešné zavedení zmˇeny zásadní.
4.6.3 Vytvoˇrení vize Zmˇena cˇ asto sestává z ruzných ˚ nápadu, ˚ které postupnˇe vyplývají pˇri diskuzi nad souˇcasným stavem. Tyto nápady a útržky je potˇreba zaštítit jednotnou vizí. Ucelená vize pomuže ˚ lidem pochopit, proˇc je žádáme dˇelat nˇeco nového a mˇenit vˇeci, na které jsou zvyklí. Když lidé sami pochopí, cˇ eho se snažíte zmˇenou dosáhnout, zaˇcnou jim zmˇeny dávat smysl v širším kontextu.
4.6.4 Komunikace transformaˇcní vize Co je s vizí provedeno po jejím vytvoˇrení urˇcuje její úspˇech. Vize musí být cˇ asto opakovaná napˇríˇc firemním prostˇredím, protože jinak by mohla zapadnout nebo být vytlaˇcena jinou pˇredstavou. Nestaˇcí vizi pˇredávat jen na urˇcených setkáních, je potˇreba o ní mluvit kdykoliv máme pˇríležitost. 38
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
4.6.5 Odbourání pˇrekážek Pakliže se proces zmˇeny dostal až do tohoto stádia, znamená to, že zmˇenˇe všichni rozumˇejí a cˇ asto se o ní ve firmˇe mluví. Je tedy dule˚ žité položit si otázku, co stojí realizaci zmˇeny v cestˇe. Muže ˚ se jednat jak o souˇcasné procesy tak i o zavedené struktury. Je proto potˇreba neustále rozpoznávat a odstranovat ˇ bariéry, které stojí zmˇenˇe v cestˇe. Lidem dodá odstranˇení bariér motivaci v pokraˇcování, protože uvidí, že zmˇena je opravdu možná. 4.6.6 Vytváˇrení krátkodobých vítˇezství Není nic, co by motivovalo lidi víc než úspˇech. Je dobré ukázat celé spoleˇcnosti dílˇcí úspˇechy už v zaˇcátcích procesu. Je potˇreba, aby bylo pomˇernˇe rychle vidˇet, že zmˇena opravdu dává smysl. V opaˇcném pˇrípadˇe je velká šance, že proces neustojí tlak kritky a nedojde k jeho úspˇešnému dokonˇcení. 4.6.7 Využití výsledku˚ a podpora krátkých zmˇen Jeden z hlavních duvod ˚ u, ˚ proˇc velká cˇ ást zmˇen selže, je podle Kottera stanovení úspˇechu pˇríliš brzy. Opravdové zmˇeny musí jít daleko hloubˇeji a jejich výsledky by mˇeli být rozsáhlejší než jen pár prvních krátkodobých vítˇezství. Napˇríklad uvolnˇení prvního produktu, který je podpoˇren novým procesem, je krátkodobé vítˇezství. Teprve úspˇešné uvolnˇení deseti takovýchto produktu˚ ukáže opravdový pˇrínos zmˇeny. Než se však firma dostane k desátému produktu musí zmˇena stále probíhat a proces musí být neustále vylepšován. 4.6.8 Zakotvení nových pˇrístupu˚ do firemní kultury Aby se jakákoliv zmˇena udržela, musí se stát pevnou souˇcástí celé spoleˇcnosti. Kultura spoleˇcnosti vˇetšinou urˇcuje, jak se má ve firmˇe postupovat. Proto by mˇely být hodnoty naší vize viditelné v každodenní firemní práci. Stejnˇe tak je duležité, ˚ aby souˇcasní ani novˇe pˇríchozí lídˇri zmˇenu nepˇrestali podporovat. V této kapitole jsme vycházeli z obecných pˇredpokladu, ˚ které by mˇela vˇetšina firem naplnovat. ˇ Díky tomu jsme definovali obecné 39
ˇ ˇ MENŠÍCH A ST REDN ˇ 4. P ILÍ RE Eˇ VELKÝCH SPOLE CNOSTÍ
vlastnosti, které by mˇel IS pro menší IT firmy obsahovat. Na závˇer jsme prošli body, kterými by mˇela zmˇena firemního IS procházet, aby došlo k jeho úspˇešnému zavedení. V dalším textu se budeme vˇenovat konkrétnˇeji analýze procesu˚ ve firmˇe inQool a.s., pro kterou budeme software vybírat a nasazovat.
40
Kapitola 5
Analýza ve firmˇe Firma InQool a.s. je mladou IT spoleˇcností založenou v roce 2010. V souˇcasné dobˇe se zamˇerˇ uje jak na tvorbu zakázkového software, tak i na vývoj vlastních produktu, ˚ kterým sama zajišt’uje marketing a prodej.
5.1
Firemní struktura
Firma InQool je akciovou spoleˇcností, kterou vedou tˇri výkonní maˇ nažeˇri. Cásteˇ cnˇe se jejich funkce pˇrekrývají, mužeme ˚ však díky nim firmu rozdˇelit na tˇri primární struktury. Personání a projektový manažer zodpovídá pˇredevším za nabírání nových zamˇestnancu, ˚ za organizaci jejich práce a jejich adekvátní odmˇenování. ˇ ˇ Reditel technologií odpovídá za vývoj software. Plánuje strukturu a vhodnou implementaci projektu, ˚ vybírá pro nˇe vhodné technologie a zpracovává cenové odhady. Výkonný rˇeditel rˇ eší hlavnˇe obchodní záležitosti firmy. Pˇredevším tedy jedná se stávajícími i potenciálními klienty a prezentuje firmu a její produkty. Na starosti má teké celý obchodní a marketingový tým. Ve firmˇe dále pracují zamˇestnanci jako jsou programátoˇri, sít’oví administrátoˇri, grafici, obchodníci a další. Pro naše potˇreby nemusíme rozlišovat, zda-li jsou daní zamˇestnanci externí, tedy osoby samostatnˇe výdˇeleˇcnˇe cˇ inné, nebo zda se jedná o interní trvalé zamˇestnance firmy. Z pohledu organizace práce se nejedná o rozdílné typy, 41
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.1: Struktura fimy inQool a.s.
protože i stálým zamˇestnancum ˚ nabízí firma inQool volnou pracovní dobu a možnost pracovat odkudkoliv. Velká cˇ ást zamˇestnancu˚ firmy inQool jsou prezenˇcní studenti, proto je nepravidelná pracovní doba jednou s typických vlastností firmy. V pˇredchozí kapitole jsme rozebírali Scrum a jeho pozitivní vliv na vývoj software. Z duvodu ˚ nepravidelné pracovní doby ale nebude možné ve firmˇe striktní Scrum nasadit. Pˇri návrhu organizování práce se tedy agilními metodikami mu˚ žeme pouze inspirovat. Do firmy budeme muset nasadit rˇ ešení, které vytvoˇrí jistý kompromis mezi doporuˇcenou agilní metodikou a tím, co si ve firmˇe mohou z její podstaty dovolit. 42
5. A NALÝZA VE FIRM Eˇ
5.2
Systém pˇridˇelování HW
Ve velkých firmách vˇetšinou zamˇestnanci z bezpeˇcnostních duvod ˚ u˚ dostávají firemní poˇcítaˇce (popˇrípadˇe i telefony a další zaˇrízení). V menších firmách toto cˇ asto z ruzných ˚ duvod ˚ u˚ zvykem není, napˇríklad protože firmy své zamˇestnance nechtˇejí omezovat ve výbˇeru. Tyto firmy tedy nasazují politiku „Bring your own device“ (BYOD, [9]). Za cenu nižších nákladu˚ tím riskují možnost bezpeˇcnostního úniku, pokud zamˇestnanci nemají své poˇcítaˇce dostateˇcnˇe zabezpecˇ eny. To, že zamˇestnanci mohou pracovat odkudkoliv na svých vlastních zaˇrízeních, je souˇcástí firemní politiky i ve spoleˇcnosti inQool. Za správu pˇrístupových údaju˚ zamˇestnancu˚ je ve firmˇe zodpovˇedný centrální LDAP server. Všechny služby s podporou LDAP jsou pˇres nˇej synchronizované.
5.3
Souˇcasnˇe používané programy
Ve firmˇe se souˇcasnˇe používá nˇekolik programu˚ pro správu projektu, ˚ sdílení dokumentu, ˚ organizaci cˇ asu a komunikaci s klienty. Tento heterogenní zpusob ˚ práce bez centrálizovaného systému výraznˇe snižuje efektivitu zamˇestnancu˚ a vedoucích pracovníku. ˚ Zárovenˇ také souˇcasné rˇ ešení neumožnuje ˇ spolehlivou zálohu a jednotné vyhledávání ve všech firemních záznamech. 5.3.1 Organizace a plánování V souˇcasné chvíli používá firma inQool na organizování práce svých zamˇestnancu˚ program Mantis. Zamˇestnancum ˚ tento systém nevyhovuje, protože není pˇrehledný, obsahuje spoustu nadbyteˇcných informací, které nevyužívájí, a bˇežné úkony v nˇem zabírají zbyteˇcnˇe mnoho cˇ asu. Jméno: Mantis BT Web:
Licence: GNU GPL 43
5. A NALÝZA VE FIRM Eˇ
Kategorie programu: Systém pro zaznamenávání chyb (bug tracking system) Technické detaily: Mantis je naprogramovaný v PHP a kompatibilní s MySQL, MS SQL a PostgreSQL. Podporované systémy pro instalaci jsou Windows, Linux, Mac OS a OS/2.
Obrázek 5.2: Program Mantis BT Jedná se o robustní systém pro evidenci chyb u velkých projektu, ˚ které mají tisíce uživatelu. ˚ K tomuto byl program primárnˇe urˇcen a tuto funkci plní správnˇe. Zárovenˇ je použitelný jak pˇri práci na proprietárním software, tak i pro open-source projekty. Program ale není vhodný pro vedení vývoje projektu. ˚ Každý záznam v databázi považuje Mantis jako nahlášení chyby, kterou je potˇreba odhalit a opravit. Proto ke každé chybˇe nabízí i cˇ íslo rˇ ádku, na kterém se chyba nachází, popis opravy, verzi programu, u které došlo k opravˇe, a další pro vývoj nových projektu˚ zbyteˇcné položky. 5.3.2 Správa stráveného cˇ asu zamˇestnancu˚ V souˇcasné chvíli firma inQool nemá žádný zpusob ˚ jak ukládat, kolik cˇ asu strávili zamˇestnanci na jednotlivých úkolech. Zamˇestnanci 44
5. A NALÝZA VE FIRM Eˇ pouze ukládají do Excel dokumentu celkový cˇ as, který strávili daný den v práci. Toto firmˇe neumožnuje ˇ jakýmkoliv zpusobem ˚ urˇcovat délku odpracované doby pro jednotlivé zákazníky. 5.3.3 Ukládání dokumentu˚ Duležitost ˚ perzistence firemních dokumentu˚ již byla probírána v pˇredchozí kapitole. V souˇcasné dobˇe ve firmˇe inQool není nasazené žádné unifikované rˇ ešení pro správu firemního obsahu. Zamˇestnanci firmy používají k pˇredávání dokumentu˚ podle potˇreby pˇredevším dvˇe webové služby. Jméno: Dropbox Web: Licence: Tento software je proprietární. Není možné získat jeho zdrojové kódy a je nabízený jako SaaS. Základní velikost úložného prostoru je nabízena zdarma. Rozšiˇrování velikosti a další funkce jsou zpoplatnˇeny. Kategorie programu: Jednoduchá služba pro online ukládání souboru˚ Technické detaily: Služba je aktivní už od roku 2008. Program je napsaný v jazyce Python a nabízí jak pˇrístup ke službˇe pˇres webové rozhraní, tak i klienty pro rˇ adu populárních platforem (Microsoft Windows, Linux, Mac OS X, iOS, Android a další). Program Dropbox nabízí možnost pracovat se soubory jak pˇres webové rozhraní, tak i pomocí aplikace, která synchronizuje soubory fyzicky na disku klienta. S kolegy je možné sdílet a synchronizovat celé složky pomocí sdílených adresáˇru˚ nebo jen nabízet aktuální verze jednotlivých souboru˚ pomocí HTTP odkazu. ˚ Ve firmˇe inQool jsou na práci s programem Dropbox zvyklí a vyhovuje jim. Díky pˇrímému pˇripojení souboru˚ na disk uživatele je služba velice efektivní. Hlavní nedostatky jsou uzavˇrenost služby a nutnost platit za sdílený obsah. Stejnˇe tak pˇridání nového zamˇestnance do systému vždy znamená nastavování všech složek s projekty, ke kterým by mˇel dostat pˇrístup. Ideální by tedy bylo najít alternativu uživatelsky velice podobnou službˇe Dropbox. 45
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.3: Program Dropbox Jméno: Google Drive Web: Licence: Tento software je proprietární. Není možné získat jeho zdrojové kódy a je nabízený jako SaaS. Základní velikost úložného prostoru je nabízená zdarma, rozšiˇrování velikosti a další funkce jsou zpoplatnˇeny. Kategorie programu: Služba pro online ukládání souboru˚ a online spolupráci Technické detaily: Google nabízí kompletní textový editor, tabulkový editor a aplikaci pro vytváˇrení prezentací ve webovém rozhraní. Dále nabízí možnost synchronizovat soubory na klientském disku pomocí podobné služby jako Dropbox. Klient v souˇcasné dobˇe podporuje systémy Microsoft Windows, Mac OS X, Android, iOS a Chrome OS, neexistuje oficiální podpora pro linux. Google Drive je služba velmi podobná pˇredchozímu Dropboxu. Pˇridanou hodnotu, kterou svým zákazníkum ˚ nabízí navíc, je synchronizované upravování dokumentu˚ pomocí webového rozhraní. Tato možnost z nˇej dˇelá vynikající prostˇredek pro online týmovou spolupráci. Ve firmˇe inQool je tato funkcionalita využívána pro komunikaci s klienty, ukládání zpráv z porad i zapisování docházky 46
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.4: Program Google Drive zamˇestnancu. ˚ 5.3.4 Komunikace s klienty Pˇrestože vztahy s klienty rˇ eší v souˇcasnou chvíli prakticky pouze jeden cˇ lovˇek, vznikla ve firmˇe samovolnˇe potˇreba využívat CRM systém. Tento jev upevnuje ˇ tvrzení z pˇredchozí kapitoly, kdy jsme postavili CRM systém mezi tˇri nejduležitˇ ˚ ejší pilíˇre IS malých IT firem. Jméno: Capsule CRM Web: Licence: Tento software je proprietární. Není možné získat jeho zdrojové kódy a je nabízený jako SaaS. Základní funkce jsou nabízené zdarma, rozšiˇrování poˇctu uživatelských úˇctu˚ v rámci jedné organizace a další funkce jsou zpoplatnˇeny. Kategorie programu: CRM systém Technické detaily: Program bˇeží jako webová aplikace, na serveru je napsaný v jazycích Java a Scala. V prohlížeˇci se kód opírá o backbone.js. Tato aplikace podobnˇe jako Dropbox nebo Trello plní svuj ˚ úkol velice dobˇre. Práce v ní je velice pˇrímá a efektivní. Splnuje ˇ dokonce témˇerˇ všechny funkˇcní požadavky, které jsme stanovili na CRM systém v pˇredchozí kapitole. Umožnuje ˇ i organizovat cˇ as a vytváˇret 47
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.5: Program CapsuleCRM úkoly. Jejím hlavním nedostatkem je proprietární licence a poplatek za využívání v závislosti na velikosti organizace. V rámci bezplatného využívání je možné, aby do systému mˇeli pˇrístup jen dva uživatelé. Protože se snažíme najít finanˇcnˇe nejvýhodnˇejší variantu pro spoleˇcnost inQool, pokusíme se najít alternativu i tomuto systému.
5.4
Chybˇející prvky a vlastnosti
Z pohledu na spoleˇcnost, který jsme pˇredstavili v pˇredešlých odstavcích, chybí v souˇcasném IT rˇ ešení firmˇe inQool nˇekolik prvku˚ a vlastností, které by plnohodnotný informaˇcní systém mˇel obsahovat. V první rˇ adˇe jsme pˇredeslali, že systém by mˇel být pokud možno co nejvíce jednolitý a konzistentní. Tento požadavek, jak bylo nastínˇeno v pˇredchozích odstavcích souˇcasné, rˇ ešení ve firmˇe inQool rozhodnˇe nesplnuje. ˇ Stejnˇe tak souˇcasná rˇ ešení nedávají možnost, aby firma mohla mít data uložená u sebe na svém serveru, protože vˇetšina služeb, jež inQool využívá, je nabízená pouze ve formˇe SaaS. Z konkrétních prvku˚ systému chybí firmˇe napˇríklad centralizovaný seznam pracovníku, ˚ kde by na sebe jednotliví zamˇestnanci mohli sehnat kontakt v pˇrípadˇe, že by potˇrebovali rˇ ešit naléhavé zá48
5. A NALÝZA VE FIRM Eˇ ležitosti. Dále firma nemá vypracovaný zpusob ˚ jak ukládat informace o pˇresném objemu cˇ asu, který její zamˇestnanci strávili na jednotlivých úkolech. Zapisuje se pouze celkový cˇ as, který byl strávený na projektu.
5.5
Návrh nových procesu˚
Po analýze stávajících postupu˚ vývoje produktu˚ ve firmˇe inQool jsme vytvoˇrili unifikované diagramy, které vznikly slouˇcením firemní kultury s metodikou Scrum. Je na nich znázornˇeno, jak by se ve firmˇe mˇelo postupovat pˇri rˇ ešení zakázky. Grafy prezentují jak postup pˇri vývoji software, tak i úkony, které budou požadovány po informaˇcním systému. Protože pro témˇerˇ každý úkon je potˇreba interakce s IS, není v grafu pro pˇrehlednost IS vyznaˇcen. (Mˇel by být zakreslen jako back box entita.) Interakci s IS vyžaduje každý úkol, který je oznaˇcený jako User Task. (Dle BPMN notace obsahuje ikonku uživatele.) Model práce na projektu 5.6 pˇredstavuje zpusob, ˚ jak bude ve firmˇe inQool pˇri vytvoˇrení nového projektu manažer a obchodní zástupce pracovat s informaˇcním systémem. Diagram 5.7 pak znázornuje ˇ prubˇ ˚ eh sprintu˚ v rámci práce na projektu. V modelech je patrná inspirace v agilních technikách, která se projevuje pˇredevším v definici backlogu˚ a v iterativním pˇrístupu k vývoji. Modely pˇredstavují chování systému a fáze, kterými prochází pˇri interakci s uživateli. Díky formálnˇe definovaným potˇrebám mužeme ˚ nyní zaˇcít pro firmu inQool hledat vhodné softwarové zázemí. Pˇri vývoji systému˚ je naprosto bˇežné, že zákazník pˇri testování nebo i plném provozu narazí na implementaˇcní nebo funkˇcní chyby. Model 5.8 pˇredstavuje proces, podle kterého bude ve firmˇe inQool docházet k zaznamenávání chyb. Procesy pro shromažd’ování obchodních kontaktu˚ a vyjednávání pˇri vzniku nové zakázky jsou zaznamenány na diagramech 5.9 a 5.10.
49
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.6: Model procesu práce na projektu 50
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.7: Model procesu Sprint pˇri práci na projektu 51
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.8: Model procesu na zaznamenávání chyb pˇri vývoji 52
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.9: Model procesu pˇredstavující vznik nového projektu 53
5. A NALÝZA VE FIRM Eˇ
Obrázek 5.10: Model práce obchodního zástupce 54
Kapitola 6
Stanovení kritérií pro hodnocení software Na trhu je k dispozici rozsáhlé množství software pro správu projektu, ˚ dokumentu˚ a kontaktu. ˚ Testovat detailnˇe každý program by bylo pˇríliš nároˇcné, proto testování rozdˇelíme na dvˇe fáze. První fázi mužeme ˚ pˇrirovnat k prohledávání do šíˇrky. Stanovíme si jednoduchá kritéria, která musí software splnovat, ˇ a pokud jim bude jeho funkcionalita odpovídat nebo bude svou funkci plnit výraznˇe lépe než konkurenˇcní produkty, postoupí do druhé fáze. Takto rychle otestujeme širokou škálu rˇ ešení, která trh nabízí. Druhá, detailní fáze testování pak bude probíhat nad výraznˇe menší množinou produktu. ˚
6.1
Kritéria pro první fázi testování
Všechna softwarová rˇ ešení musí obecnˇe vyhovovat následujícím podmínkám. 1.
Software musí pracovat jako služba pˇres webové rozhraní.
2.
Musí být možné software nainstalovat, provozovat a data ukládat na vlastním serveru.
3.
Pakliže se jedná o open-source projekt, nesmí být zastaralý a musí mít aktivní komunitu.
4.
Software musí mít možnost synchronizovat uživatele pomocí protokolu LDAP, abychom mohli využít stávající infrastrukturu. 55
6. S TANOVENÍ KRITÉRIÍ PRO HODNOCENÍ SOFTWARE 6.1.1 Kritéria pro správu projektu˚ 1.
Systém musí podporovat vytváˇrení projektu, ˚ pˇridávání uživatelu˚ a vytváˇrení úkolu. ˚
2.
Projekty musí být viditelné pouze pro uživatele, kteˇrí jsou k nim pˇrihlášeni.
3.
K úkolum ˚ musí být možné pˇridávat cˇ as, který na nˇem pracovníci strávili.
4.
U úkolu˚ musí být možné mˇenit stavy (hotovo, rozpracováno a další).
5.
Software musí nabídnout každému zamˇestnanci možnost zobrazit seznam všech jeho kolegu. ˚
6.1.2 Kritéria pro správu kontaktu˚ 1.
Musí být možno pˇridávat jak kontakty na celé spoleˇcnosti, tak i kontakty na jednotlivé lidi.
2.
Kontakty na pracovníky musí být možné agregovat pod firmu.
3.
Ke každému kontaktu musí být možnost pˇridávat komentáˇre a shrnutí z jednání.
6.1.3 Kritéria pro správu dokumentu˚ 1.
Ukládání dokumentu˚ do hierarchické struktury.
2.
Nastavování pˇrístupových práv všem uživatelum. ˚
3.
Fulltextové vyhledávání v dokumentech.
6.1.4 Cena rˇešení Z duvodu ˚ minimalizace nákladu˚ na nasazení a provoz software firma inQool trvá na open-source rˇ ešení, proto budeme brát v potaz pouze otevˇrené projekty, které mužeme ˚ nasadit na firemní servery. 56
6. S TANOVENÍ KRITÉRIÍ PRO HODNOCENÍ SOFTWARE Otázku, zda-li použití otevˇreného software opravdu náklady redukuje, projednávala napˇríklad studie [38], která došla k pozitivním závˇerum. ˚ Další výhodou je, že programátoˇri z firmy si také budou moci dále aplikace upravovat podle svých potˇreb. I z pohledu soukromí se jedná o výhodné rˇ ešení (firma uchovává svá vlastní data).
6.2
Pˇresnˇejší kritéria pro druhou fázi
Na druhou fázi testování již budeme mít pˇripravenou množinu softwaru, o které víme, že splnuje ˇ naše základní požadavky na funkcionalitu. Budeme tedy testovat pˇredevším vlastnosti uživatelského rozhraní jednotlivých produktu. ˚ Pro objektivní mˇerˇ ení tˇechto vlastností budeme vycházet z metriky Scenairo-Based UX metrics scorecard (SBUMS, [21]), kterou pro mˇerˇ ení vlastností UI navrhuje Phil H.Goddard, Ph.D. z Human Factors International. Pˇripravíme si scénáˇre, které nás zajímají v rámci navržených procesu˚ pro firmu inQool z pˇredchozí kapitoly, a otestujeme, s jakou efektivitou je možno tyto scénáˇre provádˇet ve vybraných aplikacích. Abychom odhalili, zda budou programy efektivní právˇe pro naše potˇreby, použijeme pro simulaci ty úkony, které v procesech obsahují cyklické a cˇ asté opakování. Obchodní scénáˇr: Obchodní zástupce právˇe narazil na zajímavého zákazníka a uzavˇrel s ním dohodu. Chce ted’ do systému pˇridat novou zakázku. Projektový scénáˇr: Projektový manažer potˇrebuje požádat zamˇestnance, aby vytvoˇril HTML a CSS kód pro novou šablonu v PSD formátu z programu Photoshop. Scénáˇr pro práci s dokumenty: Grafik vytvoˇril nˇekolik grafických návrhu˚ webu a uloží je pˇres webové rozhraní na spoleˇcný server. Rychlost, s jakou mužeme ˚ scénáˇr pomocí daných nástroju˚ provést, pak budeme hodnotit za pomocí spojením mˇerˇ ítek, které na57
6. S TANOVENÍ KRITÉRIÍ PRO HODNOCENÍ SOFTWARE vrhuje SBUMS a mˇerˇ itek, které odpovídají požadavkum ˚ sledované firmy. Konkrétnˇe budeme hodnotit z tˇechto pohledu: ˚ Navigace urˇcuje, jak jednoduché je dostat se z úvodní stránky k provedení našeho scénáˇre a jak intuitivní jsou všechny kroky. Zárovenˇ budeme tyto jednotlivé kroky poˇcítat. Za krok považujeme nutnost posunout se dále ve struktuˇre webu. Tedy vyplnˇení položky formuláˇre není krokem, zatímco odeslání celého formuláˇre nebo kliknutí na odkaz krokem je. Duležitým ˚ mˇerˇ ítkem je také práce s obsahem (ukládání dokumentu, ˚ nebo textu) a možnost napojení systému na další služby. Obsah jednotlivých stránek, které nás provází pˇri naší cestˇe úkolem, je také významné mˇerˇ ítko. Samozˇrejmˇe by mˇelo být obsahu co nejménˇe a mˇel by být co nejvíce relevantní našemu úkolu. Systém by nemˇel zobrazovat zbyteˇcné informace. Prezentace je celkový dojem ze systému a grafická pˇrívˇetivost. Interakce si klade otázku, zda-li zpusob, ˚ jakým s námi systéme komunikuje, odpovídá našim pˇredpokladum ˚ a zda-li nám podle toho také pomáhá vhodnˇe jednat. Integrace nám udává, jak moc je komplikované propojit aplikaci s dalšími systémy. Hodnotíme zde zejména dostupné pˇrídavky pro aplikaci a pokroˇcilost Application Programming Interface (API, [4]), tedy rozhraní, které nám aplikace nabízí pro pˇrípojení jiných služeb. Knowledge management znamená, jak systém pracuje se znalostmi a dokumentací u projektu, ˚ popˇrípadˇe na kolik je schopen využít pro tuto správu software jiných stran. Pˇrístupnost rozdˇeluje body podle toho, zda-li nám produkt muže ˚ nabídnout mobilní aplikaci nebo alesponˇ plnohodnotný mobilní web. Protože produkty hodnotíme relativnˇe, nikoliv absolutnˇe (jak popisuje puvodní ˚ SBUMS), budeme rozdávat cˇ ísla v závislosti na tom, kolikátý se daný produkt umístil ve srovnání s ostatními (tedy 1 znamená nejlepší). 58
6. S TANOVENÍ KRITÉRIÍ PRO HODNOCENÍ SOFTWARE
6.3
Stanovení metriky pro porovnání zlepšení
Abychom mohli pˇresnˇe urˇcit jak naše rˇ ešení ovlivnilo pracovní výkon zamˇestnancu, ˚ musíme stanovit metriku, podle které budeme zmˇenu poˇcítat. Jak jsme již zminovali, ˇ našim hlavním poždavkem na nástroj je jeho efektivita. Chceme minimalizovat cˇ as, který zamˇestnanci musí trávit s nástrojem na správu úkolu˚ a naopak maximalizovat cˇ as, který jim zbyde na samotnou práci. Stanovíme si tedy Key Performace Indicator (KPI, [36]) jako dobu, kterou zamˇestnanci stráví ve webovém prohlížeˇci na stránkách nástroje pro organizaci práce. Tuto dobu budeme mˇerˇ it pomocí rozšíˇrení do prohlížeˇce Chrome, které se nazývá Time Tracker [17]. Primárnˇe je urˇceno pro sledování objemu cˇ asu stráveného na jednotlivých stránkách. Aby program posloužil našemu zámˇeru, nastavíme cˇ ítaˇc na nulu a uvidíme, o jak velký cˇ asový úsek se zamˇestnancum ˚ odpoˇcet u firemních nástroju˚ zvýší za týden práce. Po nasazení našeho rˇ ešení do firmy poˇckáme dostateˇcnˇe dlouho, než si zamˇestnanci na práci s programem zvyknou, a provedeme opˇetovné mˇerˇ ení. Nakonec porovnáme výsledky a vyvodíme závˇery.
59
Kapitola 7
Zhodnocení dostupných produktu˚ Tato kapitola se vˇenuje praktickému výbˇeru vhodného software popsaným zpusobem ˚ dle stanovených kritérií.
7.1
První fáze
7.1.1 Systémy pro správu projektu˚ Jméno: trac Web: Licence: Upravená BSD licence Kategorie programu: Primárnˇe se jedná o program na zaznamenávání chyb (bug tracking). Spadá tedy do podobné kategorie jako dˇríve zminovaný ˇ Mantis a není pro naše potˇreby pˇríliš vhodný. Primární programovací jazyk: Python Závˇer: Program nepodporuje ukládání stráveného cˇ asu zamˇestnancu. ˚ Obecnˇe se jedná spíše o aplikaci z kategorie bug tracking než systém pro správu projektu. ˚ Jméno: WebIssues Web: Licence: AGPL Kategorie programu: Bug Tracking Primární programovací jazyk: PHP Závˇer: Tento program také nepodporuje ukládání stáveného cˇ asu 60
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.1: Ukázka programu trac zamˇestnancu˚ a jeho podstatou je spíše zaznamenávání chyb než zadávání úkolu˚ pro vývoj nových projektu. ˚
Obrázek 7.2: Ukázka programu WebIssues Jméno: Mantis BT Web:http://www.mantisbt.org/ Licence: GPL Kategorie programu: BugTracker Primární programovací jazyk: PHP Závˇer: Na program jsme již narazili v pˇredchozí cˇ ásti práce. Nepodporuje ukládání stráveného cˇ asu zamˇestnancu. ˚ Není vhodný jako 61
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ systém pro správu projektu. ˚
Obrázek 7.3: Ukázka programu Mantis BT Jméno: BugZilla Web: Licence: MPL Kategorie programu: BugTracker Primární programovací jazyk: Perl Závˇer: Bugzilla je další ukázkou programu primánˇe pro bug tracking, který není pˇríliš vhodný pro plánování a správu projektu. ˚ Jméno: Redmine Web: Licence: GPL Kategorie programu: Webová aplikace pro správu projektu˚ Primární programovací jazyk: Ruby Další funkce: Jako doplnˇek je možno k systému doinstalovat CRM systém i kanban pohled na úkoly. Taktéž je možno použít systém pro správu informací o projektech (knowledge management) díky integrované wiki a ukládání souboru. ˚ 62
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.4: Ukázka programu BugZilla Závˇer: Jedná se o program pro správu projektu. ˚ Redmine je velice obsáhlý a obsahuje velké množství doplnk ˇ u, ˚ pomocí kterých je možno funkcionalitu dále upravovat. Komunita kolem projektu je široká a aktivní. Program umožnuje ˇ i ukládat strávený cˇ as k jednotlivým úkolum. ˚ Systém odpovídá našim požadavkum. ˚
Obrázek 7.5: Ukázka programu Redmine Jméno: ClockingIT Web: Licence: MIT/X11 Kategorie programu: Webová aplikace pro ukládání úkolu˚ a stráve63
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ ného cˇ asu Primární programovací jazyk: Ruby Závˇer: Komplexní systém pro evidenci projektu˚ a stráveného cˇ asu s integrovaným chatem a seznamem kontaktu. ˚ Projekt ale není dále vyvíjen ani upravován. Poslední úprava kódu byla provedena pˇred tˇremi lety.
Obrázek 7.6: Ukázka programu ClockingIT Jméno: FengOffice Community Edition Web: Licence: AGPL Kategorie programu: Software pro spolupráci týmu Primární programovací jazyk: PHP Závˇer: FengOffice je primárnˇe nabízený jako SaaS. My jsme se ale zamˇerˇ ili na Comunity Edition, která je open source. Feng Office nabízí vytváˇrení projektu, ˚ úkolu, ˚ seznamu zamˇestnacu˚ i ukládání stráveného cˇ asu k jednotivým úkolum. ˚ V souˇcasné verzi ale není možné zjistit, kolik cˇ asu který zamˇestnanec dohromady odpracoval. Systém tedy neodpovídá naším požadavkum. ˚ Jméno: PHProjekt 64
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.7: Ukázka programu FengOffice Community Edition Web: Licence: LGPL Kategorie programu: Správce úkolu˚ Primární programovací jazyk: PHP Závˇer: Projekt je sice aktivní, ale v souˇcasné chvíli nepodporuje všechny potˇrebné funkce a není ani plnˇe dokonˇcený.
Obrázek 7.8: Ukázka programu PHProjekt Jméno: Codendi Community Edition Web: 65
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Licence: GPL Kategorie programu: Systém pro správu projektu˚ Primární programovací jazyk: PHP Závˇer: Program je obsáhlý a na první pohled nepˇrehledný. Ve své komunitní verzi navíc nepodporuje kompletní funkcionalitu. Pro naše potˇreby je tedy nevhodný.
Obrázek 7.9: Ukázka programu Codendi Community Edition Jméno: Trello Web: Licence: Nabízeno zdarma jako SaaS pro libovolné využití Kategorie programu: Aplikace pro sdílení a organizování úkolu˚ Primární programovací jazyk: JavaScript (node.js, backbone.js) Závˇer: Trello je velice efektivní program pro organizování menších a stˇrednˇe velkých týmu˚ pomocí kanbanu. Nabízí i mobilní aplikaci s plnou funkˇcností pro všechny populární platformy. Za využívání všech funkcí programu není potˇreba platit žádné poplatky a autoˇri slibují, že se tato politika v budoucnu nezmˇení. Z našich požadavku˚ nesplnuje ˇ možnost nasazení aplikace na vlastním serveru a ukládání stráveného cˇ asu. Protože je aplikace výraznˇe efektivnˇejší a pˇrehlednˇejší než ostatní, postupuje i pˇres nedostatek se stráveným cˇ asem do druhého kola. 66
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.10: Ukázka programu Trello
Jméno: Collabtive Web: Licence: GPL Kategorie programu: Systém pro správu projektu˚ Primární programovací jazyk: PHP Závˇer: V tomto programu není možno pˇriˇrazovat úkoly zamˇestnancum. ˚ Z našeho pohledu je nevyhovující.
Obrázek 7.11: Ukázka programu Collabtive Jméno: Web2project Web: Licence: GPL 67
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Kategorie programu: Webová aplikace pro správu projektu˚ Primární programovací jazyk: PHP Závˇer: Systém není pˇrehledný a neodpovídá našim požadavkum ˚ na jednoduchou a pˇrímoˇcarou aplikaci. Tato webová aplikace by byla vhodnˇejší na správu velkých projektu˚ ve spoleˇcnostech, které kladou vˇetší duraz ˚ na robustnost než na efektivitu nástroje.
Obrázek 7.12: Ukázka programu Web2project Jméno: XPlanner+ Web: Licence: LGPL Kategorie programu: Nástroj pro podpru agilního vývoje Primární programovací jazyk: Java Závˇer: Webová aplikace splnuje ˇ požadavky na agilní vývoj. Nabízí možnost definovat iterace a User Stories. Jejím velkým nedostatkem je však nízká pˇrehlednost a neaktivita komunity. Vývoj projektu více jak rok stojí. Jméno: IceScrum Web: Licence: AGPL 68
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.13: Ukázka programu XPlanner+ Kategorie programu: Webová aplikace pro striktní Scrum vývoj Primární programovací jazyk: Java Závˇer: Tato webová aplikace je vhodná pro týmy, které plánují nasadit striktní Scrum. To ale není situace, která by se týkala firmy inQool.
Obrázek 7.14: Ukázka programu IceScrum Jméno: Zimbra Web: Licence: Zimbra Public License 69
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Kategorie programu: Webový mailový klient Primární programovací jazyk: Java Další funkce: Aplikace Zimbra muže ˚ být díky doplnk ˇ um ˚ taktéž použita jako CRM systém. Závˇer: Zimbra je komplexni mailový klient vhodný pro týmovou spolupráci. K dispozici ke stažení je také mnoho rozšíˇrení. Primárnˇe je však Zimbra navržená pro práci s maily, organizování práce není silnou stránkou programu.
Obrázek 7.15: Ukázka programu Zimbra Jméno: KForge Web: Licence: GPL Kategorie programu: Portál pro správu velkých projektu˚ Primární programovací jazyk: Python Závˇer: Aplikace nabízí rozsáhlou funkcionalitu. Navržená je však pro správu velkých open-source projektu, ˚ jejichž vývoje se úˇcastní stovky lidí. Pro menší firmu s desítkou zamˇestnancu˚ vhodná není. Jméno: Launchpad 70
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.16: Ukázka programu KForge Web: Licence: AGPL Kategorie programu: Portál pro správu velkých projektu˚ Primární programovací jazyk: Python Závˇer: Aplikace je velice podobná programu KForge. A stejnˇe tak je koncipovaná pro správu open-source projektu, ˚ nikoliv pro firmu s desítkou zamˇestnancu. ˚ Jméno: OpenERP Web: Licence: AGPL Kategorie programu: Komplexní ERP systém Primární programovací jazyk: Python Další funkce: OpenERP je možno použít taktéž jako plnohodnotný CRM systém. Závˇer: Webová aplikace je komplexní a nabízí správu velkých firem od projektu˚ pˇres sklady až po knihu jízd a obˇedy pro zamˇestnance. 71
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.17: Ukázka programu Launchpad Kdybychom však použili pouze pár modulu˚ z nabídky, dostaneme jednoduchý a pˇrehledný systém pro správu kontaktu˚ a projektu. ˚ Aplikace nabízí i ukládání stráveného cˇ asu a kanban pohled na rozpracované projekty. Systém odpovídá našim požadavkum. ˚
Obrázek 7.18: Ukázka programu OpenERP Jméno: Tryton Web: Licence: GPL Kategorie programu: Komplexní ERP systém Primární programovací jazyk: Python 72
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Závˇer: Jedná se o klon OpenERP. V souˇcasné dobˇe nemá funkˇcní webové rozhraní.
Obrázek 7.19: Ukázka programu Tryton Jméno: Teamlab Office Open Source Version Web: Licence: AGPL Kategorie programu: Správa projektu˚ a online kanceláˇre Primární programovací jazyk: C# Závˇer: Komerˇcní verze aplikace splnuje ˇ vˇetšinu našich požadavku. ˚ Open-source verze je již pul ˚ roku beze zmˇeny a nenabízí plnou funkcionalitu. Jméno: Tree.io Web: Licence: Creative Commons Attribution-NonCommercial 3.0 License Kategorie programu: Správa projektu˚ a online kanceláˇre Primární programovací jazyk: Python 73
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Další funkce: Tree.io nabízí funkcionalitu CRM systému. Závˇer: Jedná se o webovou službu, která splnuje ˇ všechny naše požadavky na organizování práce a ukládání stráveného cˇ asu. Systém nabízí i ukládání kontaktu. ˚ Dokonce Tree.io nabízí i integrovaný chat. Tento systém odpovídá našim požadavkum. ˚
Obrázek 7.20: Ukázka programu Tree.io Jméno: Tactic Web: Licence: Eclipse Public License Kategorie programu: Správa projektu˚ vytváˇrejících digitální média Primární programovací jazyk: Python Závˇer: Jedná se o program, jehož primárním cílem je spravovat vývoj digitálního obsahu. Je napsaný pˇrímo pro firmy, které vytváˇrí grafiku, modely a multimédia. Pro firmu, která primárnˇe vytváˇrí software, vhodný není. Jméno: ADempiere Web: Licence: GPL Kategorie programu: Kompletní implementace ERP systému 74
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.21: Ukázka programu Tactic Primární programovací jazyk: Java Závˇer: Velice komplexní aplikace pro správu ERP vhodná pro podniky, které pracují s fyzickými komoditami. Pro organizování projektu˚ vˇenujících se vývoji aplikací je nevhodná.
Obrázek 7.22: Ukázka programu ADempiere Jméno: LibrePlan Web: Licence: AGPL 75
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Kategorie programu: Implementace ERP systému Primární programovací jazyk: Java Závˇer: Komplexní ERP systém, jeho hlavní pˇredností jsou možnosti plánování a generování Ganttových diagramu. ˚ Pro námi stanovené potˇreby je systém pˇríliž rozsáhlý.
Obrázek 7.23: Ukázka programu LibrePlan Jméno: Plandora Web: Licence: LGPL Kategorie programu: Komplexní plánování zdroju˚ a výdaju˚ Primární programovací jazyk: Java Závˇer: Jedná se o komplexní projekt, který nabízí finanˇcní a cˇ asové plánování podniku. ˚ Pro naše potˇreby rˇ ízení vývojových projektu˚ je nevhodný.
7.1.2 Systémy pro správu souboru˚ Jméno: Apache Jackrabbit Web: 76
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.24: Ukázka programu Plandora Licence: Apache License 2.0 Kategorie programu: Správce obsahu Primární programovací jazyk: Java Závˇer: Apache Jackrabbit je správce repozitáˇre, který sám nenabízí žádné webové rozhraní. Je nutno k nˇemu pˇripojovat klienty napˇríklad pˇres CMIS protokol. My hledáme programové rˇ ešení, které nám rovnou poskytne i webové rozhraní. Jméno: Nuxeo 5 Web: Licence: LGPL Kategorie programu: Enterprise Content Management System Primární programovací jazyk: Java Závˇer: Jedná se o systém pro správu digitálního obsahu, který splnuje ˇ všechny naše požadavky vˇcetnˇe verzování všech zmˇen i synchronizace souboru˚ v adresáˇrovém systému u klienta pomocí aplikace Nuxeo Drive. Systém odpovídá našim požadavkum. ˚ Jméno: MyDMS Web: 77
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.25: Ukázka programu Nuxeo 5 Licence: GPL Kategorie programu: Jednoduchý systém na správu obsahu Primární programovací jazyk: C# Závˇer: Systém je pˇríliš jednoduchý, nepodporuje verzování ani synchronizaci klientského souborového systému. Jméno: Alfresco Share Web: Licence: LGPL Kategorie programu: Enterprise Content Management System Primární programovací jazyk: Java Závˇer: Jedná se o systém pro správu digitálního obsahu, který splnuje ˇ všechny naše požadavky vˇcetnˇe verzování všech zmˇen. Synchronizace souboru˚ v adresáˇrovém systému u klienta je možno pomocí aplikace CmisShare. Systém odpovídá našim požadavkum. ˚
7.1.3 Systémy pro správu kontaktu˚ Jméno: Zurmo 78
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.26: Ukázka programu Alfresco Share Web: Licence: GPL Kategorie programu: CRM systém Primární programovací jazyk: PHP Závˇer: Plnˇe funkˇcní CRM systém, který splnuje ˇ všechny naše požadavky.
Obrázek 7.27: Ukázka programu Zurmo Jméno: SplendidCRM Web: 79
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Licence: AGPL Kategorie programu: CRM systém Primární programovací jazyk: C# Závˇer: Rozsáhlý CRM systém, který pokrývá daleko více požadavku, ˚ než které jsme na systém kladli my.
Obrázek 7.28: Ukázka programu SplendidCRM Jméno: FatFreeCRM Web: Licence: MIT Kategorie programu: CRM systém Primární programovací jazyk: Ruby Závˇer: Plnˇe funkˇcní CRM systém, který splnuje ˇ všechny naše požadavky. Jméno: SugarCRM’s Sugar Community Edition Web: Licence: AGPL Kategorie programu: Komplexní CRM systém Primární programovací jazyk: PHP 80
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
Obrázek 7.29: Ukázka programu FatFreeCRM
Závˇer: Rozsáhlý CRM systém, který pokrývá daleko více požadavku, ˚ než které jsme na systém kladli my.
Obrázek 7.30: Ukázka programu SugarCRM’s Sugar Community Edition
81
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚
7.2
Druhá fáze
Naším eliminaˇcním procesem v první fázi prošly cˇ tyˇri aplikace na správu projektu, ˚ tyto aplikace obsahují zárovenˇ i CRM modul s plnou funkcionalitou, kterou vyžadujeme pro správu kontaktu. ˚ Abychom zvýšili kompaktnost celého rˇ ešení, použijeme pro správu CRM kontaktu˚ stejný systém jako pro správu projektu. ˚ Pro správu digitálního obsahu nám zbyly celkem dvˇe možná rˇ ešení. Z tˇechto dvou vybereme takové, které pujde ˚ lépe zaintegrovat do systému na správu projektu. ˚
7.2.1 Obchodní scénáˇr Obchodní zástupce právˇe narazil na zajímavého zákazníka a uzavˇrel s ním dohodu. Chce ted’ do systému pˇridat novou zakázku.
Redmine (plugin Contacts) Ke kontaktum ˚ je potˇreba pˇristupovat pˇres samotný projekt, což bohužel ubírá navigaci. Samotné vytváˇrení a úprava kontaktu˚ je pak ale uživatelsky pˇrímoˇcará a rychlá. Modelový scénáˇr je pak možno provést v 5 krocích.
OpenERP CRM v tomoto systému nabízí mnoho možností. Uživatelsky je velmi pˇrímoˇcaré a efektivní, navigaˇcnˇe pˇresné a graficky zajímavé. Modelový scénáˇr je možno provést ve 4 krocích. Z prezentaˇcního pohledu je velmi povedená správa obchodu˚ pomocí kanbanu.
Tree.io Pˇrístup ke kontaktum ˚ je v hlavní nabídce. Vytváˇrení nových kontaktu˚ ale zabírá více kroku, ˚ než u konkurenˇcních produktu. ˚ Pro pru˚ chod modelovým scénáˇrem je potˇreba 7 kroku. ˚ 82
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Tabulka 7.1: Vyhodnocení obchodního scénáˇre Redmine Tree.io OpenERP Navigace 2 3 1 Obsah 2 3 1 Prezentace 2 3 1 Interakce 2 3 1 Integrace 1 3 2 Knowl. mgmt. 1 2 3 Pˇrístupnost 1 2 3 7.2.2 Projektový scénáˇr Projektový manažer potˇrebuje požádat zamˇestnance, aby vytvoˇril HTML a CSS kód pro novou šablonu v PSD formátu z programu Photoshop. Redmine Tento nástroj je pˇrímo napsaný pro správu vývoje software. Je pomˇernˇe robustní a nabízí široké možnosti úprav a nastavení dle potˇreb projektu˚ a vývojáˇru. ˚ Grafická podoba nástroje je ucházející, ale z pohledu prezentace se nejedná o jednoduchý nástroj. Modelový scénáˇr v nˇem vychází na 6 kroku. ˚ Další nespornou výhodou je zabudování knowledge managementu pˇrímo v Redmine. Je možné zde ke každému projektu ukládat wiki stránky i spravovat diskuzní fóra. Stejnˇe tak je možné systém pomocí rozšíˇrení spojit s DMS systémem pomocí CMIS protokolu. Do Redmine jsou k dispozici pˇrídavky pro podporu kanbanu, nenabízí však takový komfort jako kanban v Trello nebo OpenERP. OpenERP Software je urˇcen primárnˇe pro správu celých podniku, ˚ na rozdíl od Redmine není pˇrímo optimalizován na správu softwarových projektu. ˚ Z grafického a prezentaˇcního pohledu se jedná o povedený nástroj, který pro každý projekt nabízí pˇrehledný kanban. Modelový scénáˇr je možné v nˇem provést na cˇ tyˇri kroky. 83
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Oproti Redmine se jedná o navigaˇcnˇe pˇrívˇetivˇejší a prezentaˇcnˇe pˇrehlednˇejší nástroj. V souˇcasné verzi však naprosto chybí jakýkoliv knowledge management a není k dispozici ani možnost propojení s DMS systémem. Tree.io V této aplikaci není možné modelový scénáˇr provést pˇríliš efektivnˇe, protože Tree.io nepodporuje vkládání souboru˚ pˇrímo k jednotlivým úkolum. ˚ Proto je nutné úkol i dokument vložit zvlášt’ a celá procedura sestává z 9 kroku. ˚ Prezenˇcnˇe je systém na vyšší úrovni než Redmine. Co se týká knowledge managementu systém nabízí možnosti ukládání souboru˚ i editaci jednoduchých textových dokumentu. ˚ Nenabízí ale možnost spojit dokumenty s projekty nebo úkoly. Taktéž není k systému možno pˇrímo pˇripojit žádný externí DMS systém. Trello Ze všech testovaných se jedná o nejefektivnˇejší a nejintuitivnˇejší aplikaci na správu úkolu. ˚ Pro uložení nového úkolu s dokumentem je potˇreba dle naší metriky provést pouze 2 kroky. Z pohledu navigaˇcního, obsahového, prezentaˇcního i interakˇcního se jedná o vynikající produkt. Trello nám nabízí také plnohodnotnou mobilní aplikaci a REST API, pomocí kterého muže ˚ být propojené s dalšími systémy. V systému ale chybí pokroˇcilejší knowledge management pro ukládání dokumentace o projektech a v souˇcasné verzi neumožnuje ˇ ani ukládat cˇ as strávený na úkolech. 7.2.3 Scénáˇr po ukládání dokumentu˚ Alfresco Alfresco je kromˇe správy souboru˚ orientováno i na spolupráci pracovníku. ˚ Pro pˇrístup k souborum ˚ nabízí dvˇe webové rozhraní – starší Alfresco a novˇejší Alfresco Share. Našim potˇrebám více vyhovuje Alfresco Share, v dalším textu se proto zamˇerˇ íme primárnˇe na nˇej. Alfresco Share nabízí každému uživateli možnost pˇrizpusobení ˚ úvodní stránky. V rámci platformy je kromˇe ukládání dokumentu˚ 84
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Tabulka 7.2: Vyhodnocení projektového scénáˇre Trello Redmine Tree.io OpenERP Navigace 1 3 4 2 Obsah 1 2 4 3 Prezentace 1 3 4 2 Interakce 1 3 4 2 Integrace 1 2 3 4 Knowl. mgmt. 4 1 2 3 Pˇrístupnost 1 2 3 4
také možné vytváˇret i fóra a wiki stránky. Tyto možnosti by mohly pˇrinést pozitivní výsledky pˇri práci s OpenERP, které samo o sobˇe knowledge management nemá. Pro spojení se systémem Redmine nebo Tree.io je však tato funkcionalita redundantní. Alfresco nabízí sdílení souborového systému pˇres širokou škálu protokolu˚ (Java RMI, CIFS, WebDAV, FTP, NFS, IMAP, Windows SharePoint Services, vlastní REST). Samotná instalace systému je velice pˇrímoˇcará a po instalaci na servery firmy inQool systém fungoval pˇresnˇe a stabilnˇe bez jakéhokoliv problému. Pomocí aplikace CMIS Sync je možné synchronizovat obsah repozitáˇre s adresáˇrovou strukturou na lokálních discích klientu˚ podobnˇe, jako to nabízí služba Dropbox [3].
Nuxeo Sytém nabízí hned po pˇrihlášení stromovou strukturu dokumentu, ˚ je více orientovaný na samotné soubory než Alfresco. Dále oproti Alfrescu platforma Nuxeo nabízí ménˇe protokolu˚ pro pˇripojení k vnitˇrnímu souborovému systému (Java RMI, CMIS, WebDAV, Windows SharePoint Services, vlastní REST). Systém nabízí i mobilní aplikaci a vlastní rˇ ešení pro synchronizaci dokumentu˚ na discích klientu. ˚ Po instalaci do testovacího provozu na servery firmy inQool se však aplikace neprojevila jako stabilní. Systém padal pravidelnˇe po nˇekolika hodinách. 85
7. Z HODNOCENÍ DOSTUPNÝCH PRODUKT U˚ Hodnocení scénáˇre Pro naše potˇreby se jedná o shodné produkty co se týˇce funkcionality i efektivity práce. Vzhledem k tomu, že na serverech firmy inQool Alfresco Share pracuje výraznˇe stabilnˇeji než Nuxeo, rozhodli jsme se upˇrednostnit systém Alfresco Share.
7.3
Výsledky hodnocení
Ze všech testu˚ vyšlo prumˇ ˚ ernˇe nejhuˇ ˚ re Tree.io, proto se jím nebudeme dále zabývat. Zamˇestnancum ˚ firmy inQool se nejvíce líbil program Trello s mobilní aplikací a kanbanem. Redmine je vhodnˇejší pracovní nástroj pro práci vývojáˇru˚ než OpenERP, které je více orientované na obecnou práci velkých podniku. ˚ Stejnˇe tak absence knowledge managementu dˇelá OpenERP nevhodné pro práci vývojových týmu. ˚ Z pohledu integrace všech služeb do jednoho systému je ideálním rˇ ešením Redmine, protože nabízí kompletní project management, CRM systém, knowledge management a plugin pro spojení s DMS Alfresco. Na druhou stranu projektová práce v Redmine ve srovnání s Trello je výraznˇe ménˇe efektivní (pro testovaný proces 3x) a zamˇestnanci firmy inQool jsou daleko více spokojeni s rychlejším nástrojem Trello. Po jednání s firmou inQool a pˇrednesení všech návrhu˚ jsme vybrali jako nejvhodnˇejší variantu pro její potˇreby spojení systému˚ Trello, Redmine a Alfresco. Systém Trello bude použit pro bˇežnou operativu spojenou s vývojem podle dˇríve definovaných firemních procesu. ˚ Automatickým skriptem se budou všechny úkoly pravidelnˇe zálohovat do Redmine. Stejnˇe tak pomocí skriptu budeme do Redmine ukládat i cˇ as strávený na jednotlivých úkolech. Pro projekty, které vyžadují velké množství dokumentu, ˚ nasadíme Alfresco na jejich správu. Systémy Alfresco i Redmine umožnují ˇ správu uživatelu˚ pomocí LDAP serveru, který ve firmˇe k autentizaci již používají. Každý zamˇestnanec bude mít Trello úˇcet, který se v Redmine spojí s identitou uloženou v LDAP.
86
Kapitola 8
Implementace a nasazení systému V této kapitole se budeme nejprve zabývat spojením systému˚ Redmine a Trello. Poté pˇrejdeme k nasazení aplikace ve firmˇe inQool a zavedení nových pracovních procesu. ˚
8.1
Spojení Trello a Redmine
Aplikace Trello v souˇcasné verzi nepodporuje záznamenávání stráveného cˇ asu u jednotlivých úkolu. ˚ Protože nabízí pˇrehledný kanban, rozhodli jsme se využít jeden sloupec jako automatické stopky. Jakmile pracovník pˇresune kartu s úkolem do sloupce Timer, zaˇcne se mu poˇcítat cˇ as strávený na úkolu, jak je vidˇet na obrázku 8.2. Po pˇresunutí karty do jiného sloupce se strávený cˇ as automaticky uloží do systému Redmine. Pakliže zamˇestnanec pˇri pˇresouvání karet udˇelá chybu, muže ˚ tak vždy pomocí Redmine strávený cˇ as upravit. Tím dostáváme maximální efektivitu pro bˇežné úkoly. Zárovenˇ budou všechny úkoly a projekty (v terminologii Trello „cards“ a „boards“) automaticky synchronizovány s Redmine, aby mˇela firma inQool svoji práci vždy k dispozici na svém serveru a nemusela se s ukládáním dat spoléhat plnˇe na tˇretí stranu. Trello se stane pouze nadstavbou s uživatelským rozhraním nad Redmine. Pokud by služba Trello náhle ukonˇcila cˇ innost, muže ˚ firma inQool dále pokraˇcovat projektovou správu v Redmine pˇresnˇe tam, kde skonˇcila. 87
8. I MPLEMENTACE A NASAZENÍ SYSTÉMU
Obrázek 8.1: Program Trello se sloupcem Timer
8.2
Použité komponenty
8.2.1 Ruby Pro programování skriptu jsme zvolili dynamický objektovˇe orientovaný jazyk s obecným využitím (Ruby, [42]). První verze tohoto jazyka byla vydaná v roce 1995. Jeho syntaxe je ovlivnˇena pˇredevším jazykem Perl a Smalltalk. V souˇcasné dobˇe je jazyk ve verzi 2.0 a pro tuto verzi jsou i optimalizované zdrojové kódy. 8.2.2 Redmine Tento systém jsme již dˇríve rozebírali. Pro jeho plnou funkcionalitu a propojení s ostatními komponentami jsme museli do Redmine doinstalovat další rozšíˇrení. Kompletní popis instalace je uložený v digitální pˇríloze diplomové práce. Cmis for Redmine 2.x je využíván na propojení Redmine s DMS Alfresco pˇres CMIS protokol [11]. Redmine Ldap Sync rozšiˇruje možnosti LDAP synchronizace. Pˇridává možnost pˇresnˇe nastavit jednotlivé položky kontaktu˚ a pˇridávat ke kontaktum ˚ vlastní data. Rozšíˇrení je nutné, 88
8. I MPLEMENTACE A NASAZENÍ SYSTÉMU
Obrázek 8.2: Pojmenování entit v Redmine a Trello abychom v Redmine mohli uchovávat informace o Trello úˇctech zamˇestnancu. ˚ Redmine Contacts pˇredstavuje dˇríve zminované ˇ rozšíˇrení, které umožnuje ˇ vložit do Redmnine CRM systém. 8.2.3 Redis Jedná se o databázi s efektivním ukládáním dvojic klíˇc-hodnota. Redis poprvé vyšel v roce 2009. Je vydáván pod BSD licencí a v soucˇ asné dobˇe vývoj sponzoruje pˇredevším firma VMWare (Redis, [29]). 89
8. I MPLEMENTACE A NASAZENÍ SYSTÉMU Redis kvuli ˚ rychlosti ukládá všechna data primárnˇe do operaˇcní pamˇeti a v pravidelných intervalech si je internˇe zálohuje na pevný disk. Redis nabízí tyto datové struktury: String pˇredstavuje základní typ. Ke každému klíˇci je pˇriˇrazen pouze jeden textový rˇ etˇezec. List slouží pro uložení více hodnot s tím, že každá má své poˇradí a stejné položky se mohou v seznamu opakovat. Set reprezentuje množinu hodnot, pro kterou platí, že nezáleží na poˇradí hodnot a nesmí se opakovat. Sorted set je podobný pˇredchozímu. Jedná se o rˇ azený seznam hodnot. Na poˇradí hodnot záleží, ale stále se v seznamu nesmí opakovat. Hash pod jednu položku ukládá mapování rˇ etˇezcu˚ znaˇcících klíˇce na rˇ etˇezce znaˇcící hodnoty. Tato datová struktura se používá cˇ asto pro reprezentaci objektu. ˚ 8.2.4 Trello API Trello nabízí pˇrístup k datum ˚ založené na REST architektuˇre. V soucˇ asné verzi 1.0 pˇres toto API nabízí informace o všech datových strukturách, které budeme potˇrebovat pro implementaci skriptu [19]. 8.2.5 Redmine API I Redmine nabízí REST API, pˇres které mužeme ˚ upravovat potˇrebné datové struktury. Navíc tím, že je Redmine open source, je možno rozhraní jakkoliv rozšíˇrit. Napˇríklad Redmine API neumožnuje ˇ ukládat záznamy o provedené práci jiného než aktuálnˇe pˇrihlášeného uživatele [39]. Pro naše potˇreby bylo proto nutné zdrojové kódy Redmine upravit. Všechny úpravy jsou k dispozici v digitální pˇríloze diplomové práce. 90
8. I MPLEMENTACE A NASAZENÍ SYSTÉMU
8.3
Implementace skriptu
Pro maximalizování rychlosti bˇeží náš skript na stejném serveru jako Redmine. V pravidelných intervalech se dotazuje aplikace Trello na aktuální stavy boards a cards. Získané informace porovná s daty, která jsou uložená v databázi Redis, a zmˇeny zapíše do Redmine. Když dojde k pˇresunu karty ze sloupce Timer, uloží do Redmine dobu, po kterou karta ve sloupci Timer byla, a tedy dobu, kterou zamˇestnanec na úkolu strávil.
8.4
Nasazení software
Firma inQool pro nasazení IS vyhradila cˇ tyˇri virtuální servery s operaˇcním systémem CentOS. V prubˇ ˚ ehu vybírání optimální softwarové výbavy pro firmu byly na tyto servery nasazeny programy: FengOffice, Redmine, Tree.io, Alfresco, Nuxeo, OpenERP. Všechny instalaˇcní skripty jsou souˇcástí digitální pˇrílohy diplomové práce. Po výbˇeru optimálního softwarového rˇ ešení pro firmu inQool jsme jeden firemní server stanovili jako Ruby platformu a druhý jako Java platformu. Na první jsme nasadili Redmine, Redis a náš skript. Druhý server hostuje systém Alfresco. Redmine jsme spojili s LDAP serverem. Pˇres ten si Redmine pravidelnˇe synchrnonizuje data o zamˇestnancích. Pˇri pˇridání nového zamˇestnance do systému je potˇreba také uložit do Redmine jeho univerzální identifikátor v systému Trello, aby mohl náš skript spojit Trello cˇ innosti se správným Redmine uživatelem. Na závˇer jsme LDAP server spojili i se systémem Alfresco, který ho využívá pˇri autentizaci uživatelu. ˚ Není tedy potˇreba pravidelnˇe synchronizovat data jako v pˇrípadˇe Redmine.
8.5
Pˇrechod firmy inQool na nový systém
Pro úspˇešný pˇrechod jsme se inspirovali dˇríve zmínˇeným systémem kroku˚ vedoucích k úspˇešné zmˇenˇe od J. P. Kottera [26]. Nˇekteré kroky byly jednodušší a ze samé podstaty vˇeci byly spojeny dohromady. Jiné kroky bylo naopak komplikovanˇejší dodržet vzhledem k tomu, že zmˇena byla vedena externˇe nikoliv z vnitˇrku firmy. 91
8. I MPLEMENTACE A NASAZENÍ SYSTÉMU Vyvolání vˇedomí naléhavosti Ve firmˇe inQool si vedení i zamˇestnanci uvˇedomovali neefektivitu souˇcasného zpusobu ˚ práce. Samotný pocit naléhavosti tedy vycházel pˇrímo z vnitra firmy. Tato nálada ve spoleˇcnosti zvýšila otevˇrenost zamˇestnancu˚ pro prezentaci agilních metodik a probírání zpusob ˚ u, ˚ jakými jsou týmy vedeny v konkurenˇcních firmách. Sestavení koalice schopné prosadit a realizovat zmˇeny Koalici, která je schopna prosadit zmˇeny, v tomto pˇrípadˇe pˇredstavovalo celé vedení firmy. Všichni tˇri rˇ editelé museli být ochotni pˇrejít na nový systém. Proto jsme systém v prubˇ ˚ ehu nˇekolika jednání spoleˇcnˇe doladili tak, aby s minimální komplexitou vyhovoval jak obchodu, tak vývoji. Vytvoˇrení a komunikace vize Zmˇenou jsme chtˇeli docílit pˇredevším sjednocení vývoje softwaru ve firmˇe a zavedení jednotného systému pro organizování práce programátoru, ˚ správu digitálního obsahu a ukládání obchodních záznamu. ˚ Hlavním krédem celé zmˇeny bylo zjednodušení práce zamˇestnancum ˚ i vedení, aby se všichni mohli soustˇredit na cíle firmy. Odbourání pˇrekážek Hlavní pˇrekážkou pˇri nasazování nových systému˚ bývá právˇe neochota zamˇestnancu˚ opustit systém starý. Lidé jsou cˇ asto neradi nuceni ke zmˇenˇe a lpí na zavedených systémech. V komunikaci se zamˇestnanci jsme proto neustále poukazovali na zjednodušení práce, uchování informací a výhodu organizovaného vývoje oproti souˇcasnému stylu. Vytváˇrení krátkodobých vítˇezství a využití výsledku˚ Prvním krátkodobým vítˇezstvím bylo zavedení systému Alfresco, díky kterému mˇeli všichni zamˇestnanci k dispozici data potˇrebná k projektum ˚ na jednom místˇe. Zavedení poˇrádku a verzování digitál92
8. I MPLEMENTACE A NASAZENÍ SYSTÉMU ních dokumentu˚ pˇrineslo do firmy duvˇ ˚ eru a pozitivní náhled na naše zmˇeny. Dále následovalo nasazení systému Trello pro všechny projekty a spojení docházky pomocí Redmine. Tato zmˇena byla zamˇestnanci pˇrijata chladnˇeji, protože pro nˇe znamenala vytvoˇrení nového návyku spojeného se zahájením a ukonˇcením práce na úkolech. Vzniklé výhody, které vyplynuly z pˇresné evidence cˇ asu, však nadchly management spoleˇcnosti a rˇ editelé se za zmˇenu plnˇe postavili. Nakonec jsme zavedli novou databázi spoleˇcnˇe s novým pracovním procesem pro obchodní zastoupení firmy. Zakotvení nových pˇrístupu˚ do firemní kultury Všichni zamˇestnanci zaˇcali pracovat na novˇe zavedené platformˇe. Protože jsme cílenˇe hledali takový systém, který bude na ovládání co nejjednodušší, nebyl pro zamˇestnance problém si na celý proces po jednom školení a nˇekolika dnech používání zvyknout.
8.6
Srovnání oproti pˇredchozímu rˇešení
Stanovený KPI je tvoˇren dobou, kterou zamˇestnanci stráví na stránkách s organizaˇcními nástroji. Byly provedeny dvˇe mˇerˇ ení: první týdenní sledování pro starý systém Mantis a druhé týdenní mˇerˇ ení pro nové systémy Trello a Redmine. Jak ukazuje tabulka 8.1 došlo v druhém sledovaném týdnu v pru˚ mˇeru k 20% poklesu cˇ asu, který zamˇestnanci trávili v programech na organizování práce s tím, že jsme pˇridali novou funkcionalitu (mˇerˇ ení cˇ asu stráveného na úkolech). Z tohoto pohledu se nám podaˇrilo naplnit cíl stanovený na zaˇcátku práce.
8.7
Návrhy do budoucna
Systém zjednodušil a zformalizoval základní práci zamˇestnancu˚ ve firmˇe a tím svuj ˚ základní úˇcel splnil. Cesta, kterou se systém bude do budoucna vydávat, je automatizace pravidelných úkonu. ˚ Na základˇe dat o práci, která je vykonávaná, budeme do systému implementovat automatickou fakturaci za odvedenou práci zákazní93
8. I MPLEMENTACE A NASAZENÍ SYSTÉMU Tabulka 8.1: Namˇerˇ ený cˇ as pro každý nástroj v hodinách za týden Zamˇestnanec Mantis Redmine Zlepšení Trello D.H. 4,5 3,8 16% J.H. 5,3 4,0 25% V.M. 6,2 5,4 13% M.S. 2,1 1,9 10% L.T. 4,3 3,2 26% M.T. 1,6 1,1 31% M.V. 4,7 3,5 26% L.K. 2,5 2,0 20% M.K 5,6 4,3 23% Prumˇ ˚ er 4,09 3,24 21% kum ˚ a automatické poˇcítání výplat pro zamˇestnance. Celé vytvoˇrené rˇ ešení je postaveno na open-source technologiích a zdrojové kódy jsou k nalezení na CD pˇríloze.
8.8
Další firmy
Pˇri práci jsme se snažili udržet obecné pˇredpoklady, a proto je rˇ ešení pro organizaci práce, dokumentu˚ a kontaktu˚ stejnˇe tak jako nastavené pracovní procesy možné replikovat do dalších firem, které jsou velikostí a organizaˇcní strukturou podobné firmˇe inQool. Pro nasazení rˇ ešení do dalších firem jsou na pˇriloženém CD pˇripraveny instalaˇcní skripty a návody.
94
Kapitola 9
Závˇer Cílem diplomové práce bylo definovat potˇreby kladené na software pro správu malých nebo stˇrednˇe velkých podniku˚ operujících v IT sektoru a následnˇe najít a upravit vhodné softwarové rˇ ešení. Abychom dokázali efektivitu tohoto rˇ ešení, bylo potˇreba nasadit software ve spoleˇcnosti inQool a.s., jenž spadá do cílové skupiny firem, na nˇež se zamˇerˇ ujeme. Pro nalezení vhodného systému jsme v teoretické cˇ ásti nejprve prošli metody, jakými dnes pracují softwarové týmy. Na tomto teoretickém základˇe jsme pak také definovali potˇreby tˇechto týmu˚ a body, které by mˇel software pro jejich organizaci splnovat. ˇ V praktické cˇ ásti jsme analyzovali souˇcasný stav ve firmˇe inQool a.s. Z teoretického náhledu na softwarové firmy a praktické analýzy ve firmˇe inQool a.s. jsme navrhli a zformalizovali procesy, které bude potˇreba ve firmˇe nastavit. Poté jsme našli softwarové produkty odpovídající stanoveným podmínkám. Ukázalo se, že není k dispozici softwarové rˇ ešení, které by za cenu minimálních nákladu˚ splnovalo ˇ všechny naše požadavky. Proto jsme dostupné produkty upravili, aby odpovídaly naším kritériím. Naše rˇ ešení jsme implementovali a nasadili do firemní infrastruktury. Nakonec jsme ve firmˇe provedli školení zamˇestnancu˚ a zavedli navržené procesy. Zamˇestnanci firmy inQool a.s. nyní s našimi nástroji pracují podle stanovených procesu. ˚ Po nasazení nových programu˚ jsme oproti pˇredchozímu rˇ ešení rozšíˇrili možnosti softwaru a namˇerˇ ili snížení doby, kterou musí zamˇestnanci v organizaˇcních programech trávit. Zavedení zmˇeny tedy probˇehlo úspˇešnˇe. Pro nasazení rˇ ešení do dalších firem jsou na pˇriloženém CD k dispozici instalaˇcní skripty a nové zdrojové kódy. 95
Literatura [1] Kolektiv autoru: ˚ Linux – dokumentaˇcní projekt. Brno: Computer Press, tˇretí vydání, 2003, ISBN 80-7226-761-2. [2] IBM [bez autora]: Agile for Dummies. John Willey and Sons, Inc., 2012, ISBN 978-118-30506-5. [3] CmisSync [bez autora]: Dropbox-like sync for your company’s file server. 2013, [cit. 25-03-2013]. URL [4] 3scale [bez autora]: What is an API? Your Guide to the Internet (R)evolution. 2012, [cit. 01-05-2013]. URL [5] Appelo, J.: Management 3.0: Leading Agile Developers, Developing Agile Leaders. Addison-Wesley Professional, první vydání, 2011, ISBN 978-0321712479. [6] Arkills, B.: LDAP Directories Explained: An Introduction and Analysis. Addison-Wesley Professional, první vydání, 2003, ISBN 978-0201787924. [7] Bhandari, A.; Majmudar, P.; Choudhari, V.: Alfresco Share. Packt Publishing, 2012, ISBN 978-1-84951-710-2. [8] Blanchard, K.; Parisi-Carew, E.: The One Minute Manager Builds High Performing Teams. William Morrow, 2000, ISBN 9780688172152. [9] Bradley, T.: Pros and Cons of Bringing Your Own Device to Work. 2011, [cit. 30-04-2013]. URL
ˇ 9. Z ÁV ER
pros_and_cons_of_byod_bring_your_own_device_ .html> [10] BusinessIT [bez autora]: Podnikové informaˇcní systémy dnes a zítra. 2011. [11] Caruana, D.; Newton, J.; Farman, M.; aj.: Professional Alfresco: Practical Solutions for Enterprise Content Management. Wrox, první vydání, 2010, ISBN 978-0470571040. [12] Centers for Medicare and Medicaid Services, Office of Information Service [bez autora]: Selecting a development approach. 2008, [cit. 20-03-2013]. URL [13] Chapman, M.: SaaS Entrepreneur: The Definitive Guide to Succeeding in Your Cloud Application Business. Aegis Resources, 2012, ISBN 978-0-967200835. [14] Clifton, M.; Dunlap, J.: What Is DSDM? 2003, [cit. 25-03-2013]. URL [15] Cunningham, W.: Manifesto for Agile Software Development. 2001, [cit. 22-03-2013]. URL [16] DiBona, C.: Open Sources 2.0: the continuing evolution. Nabu Press, 2010, ISBN 978-1171648161. [17] Dobrygoski, T.: 10 Useful Google Chrome Extensions to Help You Stay Focus And Be More Efficent. 2010, [cit. 25-03-2013]. URL 97
ˇ 9. Z ÁV ER
[18] Duvall, P. M.; Matyas, S.; Glover, A.: Continuous Integration: Improving Software Quality and Reducing Risk. AddisonWesley, první vydání, 2007, ISBN 978-0321336385. [19] Fog Creek Software [bez autora]: Trello API Documentation. 2013, [cit. 15-04-2013]. URL [20] Gilb, T.: Value-Driven Developlment Principles and Values Agility is the Tool not the Master. Agile Record, 2010. [21] Goddard, P. H.: User Experience Metrix: Connecting the language of UI design with the language of business. Technická zpráva, Human Factors International, Inc., 2008. [22] Henson, M.: The Agile PMO. 1, DSDM Consorcium, 2012, ISBN 0-9544832-5-1. [23] Hiranabe, K.: Kanban Applied to Software Development: from Agile to Lean. 2008, [cit. 25-03-2013]. URL [24] Kampffmeyer, U.: ECM: Enterprise Content Management. Project Consult, 2006, ISBN 978-3-936534-09-2. [25] Ko, R. K. L.; Lee, S. S. G.; Lee, E. W.: Business process management (BPM) standards: a survey. Business Process Management Journal, roˇcník 15, cˇ . 5, 2009: s. 744 – 791, ISSN 1463-7154. [26] Kotter, J. P.: Leading Change. Harvard Business Review Press, první vydání, 1996, ISBN 978-0875847474. [27] Kunstová, R.: Efektivní správa dokumentu. ˚ Co nabízí Enterprise Content Management. Praha: Grada Publishing, první vydání, 2009, ISBN 978-80-247-3257-2. [28] Leuf, B.: The Wiki Way: Quick Collaboration on the Web. Addison-Wesley Professional, 2001, ISBN 978-0201714999. [29] Macedo, T.; Oliveira, F.: Redis Cookbook. O’Reilly Media, 2011, ISBN 978-1449305048. 98
ˇ 9. Z ÁV ER
[30] Marcotte, E.: Responsive Web Design. 2010, [cit. 25-03-2013]. URL [31] Ming, L. M.: A billion dollar software tech company is founded every 3 months in U.S. 2012, [cit. 09-03-2013]. URL [32] Moen, R.; Norman, C.: Taking the First Step with PDCA. 2009, [cit. 12-03-2013]. URL [33] National Instruments [bez autora]: Development Life Cycle Models. 2012, [cit. 10-03-2013]. URL [34] Nayar, V.: Employees First, Customers Second: Turning Conventional Management Upside Down. Harvard Business Review Press, první vydání, 2010, ISBN 978-1422139066. [35] Object Management Group, Inc. [bez autora]: Business Process Model and Notation, v2.0. 2011, [cit. 03-04-2013]. URL [36] Parmenter, D.: Key Performance Indicators: Developing, Implementing,and Using Winning KPIs. Wiley, 2007, ISBN 9780470095881. [37] Perens, B.: The Open Source Definition (Annotated). [cit. 10-032013]. URL [38] Poradenské centrum pro podporu implementace opensource software [bez autora], Praha: Efektivita nasazení Open Source. 2008, [cit. 09-03-2013]. URL 99
ˇ 9. Z ÁV ER
[39] Redmine [bez autora]: Redmine API. 2012, [cit. 11-04-2013]. URL ˇ [40] Rosenau, M. D.: Rízení projektu: ˚ Successful project management. Computer Press, 2000, ISBN 978-80-251-1506-0. [41] Royce, W.: Managing the Development of Large Software Systems. In Proceedings of IEEE WESCON, 1970, s. 328 – 338. [42] RUBY, S.; THOMAS, D.; HANSSON, D. H.: Ruby on Rails: pru˚ vodce agilním vývojem webových aplikací. Brno: Computer Press, první vydání, 2011, ISBN 978-80-251-3647-8. [43] Schwaber, K.; Sutherland, J.: The Scrum Guide. 2011, [cit. 24-032013]. URL [44] Scotland, K.: Aspects of Kanban. Methods & Tools, roˇcník 19, cˇ . 1, 2010, ISSN 1661-402X. [45] Senge, P. M.: The Fifth Discipline: The Art & Practice of The Learning Organization. Random House Business Books, druhé vydání, 2006, ISBN 9781905211203. [46] Sodomka, P.: Informaˇcní systémy v podnikové praxi. Brno: Computer Press, první vydání, 2006, ISBN 80-251-1200-4. [47] Spolsky, J.: The Identity Management Method. 2006, [cit. 25-032013]. URL ˇ [48] Storbacka, K.: Rízení vztahu˚ se zákazníky: Customer relationship management. Praha: Grada, první vydání, 2002, ISBN 807169-813-X.
100
Seznam obrázku˚ 3.1 3.2 3.3 3.4 3.5
Vodopádový model vývoje software 14 Model techniky Scrum 19 Model Sprintu v rámcí techniky Scrum 20 Ukázka kanban tabule, pˇrevzaté z [23] 21 Hierarchie úkolu˚ v Agile kanban 22
5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9
Struktura fimy inQool a.s. 42 Program Mantis BT 44 Program Dropbox 46 Program Google Drive 47 Program CapsuleCRM 48 Model procesu práce na projektu 50 Model procesu Sprint pˇri práci na projektu 51 Model procesu na zaznamenávání chyb pˇri vývoji 52 Model procesu pˇredstavující vznik nového projektu 53 5.10 Model práce obchodního zástupce 54
7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14
Ukázka programu trac 61 Ukázka programu WebIssues 61 Ukázka programu Mantis BT 62 Ukázka programu BugZilla 63 Ukázka programu Redmine 63 Ukázka programu ClockingIT 64 Ukázka programu FengOffice Community Edition 65 Ukázka programu PHProjekt 65 Ukázka programu Codendi Community Edition 66 Ukázka programu Trello 67 Ukázka programu Collabtive 67 Ukázka programu Web2project 68 Ukázka programu XPlanner+ 69 Ukázka programu IceScrum 69 101
ˇ 9. Z ÁV ER
7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 7.23 7.24 7.25 7.26 7.27 7.28 7.29 7.30
Ukázka programu Zimbra 70 Ukázka programu KForge 71 Ukázka programu Launchpad 72 Ukázka programu OpenERP 72 Ukázka programu Tryton 73 Ukázka programu Tree.io 74 Ukázka programu Tactic 75 Ukázka programu ADempiere 75 Ukázka programu LibrePlan 76 Ukázka programu Plandora 77 Ukázka programu Nuxeo 5 78 Ukázka programu Alfresco Share 79 Ukázka programu Zurmo 79 Ukázka programu SplendidCRM 80 Ukázka programu FatFreeCRM 81 Ukázka programu SugarCRM’s Sugar Community Edition 81
8.1 8.2
Program Trello se sloupcem Timer 88 Pojmenování entit v Redmine a Trello 89
102
Seznam tabulek 7.1 7.2
Vyhodnocení obchodního scénáˇre 83 Vyhodnocení projektového scénáˇre 85
8.1
Namˇerˇ ený cˇ as pro každý nástroj v hodinách za týden 94
103
Pˇríloha A
Obsah CD Na pˇriloženém CD se nachází následující adresáˇrová struktura: •
doc/ –
mayer_dp.pdf ∗
•
testovane-systemy/ –
install-treeio.txt ∗
– –
popis instalace pro Nuxeo 5
install-openerp.txt ∗
–
popis instalace pro FengOffice Community 2.2
install-nuxeo.txt ∗
–
popis instalace pro Tree.io
install-fengoffice.txt ∗
popis instalace pro OpenERP 7
pouzite-systemy.pdf ∗
•
text diplomové práce ve formátu PDF
seznam použitých systému˚ s odkazy a pˇrístupovými údaji
vysledne-reseni/ –
alfresco/ ∗
install-alfresco.txt · popis instalace pro Alfresco 4.2 104
A. O BSAH CD –
trelloid/ ∗
–
adresáˇr obsahující Ruby skripty a popis instalace pro periodickou synchronizaci
redmine/ ∗ ∗ ∗
install-redmine.txt · popis instalace pro Redmine 2.3 timelog_controller.rb · upravený soubor pro Redmine 2.3 trelloid/ · adresáˇr s pluginem pro Redmine 2.3 a popisem instalace
105
