Někteří si úkoly zapisují do sešitů či na různé papíry, papírky nebo různobarevné lepící čtverečky, které jsou pak rozesety po pracovním stole, monitoru nebo klávesnici (tak často činí i autor). Jiní na to jdou v dnešní elektronizované době pokrokově a zaznamenávají si požadavky do elektronických dokumentů v počítači nebo si je zapisují a organizují v e-mailové schránce. Ti zdatnější používají různé k tomu určené nástroje dostupné on-line na Internetu. V případě, že je řešitelem úkolů/požadavků skupina více osob, je poslední jmenovaná možnost téměř nutností. O sběru požadavků v takovém nástroji vyvíjeném v rámci informačního systému Inet MU je tento článek.
Abychom si odpověděli na otázku, v čem nám (obecně) nástroje pro sběr požadavků mohou pomoci, uveďme si modelový příklad z praxe ÚVT - z vývoje a provozu Inetu a také ekonomického informačního systému firmy Magion (EIS Magion). Uživatelé se na provozní tým denně obracejí s žádostmi o pomoc při řešení problémů s aplikacemi, o přidělení práv, o zjištění či upřesnění informací z jednotlivých agend nebo jen o radu, jak postupovat při práci v jednom či druhém informačním systému. Běžnou, a také dříve hojně využívanou cestou, byla e-mailová komunikace, která má však v našem asi 20členném týmu svá úskalí.
I přes zavedení skupinových aliasů se uživatelé často e-mailem obracejí přímo na konkrétní osobu, jejíž případná nepřítomnost vyřešení problému neúměrně prodlužuje. I skupinové aliasy mají svá úskalí: Stane se, že je řešení požadavku započato více vývojáři zároveň, nebo naopak vývojáři spoléhají jeden na druhého a řešení požadavku stojí. Špatně adresované zprávy (na špatný alias nebo osobu) nebo předání řešení jinému vývojáři se řeší přeposíláním e-mailů ze schránky do schránky, a tím narůstá pracnost a čas.
Shrneme-li výše popsané, pak komunikace a informace o řešení jednoho požadavku může být distribuována ve více e-mailech a mezi více e-mailových schránek. Zvládnout takový proces řízení - kdo má problém řešit, jestli je již řešen nebo vyřešen, a zda je zadavateli korektně odpovězeno - je značně obtížné. Systémy pro sběr požadavků, pokud jsou správně používány, nám mohou účinně pomoci tyto obtíže zvládat.
V Inetu je již od roku 2004 v provozu aplikace pro sběr požadavků na změnu dat v telefonní ústředně, kterou využívají správci na součástech univerzity na straně zadavatelů, a dvě oddělení ÚVT jako řešitelé. O něco později vznikla aplikace pro sběr požadavků na změnu práv ve zmiňovaném EIS Magion. Obě aplikace byly šity na míru daným potřebám, a nedaly se tak použít pro jiné účely.
Prvotními impulzy pro zavedení obecného požadavkového systému v rámci Inetu byla žádost správců IT z lékařské fakulty (kteří si podobnou aplikaci vytvořili sami, ale nechtěli ji už více rozvíjet a udržovat) a také obtížně udržitelný stav řešení úkolů a požadavků v našem týmu vývojářů. Nejdříve jsme hledali volně dostupné již hotové řešení, které by vyhovovalo našim potřebám a bylo do Inetu snadno včlenitelné, abychom mohli využít potenciálních uživatelů a nám dostupných dat (personalistika, ekonomika, provoz a správa). V hledání jsme však neuspěli, a tak nezbylo, než se pustit do vývoje vlastními silami.
Využili jsme idejí ze školní seminární práce tehdejších našich dvou dohodářů Pavla Budíka a Martina Jakubičky, a vývoj pilotní verze systému později zadali jako diplomovou práci pro Juraje Skubáka. Výsledek diplomové práce byl nasazen, a také studentem úspěšně obhájen, ale k dnešnímu stavu vedla ještě dlouhá cesta, kdy se systém upravoval, přepracovával a zobecňoval, aby dostal žádané vlastnosti, které si popíšeme dále. Hned na počátku však zdůrazněme, že naším cílem nebylo vytvořit ani systém pro vývoj softwaru, ani systém pro řízení týmových projektů, které mají mnoho společných rysů, ale metodicky jsou lépe zvládnuty v existujících komerčních i bezplatných aplikacích.
Aby se čtenář neztratil v pouhém výčtu technických vlastností, rozdělíme si je do několika logických celků, a pokud to bude možné, popíšeme v ukázkách na našem modelovém příkladě.
Osoby jsou přebírány z centrální evidence MU, tj. z personálního a studijního systému, a pro definování jejich skupin byla využita existující komponenta používaná v jiných subsystémech Inetu. V jedné instanci požadavkového systému je možné použít neomezené množství skupin, které mohou být definovány jako:
Příkladem skupin v požadavkovém systému mohou být např. zadavatelé, možní řešitelé nebo "dohlížitelé" - odpovědné osoby. Mimo pevně zadané skupiny jsou v systému také dynamické skupiny odvozené od konkrétního požadavku: např. jeho zadavatel, přiřazený řešitel nebo výběr skupiny podle hodnoty některého z atributů.
Základem každého požadavku či úkolu jsou informace o něm. Některé jsou společné všem typům použití (instancím systému), např. kdo požadavek zadal a kdy, identifikace požadavku atd. Jiné údaje se velmi různí pro různé instance, například: popis a priorita požadavku, příloha, řešitelé a jejich komentáře atd. Systém tak pro každou instanci definuje seznam tzv. atributů, tj. seznam údajů, jejich datových typů a také omezení. Např. popis problému je text o maximální délce 4 000 znaků, priorita je pevný seznam položek, ze kterých si uživatel povinně vybírá, řešitelem je osoba z definované skupiny (viz výše). Mezi základní typy patří:
Nový datový typ však může být do systému s určitou námahou přidán. K dispozici je také datový typ sdružující atributy do větších celků (např. adresa bydliště se může skládat z obce, ulice, č. popisného a PSČ) a také typ pro násobné uložení různých hodnot atributů (např. více příloh, více osob, ale také v kombinaci s předchozím - více adres).
Možná omezení rozsahu hodnot jsou různá podle datového typu:
Systém tedy zajišťuje kontrolu a správné ukládání dat podle definice atributu. Žádný ze zadaných údajů se při změně hodnoty nepřepisuje; vše je uchováno historicky, a je tak možné se zpětně podívat, jak a kdo požadavek v čase měnil. U některých položek je však žádoucí vidět ihned všechny uložené hodnoty - typickým příkladem jsou komentáře řešitelů v interní komunikaci.
Požadavky nejsou neměnné a během svého životního cyklu procházejí různými stavy. V našem modelovém případě je požadavek na počátku ve stavu založený, poté je převzat, řešen, vyřešen, a nakonec je potvrzena správnost řešení. Nad seznamem stavů je definován workflow, tj. zda je z jednoho stavu pro vybranou skupinu osob povoleno přejít do stavu druhého. Ve výše popisované aplikaci pro telefonii na MU se ukázala potřeba mít v dané instanci více nezávislých workflow, a tedy i více seznamů stavů, protože stavy řešení pro obě skupiny řešitelů jsou vzájemně nezávislé. V systému nejsou omezeny ani počet stavů ani možné přechody.
Dáme-li předchozí tři části systému dohromady, určíme tím pro každou trojici [skupina osob × stav každého workflow × atribut], zda je/není hodnota atributu vidět nebo zda je možné/povinné hodnotu vyplnit či změnit. Ukázka nastavení práv modelového příkladu v našem editoru je vidět na obrázku 1.
V editoru je například vidět, že při uzavření požadavku již není možné data kýmkoliv měnit (pouze číst - R), interní komunikaci mohou (CW) vyplňovat pouze administrátoři či řešitelé, zadavatel musí vyplnit popis (MW) nebo administrátor může změnit kategorii, ale musí být vyplněna (CMW).
Nesmíme také zapomenout na informování uživatelů o vzniku a změnách požadavku. Pro větší flexibilitu lze v instanci systému povolit posílání e-mailových upozornění buď při změně stavu, nebo při změně hodnoty kteréhokoliv atributu - samozřejmě pro každou skupinu osob zvlášť. Obsah e-mailu je pak dán vybranou šablonou (pevné i proměnlivé texty a jejich rozmístění) a také výběrem atributů, které se v něm mají zobrazit.
V předchozích částech jsme si popsali vlastnosti našeho systému, ale chybí nám celkový pohled na něj. Každá instance systému je rozdělena do 3 záložek; na první jsou seznamy požadavků, na druhé detail a na třetí vyhledávání požadavků. Na přání je však možné přidat i další záložky se specifickými údaji. Při vstupu do aplikace systém zkontroluje, zda je přihlášený uživatel alespoň v jedné ze skupin oprávněných osob, a v každé ze záložek pak zobrazuje jen ty informace, na něž má uživatel právo. Ukázky uživatelského rozhraní jsou na obrázcích 2 a 3.
První (vstupní) záložka může obsahovat několik seznamů požadavků nalezených podle zadaných kritérií a práv. Mohou to být např. seznamy mnou zadaných, mnou řešených nebo posledních 10 vyřešených požadavků. Počet a kritéria jsou pro každou instanci volitelná a volitelné jsou také zobrazené atributy pro každý požadavek. U každé položky v seznamu je odkaz na detail. Druhá záložka slouží pro zadávání nových a také editaci a zobrazení detailu a historie již existujících požadavků. A konečně na třetí záložce lze hledat požadavky podle zadaných hodnot atributů.
Námi popisovaný modelový případ jsme implementovali a zpřístupnili v menu Inetu jako Požadavkový systém uživatelské podpory Inetu (zkráceně iHelp), na nějž vedou odkazy z každé aplikační stránky (zápatí vpravo). Přímo z aplikace tedy může každý uživatel zadat svůj požadavek na poskytnutí pomoci. Jediné, co je nutné vyplnit (podobně jako v e-mailu), je název, popis, kategorie a priorita problému či úkolu, a případně přiložit soubor ve formě přílohy.
V době psaní tohoto článku jsou v Inetu k dispozici tyto instance požadavkového systému:
objednávky tisku velkoformátových posterů v ÚVT - ukázka této nejsložitější implementace je na obrázku 4 (více posterů s rozdílným nastavením tisku, při výběru platby přes systém SUPO kontrola na existenci a platnost účtu, a odhad výsledné ceny podle plochy pokrytí).
V přípravě je dále systém pro požadavky na elektronické podepisování dokumentů (s externí aplikací usnadňující celý proces podepisování), a systém pro sběr a evidenci požadavků resp. problémů týkajících se EIS Magion, z nichž druhý jmenovaný je určen nejen pro potřeby MU, ale také ostatních vysokých škol provozujících stejný ekonomický informační systém.
V předchozím textu jsme se pokusili ukázat možnosti a komplexnost celého systému a jsme otevření implementacím dalších instancí pro potřeby zaměstnanců univerzity. Případní zájemci se mohou obracet na e-mailovou adresu inet@ics.muni.cz.
předchozí článek
