A DOTPROJECT ALKALMAZÁS HASZNÁLATÁNAK TAPASZTALATAI ÉS LEHETŐSÉGEI A DEBRECENI EGYETEM KÖZGAZDASÁGTUDOMÁNYI KARÁNAK MENEDZSMENT ÉS MARKETING TANSZÉKÉN

Informatika a felsőoktatásban 2008

Debrecen, 2008. augusztus 27-29.

A DOTPROJECT ALKALMAZÁS HASZNÁLATÁNAK TAPASZTALATAI ÉS LEHETŐSÉGEI A DEBRECENI EGYETEM KÖZGAZDASÁGTUDOMÁNYI KARÁNAK MENEDZSMENT ÉS MARKETING TANSZÉKÉN EXPERIENCES AND PERSPECTIVES IN THE USE OF THE APPLICATION DOTPROJECT AT THE DEPARTMENT OF MANAGEMENT AND MARKETING OF THE UNIVERSITY OF DEBRECEN FACULTY OF ECONOMICS AND BUSINESS ADMINISTRATION 1,2

Kun András István1, Siklós Balázs2 Debreceni Egyetem Közgazdaságtudományi Kar Menedzsment és Marketing Tanszék Összefoglaló

A Debreceni Egyetem Közgazdaságtudományi Karának Menedzsment és Marketing Tanszékének oktatói és hallgatói a 2006/2007-es tanév két félévében a tanszéken működő kutatócsoportok és pályázatok, valamint egy tantárgy menedzseléséhez használták a dotProject nyílt forráskódú projektmenedzsment szoftvert. Az alkalmazás használata során több nehézség, probléma is felmerült, melyek rávilágítottak arra, hogy az alkalmazás lehetőségei csak bizonyos feltételek megléte esetén használhatóak ki, illetve felhívták a figyelmet a dotProject néhány hiányosságára is. Az előadás első felében ezeket a problémákat és szükséges feltételeket mutatjuk be, a második felében pedig javaslatot teszünk arra, hogyan könnyítheti meg a vizsgált vagy ahhoz hasonló alkalmazás egy teljes tanszék (példánkban a Debreceni Egyetem Közgazdaságtudományi Karának Menedzsment és Marketing Tanszéke) munkáját.

Kulcsszavak projektmenedzsment, kutatásmenedzsment, menedzsment-rendszer

Abstract The staff and students of the Department of Management and Marketing at the University of Debrecen Faculty of Economics and Business Administration used the open source project management system dotProject for managing research teams, applications and a course. While using the application, several difficulties and problems emerged which showed that the features of the application can only be utilized under certain circumstances. Besides, it pointed out some shortcomings of the software. In the first half of our presentation, we are going to point out these problems and conditions, while in the second part we will make some suggestions on potential fields, where the software in question or a similar one can make the work of a department (in our case the Department of Management and Marketing at the University of Debrecen Faculty of Economics and Business Administration) easier.

Keywords project management, research management, project management system

1



1. Bevezetés Nem lévén informatikusok, az előadásunkban bemutatott informatikai megoldás – egy projektmenedzsment támogató szoftver – felhasználói oldalon szerzett tapasztalatait mutatjuk be, szándékunk szerint olyan formában, hogy mind a hasonló informatikai igénnyel fellépő felhasználók, mind a hasonló alkalmazások fejlesztésével foglalkozók számára hasznos és ötletadó legyen. A Debreceni Egyetem Közgazdaságtudományi Karának Menedzsment és Marketing Tanszékén 2006/2007-es tanév első szemeszterében a tanszéki tevékenység egyfajta innovációjaként megpróbáltunk néhány tevékenységet projektmenedzsment alapokra helyezni és ennek kialakításához, menedzseléséhez egy erre alkalmas szoftvert segítségül hívni. Ez a dotProject nevű nyílt forráskódú, ingyenes szoftver volt (http://dotproject.net/). Az alkalmazást egy féléven keresztül használtuk, jó és rossz tapasztalatokat szereztünk, a felhasználás területét megpróbáltuk kiterjeszteni, míg végül használatát megszüntettük. Ennek okait, folyamatait és a levonható következtetéseket mutatjuk be, esettanulmány formájában. Az első részben röviden ismertetjük a porjektmenedzsment rendszerű szervezésimenedzselési kihívásokat, ezáltal hátteret adva a felmerült problémák és a meghozott döntések értékeléséhez. Kitérünk az alkalmazás ismertetésére, itt is a főbb, általánosítható vonalakat megragadva, és ezzel összefüggésben tömören bemutatjuk a nyílt forráskódú szoftverek technikai/technológiai/gazdasági fejlődésben játszott szerepét (3.1. alfejezet). Ezt követően bemutatjuk azokat a problémákat, melyek megoldásához segítséget vártunk a programtól, a vele való munka főbb jellemzőit, majd összefoglaljuk azokat a tanulságokat, melyek véleményünk szerint általánosíthatóak a miénkkel rokon helyzetekre, illetve más, hasonló szoftverekre is. 2. A projektmenedzsment mint szervezési-menedzselési forma A szervezetek – és a szervezeti alrendszerek, mint esetünkben egy tanszék – tevékenységét nem csak olyan feladatok alkotják, melyek a rendszeres „üzletmenethez” tartoznak. Egyes célok elérése megkívánja az újszerű, egyedi, nem ismétlődő, időben behatárolt feladatok elvégzését is. Jellemzően ilyenek a beruházások, de ilyen a tipikus kutatómunka is, sőt, gyakran a hagyományos tevékenységek is „projektesíthetők”, mi ilyennel is próbálkoztunk, bár esetünkbe ennek sikere elmaradt. A projekt fogalma olyan tevékenységet takar, amely (Görög, 2001): 

időben behatárolt,



egyszeri és komplex (egyedi output létrehozására irányul),



meghatározott költségvetéssel rendelkezik.

Időbeli behatároltságon azt értjük, hogy egyértelműen meghatározható a projekt kezdete és vége. A projekt vége jó esetben a célkitűzések elérését jelent, rossz esetben pedig annak nyilvánvalóvá válásakor következik be, hogy a célok már nem, vagy csak nem vállalható többletráfordítások mellett teljesíthetőek. A projekt tervezési szakaszában a projekt végének időpontját természetesen a célok teljesüléséhez kell igazítani. A projekt időbeli végessége az általa létrehozott outputra már nem szükségképpen jellemző, gondoljunk csak az új tudományos eredmények esetére.

2



A projekt által létrehozott output lehet termék, szolgáltatás, épület, új szervezeti struktúra, tudományos felfedezés vagy bármilyen más egyértelműen meghatározható eredmény. Ennek egyedisége azt jelenti, hogy a tervezés és megvalósítás során jelentősek az olyan tényezők, melyek újszerűek, nem létezik a kezelésükre kialakult gyakorlat. Azonban ezek mellett a projekt tartalmazhat ismétlődő elemeket vagy rutinszerűen kezelhető feladatokat is. A projekt egészére azonban mindig jellemző az egyediség. A projektmenedzsment során nem feledkezhetünk meg arról, hogy sem az egyes projekteket, sem a projektek egyes részeit nem szabad önmagában álló, független egységként kezelnünk. A szervezet vagy munkacsoport stratégiájának megvalósítása szempontjából e tevékenységek és folyamatok egységes keretben való kezelése, a kölcsönhatások figyelembevétele elengedhetetlen. A fenti cél eléréséért a tervezés és a megvalósítás során mindig a 1. stratégiai tervezés – 2. projekt-portfólió – 3. program – 4. projekt – 5. alprojekt hierarchiában kell gondolkodni a döntéshozóknak (PMBOK® Guide, 2006). Azaz a projektek és az azokból álló programok a stratégiai célfeladatokból származnak, azokat hivatottak megvalósítani. A stratégia esetünkben olyan viszonylag hosszú távú célt, célrendszert jelent, amely már tartalmaz mérhető célokat, sarokszámokat, de még kellőképpen általános is ahhoz, hogy ezek elérése több úton is megvalósítható legyen. Programoknak nevezzük az egymással kapcsolatban álló projektek és a projekteken kívül álló (rész)feladatok olyan csoportjait, melyeket egymással koordinált módon menedzselnek szinergikus előnyök elérése céljából. A szinergia megjelenhet mind a projektek megvalósításában, mind az irányítás területén. Projekt-portfólió alatt projektekből, programokból és egyéb tevékenységekből álló olyan halmazokat értünk, melyeket valamilyen célból hasznos együtt kezelni (ilyen cél lehet akár az adminisztrációs költségek csökkentése, de a tevékenységek földrajzi elvű elkülönítése is, vagy bármi más). Az egy portfólióba tartozó elemek azonban nem állnak olyan szoros kapcsolatban, mint az egy programba tartozó projektek és feladatok, sőt, egymástól függetlenek is lehetnek. Tipikusan ilyen portfólióképző ismérv lehet az egy tanszékhez kapcsolódó, más szempontok szerint heterogén tevékenységek együttes kezelése. Az alprojektek (vagy részprojektek) a projektek olyan összetevői, melyek önmagukban is kezelhetők projektként. A nagyobb projektek alprojektjei gyakran további alprojektekre bonthatók. A projektmenedzsment mint menedzselési, szervezési forma röviden azt jelenti, hogy (PMBOK® Guide, 2006) a projektmenedzsment-folyamatokat – kezdeményezés, tervezés, végrehajtás, követés és ellenőrzés (monitoring), lezárás – és a projektmenedzsment eszköztárát használjuk fel valamely folyamatok irányítására. Ezt szokás „projektszerű irányításnak” is nevezni, és kényszerűen együtt kell járjon a projektszervezetekre jellemző szervezeti kultúra meglétével. A projektmenedzsment a szervezeti kultúrával szemben a következő követelményeket támasztja (ezekkel az értékekkel kell rendelkezzen a szervezet) (Verzuh, 2006): csoportidentitás (csoportmunka, közös problémamegoldás), felelősségvállalás, teljesítményorinetáció, változás elfogadása (nyitottság, aktivitás), folyamatos tanulás, támogató vezetés. Látható tehát, hogyha a szoft tényezőktől el is tekintünk (szervezeti kultúra), akkor is meglehetősen sok elvárást támaszt a jó projektmenedzsment rendszer kialakítása a szervezetekkel szemben. A folyamatos és részletes tervezés, a többszintű egymásraépülés, a

3



monitoring-rendszer, a projekt-portfoliók együttes kezelése mind-mind olyan területek, ahol a számítógépes alkalmazások jelentős könnyebbséget jelenthetnek. Legalábbis első ránézésre. 3. A dotProject szoftver választásának elvei A programnak a mi szempontunkból legfőbb tulajdonságait három csoportba lehet sorolni: 1. ingyenes 2. szabad forráskódú 3. hasonlóság a zárt forráskódú projektmenedzsment szoftverekhez Az első, hogy a rendszer ingyenesen hozzáférhető, korlátozás nélkül használható. Az ingyenesség több szempontból is fontos volt. Egyrészt amiatt, hogy a rendszer bevezetése kísérleti jelleggel történt, hogy megtudjuk, valóban képesek vagyunk-e külső segítség nélkül projektmenedzsmet alapokra helyezni a tevékenységünket, ehhez egy komplett projektmenedzsment rendszert felépíteni és saját igényeinkhez szabni, valamint hogy kiderüljön, használható-e a futó projektjeink esetében a program, jelent-e költség- és időmegtakarítást munkánk során. A másik szempont, ami miatt az ingyenesség fontos volt, az a Tanszék korlátozott költségvetéséből adódik. Abban az esetben ugyanis, ha akár szélsőségesen pozitív eredményre jutottunk is volna, sem valószínű, hogy Tanszékünk pénzt áldozott volna egy zárt forrású alkalmazás licencének megvásárlására és periodikus megújítására. Ezzel a választásunkkal tehát még optimális esetet figyelembe véve is megspóroltuk az átállási költségeket és egy esetleges lock-in hatást. A program másik fontos tulajdonsága annak szabad szoftver volta. Az alkalmazás tehát szabadon módosítható, fejleszthető, bővíthető, illetve testre szabható. Ez a lehetőség a mi esetünkben természetesen közvetlenül nem jelentett hasznot, hiszen a rendszert működtető team egyetlen tagja sem volt annyira járatos a programozásban, hogy a fejlesztésben részt tudott volna vállalni, a nyílt forráskód viszont azt is jelentette, hogy nálunk nagyobb tapasztalattal rendelkező fejlesztői csoportok rendszeresen jelentettek meg frissítéseket, újításokat, testre szabott funkciókat, amelyek minden felhasználó számára – így nekünk is – elérhetővé tettek. Ezáltal biztosítva volt a rendszeres update, amely mind használati, mind biztonsági szempontból nagy fontossággal bír. A nyílt forráskódú program ezen felül kisebb valószínűséggel tartalmaz olyan kódrészletet, amely a felhasználó által elérni nem kívánt célokat szolgál, hiszen számos, egymástól független fejlesztő lát bele a program kódjába, és vesz észre egy ilyen próbálkozást. A program harmadik fontos tulajdonsága, hogy kezelése és funkciói szinte teljesen megegyeznek más, kötött licencű versenytársai által kínált tulajdonságokkal. Ez egyrészt megkönnyít egy esetleges adatmigrációt, másrészt pedig kevésbé érezteti lock-in hatását, ha idővel át kell állni egy másik rendszerre. Abban az esetben pedig, ha egy felhasználónak már volt tapasztalata egyéb, projektmenedzsmentet támogató szoftverekkel, akkor feltehetőleg nem okoz nehézséget számára az átállás. Természetesen nem mondhatjuk, hogy az általunk használt program „cutting edge”, azaz a legújabb, legutolsó innovatív technológiát felvonultató alkalmazás lenne, de mindent tud, amit a „nagyok”, s ráadásul mindezt ingyenesen teszi. A 3.1 alfejezetben rövid összefoglalást nyújtunk a nyílt forráskódú szofverek gazdasági fejlődésben játszott szerepéről, majd a következő fejezetben áttekintjük a program

4



legfontosabb funkcióit, különös hangsúlyt fektetve ezen funkciók számunkra is kézzelfogható hasznára. 3.1. A nyílt forráskódú szofverek szerepe az innováció támogatásában A szabad forráskódú szoftverek történelme 1984-ig nyúlik vissza, amikor Richard Stallmann megalkotta a GNU-t, a UNIX operációs rendszer egy nyílt forráskódú változatát. Érvelése szerint ugyanis a szoftverek forráskódjának törvény általi levédése, szabadalma gátat szab a felhasználók szabadságának a termék használatában és módosításában. Az ez elleni tiltakozásul megalapította az FSF-et, a Szabad Szoftver Alapítványt, mely célul tűzte ki a nyílt forráskódú szoftverek elterjedésének elősegítését. A szabad forráskódú szoftverek az úgynevezett copylefting elv szerint készülnek, mely nem korlátozza a felhasználót a program használatában, terjesztésében vagy módosításában. Egyetlen kikötés van csupán: a programot a forráskóddal együtt nyilvánosan elérhetővé kell tenni. A zárt forrású, kereskedelmi szoftverekhez képest gyors kiadási ciklusokkal bírnak, azaz a programok újabb, javított változatainak megjelenése nagyságrendekkel gyakoribb, mint az utóbbiak esetében. A javított verziót általában az interneten teszik közzé, ahonnan bárki letöltheti, tesztelheti, illetve a forráskódban meglévő kreatív ötleteket szabadon felhasználhatja, az esetleges hibákat kijavíthatja, illetve jelezheti a szerző felé, majd a javított verziót a világhálón elérhetővé téve újra lehetővé válik bárki számára az – immár továbbfejlesztett – program letöltése. A fejlesztések és innovációk tehát felhalmozódnak az éppen aktuális verziójú kiadásban, és a gyors megjelenési ciklusoknak köszönhetően egyetlen fejlesztő sem szembesül magas elsüllyedt költségekkel, amikor valaki megoldást talál arra a problémára, amellyel azelőtt egyszerre többen foglalkoztak, ellenben azonnal hasznosíthatja a mások által kitalált megoldásokat. Ezek a tulajdonságok rendkívül hatékonnyá teszik a szabad szoftverek fejlesztését, és nagymértékben elősegítették terjedésüket. 4. A dotProject rendszer jellemzői A dotProject nyílt forráskódú projektmenedzsment szoftver első verziója dotMarketing.org néven 2000-ben jelent meg a hasonló funkciót ellátó Microsoft, és egyéb kötött licencű termékek ingyenes alternatívájaként. A program 2005-ben nyerte el jelenlegi nevét, a dotProject.org-ot. Felhasználói menedzsment: A dotProject.org rendszer adminisztrátori jogosultságú felhasználójának lehetősége van különböző felhasználói fiókok létrehozására, amelyeket értelemszerűen a projektben résztvevő munkatársakhoz lehet rendelni. A különböző felhasználókhoz pontosan meghatározott jogköröket lehet rendelni, így biztosítva azt, hogy mindenki csak azokhoz az adatokhoz férhessen hozzá, amelyek a projektben betöltött szerepe folytán számára fontosak, illetve azt, hogy az egyes felhasználók csak olyan műveleteket végezhessenek el a rendszeren belül, amilyeneket az adminisztrátor jónak lát engedélyezni. A felhasználók így pontosan tisztában lesznek azzal, hogy mi a feladatuk és meddig terjed ki a hatáskörük, a projekt vezetői pedig láthatják, hogy mi az, amit számonkérhetnek az adott munkatárstól és mit nem. Projekt áttekintés: A dotProject.org rendszer természetesen nem csak egyetlen projektet tud kezelni, hanem számos, egymással párhuzamosan futó projekt feladatait is képes

5



rendszerezni, sőt, a párhuzamosan futó projektek egymásra gyakorolt hatását is kezeli. Egy kiválasztott projektet megvizsgálva információt nyerhetünk a legfontosabb adatokról, a projektben résztvevő személyekről, azok jog- és felelősségi köréről, lekérdezhetjük a projekteken belül futó esetleges alprojektek főbb adatait is. Ez a pont nyújt információt a soron következő és a már elvégzett teendőkről is, valamint innen tájékozódhatunk az eredményekről. Hierarchikus feladatlista: Minden projekt egy sor hierarchikusan rendezett, egymásra épülő feladatból áll. Ezek a feladatok egy része gyakorlatilag független egymástól, ezek a teendők egymással párhuzamosan is futhatnak akár, de vannak olyan feladatok is, amelyek inputot szolgáltatnak egy későbbi munkához, vagy ellenkezőleg, egy másik feladat eredményeire van szükségük ahhoz, hogy el lehessen őket végezni. Ezeket a függőségeket nem egyszerű kezelni, ám a dotProject.org rendszer biztosítja, hogy a feladatokat a megfelelő sorrendben végezzék el, figyeli a teendők egymásra épülését, és hiba esetén jelzést küld a felhasználónak, felhívva figyelmét a teendők átstrukturálására. File-tárhely: A dotProject.org rendszer lehetővé teszi, hogy az egyes prjektekhez, alprojektekhez és feladatokhoz külön közös tárhelyet rendeljünk, amelyet a felhasználók jogosultságaik pontos meghatározása mellett közösen használhatnak. Ezáltal elkerülhetővé válik az a kevéssé hatékony megoldás, amikor mindenki e-mailben küldi el saját hozzájárulását az összes többi, projektben résztvevő személynek. A közös tárhely kevésbé terheli a hálózatot, bár nyilván megfelelő tároló kapacitásra van szükség a hatékony munkához. Ez a megoldás mindezek mellett egyértelművé teszi a file-történetet is: minden anyagnak a legújabb verziója érhető el a közös tárhelyen, és a naplóban pontosan nyomon követhető, ki, mikor, mit változtatott a dokumentumon. Kapcsolati lista: A projektban résztvevő munkatársak a kapcsolati lista segítségével mindig egyszerűen elérhetik azt a kollégát, akire épp szükségük van adott feladat elvégzéséhez. A kapcsolati listában szereplő személyek szintén projekthez rendeltek, így bárki számára egyszerűen átlátható, ki az, aki adott témában megkereshető. Az elérhetőség mellett természetesen egyéb fontos szakmai és személyes adatok is feltüntethetők a listában, amelyek számos esetben nyújthatnak hasznos információt. Naptár: Az alkalmazás tartalmaz egy naptár-funkciót is, ahol a projektekben résztvevő munkatársak mindegyike nyomon követheti a munka aktuális állását, az elvégzett, az aktuális, illetve a jövőbeni feladatokat. A jogosultságok itt is meghatározzák, ki melyik projekt adatait láthatja. A naptár tetszőleges részletességgel kérdezhető le, napi, heti, havi és éves lebontásban is áttekinthetjük projektjeink állását. Vitafórum: A dotProject.org rendszer központosított, hatékonyabb, jobban strukturált alternatíváját kínálja a korábban körlevelekkel megoldott kapcsolattartásnak. A vitafórumok tetszőleges projektek tetszőleges témáira strukturálható, sőt, projekteken átívelő témákra épülő fórumok is indíthatóak. A felhasználói jogosultságok erre a funkcióra is vonatkoznak, azaz mindenki csak azon témákhoz szólhat hozzá, amelyeket felhasználói jogosultságai lehetővé tesznek. 5. Hogyan használtuk mi a dotProjectet? Két elkülöníthető területen szereztünk tapasztalatokat a dotProject és tanszékünk viszonyát illetően. A szoftvert elsősorban egy felsőoktatási és kari marketingkutatással foglalkozó, oktatókból, nappali tagozatos PhD és egyetemi hallgatókból álló, kilenctagú csoport (mely

6



szándékaink szerint projekt-team formában működött volna) folyamatos, jól megtervezett, körülhatárolt célokkal felruházott tevékenységének koordinálására, szervezésére, a csoportkommunikáció megkönnyítésére használtuk volna (első terület: projekt-koordináció). Ez az, amire a szoftver elsősorban készült. A kezdeti tapasztalatok azonban azt mutatták, ennél többre is használható lenne. Megpróbálkoztunk tehát egyes tantárgyak féléves munkálatainak szervezésére is: egyrészt egy munkafüzet elkészítéséhez (ami projektszerű folyamat), másrészt pedig a normál óratartási-tananyagfejlesztési tevékenységekhez (ami nem rendelkezik a projektek jellemzőivel) (második terület: hagyományos tanszéki folyamatok segítése). A tanszék két munkatársának már volt korábbi tapasztalata az alkalmazás más projekt menedzselésére való felhasználásáról erre azonban nem térünk ki, hiszen itt a szervezést nem mi végeztük (az operatív koordinációt Mazsu Gergely végezte, akinek ezúton is köszönetünket fejezzük ki a szoftverrel való megismerkedésért), így tapasztalataink egyrészt korlátosak, másrészt amelyeket mégis szereztünk, azok nagyjából egybevágnak a fenti két területen szerzettekkel. 5.1. Projekt-koordinációs tapasztalatok A projekt-team hierarchiájából következően (az oktatók irányító feladatot láttak el, illetve értékelték is a hallgatók munkáját) úgy gondoltuk, szelektálni fogjuk a jogokat. Ehhez először is minden tagot regisztráltunk (users), kitöltettük velük a különböző személyes adatokat. A dotProject egyik nagy előnyének éreztük, hogy így nyilvántartásra kerül és mindig visszakereshető a tagok többféle elérhetősége és pontos szerepe, helye a különböző projektekben. Ezek után az adminisztrátori jogokkal felruházott oktatók közül valaki beállította a hallgatók projektben betöltött szerepeit (roles), mely többféle is lehet egyszerre. Mi az adminisztrátor, supervisor, projektmunkás (project worker) szerepeket használtuk csak. Gyakorlati hasznukat nem nagyon vettük egyfajta rendszerezési, gyors áttekinthetőséget javító funkción kívül, mert ettől függetlenül is rendelhettünk minden jogot bárkihez. Az egyik komoly kritika a dotProjecttel, legalábbis ami a számunkra való felhasználhatóságot jelenti, már ennél a résznél jelentkezett. Fel kellett osztanunk az oktatók és a PhD hallgatók között, hogy ki mely adatok feltöltéséért, figyelemmel kíséréséért fog felelni, mert a program túlzott részletessége nagy adminisztrációs terhet jelentett. Ez viszont megakadályozta, hogy bármelyikünk átlássa a teljes folyamatstruktúrát. A kisebb, fizetett adminisztrátort alkalmazni nem tudó csoportoknál szükség lenne egy egyszerűsített változatra. Ezt követte a jogosultságok (permissions) kiosztása. Ez nagyon hasznos módon van kialakítva, bár némi gyakorlatot szerezni kell benne, míg a kezdő adminisztrátor elboldogul. Vannak nagyobb jogosultság-blokkok (pl. adminisztrátori). Miután ezek közül valamelyiket hozzárendeltük egy résztvevőhöz, a blokk egyes funkcióit letilthatjuk vagy hozzáadhatunk újabb engedélyeket. Mindezt az adott tag több különböző projektjében más-más módon is eloszthatjuk. Ez hasznosnak bizonyult, mikor megpróbáltuk a kezdeti kutatócsoporton túl is kibővíteni a program alkalmazását a tanszéki tevékenységekre. Különösen az volt szimpatikus vonás, hogy ha valaki nem volt jogosult egy adat, file stb. megtekintésére, az nem is szerzett tudomást annak létezéséről, így csoporton belüli feszültségeket nem okozott. Ugyanakkor a bonyolultság, mint probléma itt is jelentkezett. Ha a felhasználók általában sok projektben vesznek részt, és különösen, ha gyakori az új projektek megjelenése, sok energiát fog felemészteni ezek kezdeti beállítása, illetve folyamatos frissítése. A projektmunkások oldaláról ugyanakkor átlátható rendszer jelentkezik. Az átláthatóság egyik eszköze, hogy a

7



különböző projektekhez (project) és projekt-csoportokhoz (companies) tartozó információk eltérő színnel jelennek meg. Miután ily módon felruháztuk a részvevőket jogosultságokkal, igazi „ínyencségek” jönnek a projektmenedzsmenttel komolyabban foglalkozók számára. A tagokhoz feladatonként százalékos intenzitások rendelhetők: felosztható lenne tehát a munkatársideje több feladat közt. A program azonban jelzi, ha adott időpontban a részvevő már 100%-ban elfoglalt. Ez egy olyan lehetőség volt, amit mi nem használtunk ki, csak alapszinten. Nagy segítséget jelentett már nekünk is, hogy a program tájékoztatott, ha valaki adott időpontban már elfoglalt volt, így őrá már nem oszthattunk akkorra feladatot. A feladatok közti ütközések feloldására nyújt segítséget továbbá, hogy azokhoz prioritás rendelhető, amit az alkalmazás jelez. A kihasznált lehetőségek közé tartozott viszont, hogy a projekteken belül ütemezhető feladatokat tudunk megkülönböztetni (tasks), amelyekhez szintén egyenként (és más-más intenzitással) rendelhetünk munkatársakat, munkaóra-szükségletet, határidőket, valamint készültségi fokot. A program ezek után már kellemetlenkedni is fog: könyörtelenül kijelzi, pontosan mekkora késésben is vagyunk... Ez a funkció kritikán felül hasznosnak bizonyult. Igen nagy segítség volt munkánk során még a naptár (calendar) és a állománymegosztó (file) funkció. Az előbbinek különösen azt a tulajdonságát kedveltük meg, hogy automatikusan e-mailben értesítette a tagokat az új feladatokról, határidőkről. Persze csak azokat, akik hozzá voltak rendelve. Így a csoport szervezését is részben megoldotta. A filemegosztás pedig klasszisokkal múlta felül a hagyományos, kör-e-mailezés lehetőségeit. Egyrészről postafiók-kímélő, másrészt pedig soha nem lehetett keveredés a tekintetben, melyik egy file legújabb verziója. És keresgélni is kevesebbet kell, a jogosultságok miatt. A rendszer azonban kihasználatlan maradt és ezen a szinten előnyei kifulladtak. A kutatócsoportot nagyban segített a filemegosztás, a kalendárium révén, azonban a folyamatos módosításokra az egyéb területeken nem maradt adminisztrátori energia. A tanszéki működésre való kiterjesztés pedig egyedül a munkafüzet-projekt terén nem volt egyértelmű kudarc (egy ideig oda töltöttük fel az újabb és újabb verziókat és megpróbáltuk a tevékenységet szervezni is), ám ott is hamar kezelhetetlenné vált adminisztrátori oldalról, így még a filemegosztásban is vissza kellett térni, a „primitív” módszerekhez. A dotProject bevezetése olyan kezdeményezés lett, mely „felszállás közben lezuhant”, de amelyről mégis úgy gondoljuk, megérne egy újabb nekifutást, ha majd nagyobb méretekben alkalmazhatjuk. Ennek okait foglaljuk röviden össze az utolsó fejezetben. 6. Levont tapasztalataink a dotProject szoftver lehetőségeiről, korlátairól, valamint saját felhasználói korlátainkról is A program hatékony alkalmazásának feltételeit tapasztalataink szerint három saroktényező szabja meg: 1. megfelelő méret 2. megfelelően működő projektszervezet 3. az adminisztrátori teendőket ellátó projektmenedzser vagy projektasszisztens A megfelelő méret mellett szóló érveket külön nem soroljuk fel, az megtalálható a második és harmadik feltétel kifejtésében.

8



Triviális követelmény, hogy a projektszervezet kialakítása meg kell előzze a számítógépes alkalmazás bevezetését. A szerepkörök, a feladatok tisztázása a mi esetünkben azzal párhuzamosan történt, és ez magában hordozta a hiba lehetőségét. Érdekes tapasztalat, hogy a dotProject jobban vizsgázott a hallgatókból és fiatal oktatókból álló csapatnál és egyértelmű kudarcot jelentett, mikor a tanszék tapasztaltabb oktatóira is ki akartuk terjeszteni. Ennek egyik oka lehetett, hogy a projektirányításnak hatalommal kell rendelkeznie. Mihelyst a tagok megszeghetik a szabályokat (és ha a rangidős oktató lesz a projektmunkás, ez könnyen előfordulhat), a rendszer sérülékennyé válik. Ez fokozottabban igaz itt, mint a hagyományos rendszereknél, hiszen itt a tervezés szorosabb, a határidők többet jelentenek, a tervezés és összehangolás szerepe nagyobb. Másrészt egyfajta felhasználói készséget is igényel az alkalmazás használata, hiszen a munkavégzés szerves részévé kell váljon a szoftver kezelése. Ez az eltérő korosztályok közt más szinten valósul meg. Harmadrészt pedig a projekt elkülönültségét a projektet működtető szervezetnek is fel kell ismernie, és a projekt számára el kell különítenie bizonyos erőforrásokat, melyeket másra nem használhat (emlékezzünk, a dotProject figyelmeztet is ilyen esetben). Ez azonban a mi esetünkben sérült, mert a tanszéki, kari, egyetemi folyamatok tipikusan nem tervezetten zajlanak, és a projektek erőforrásait is elel vonják előre nem látható módon (elsősorban a munkatársak idejére, energiájára gondolunk). Ezek kezelését a hagyományos egyetemi szervezet informálisan végzi. Ilyen közegben pedig a formalizált projektirányítás adminisztrációs terhei sokszorosára nőnek a folyamatos újratervezés miatt. Ez az oka annak is, hogy úgy látjuk, minél nagyobb körben terjesztenénk ki az alkalmazás használatát (és azt megelőzően a projektmenedzsment szemléletet), annál jobban működne: kisebb lenne ugyani olyan szervezeti környezet, mely maga generál nehézségeket a projektirányítás számára. Kritikus pont volt az adminisztrátori teendők ellátása. A rendszer nem működtethető, ha nincs olyan résztvevő, akinek a munkaidejéből jelentős részt deklaráltan erre a tevékenységre fordítanak. Sok az adminisztráció fix költsége is, azaz az energia és idő, amit mindenképp erre kell fordítani. Ez is a méret növelése mellett szól, hiszen azzal együtt az adminisztrációs feladatok fajlagos súlya csökken. Összefoglalásképp elmondhatjuk, hogy a hasonló szofverek bevezetése és sikeres alkalmazása azon feladatok közé tartozik, melyek az alkalmazó szervezetre is hasonlóaan nagy felelősséget rónak, mint a szoftver fejlesztőire. Mindazonáltal a kipróbált szoftver, a dotProject meggyőzött minket arról, hogy ez, vagy egy hasonló alkalmazás jelentős segítséget nyújthatna akár egyetemi körülmények közt is, ha megfelelő szemléletmód társulna a bevezetéshez. De sajnos arról is, hogy egy ilyen újítás nem vezethető be „alulról”, csak (felső)vezetői támogatással. Irodalomjegyzék [1]

Görög Mihály (2001) Általános projektmenedzsment. Aula Kiadó, Budapest.

[2]

PMBOK® Guide (2006) Projektmenedszemnt útmutató. Akadémiai Kiadó, Budapest.

[3]

Verzuh, Eric (2006) Projektmenedzsment. HVG ZRt., Budapest.

9

A DOTPROJECT ALKALMAZÁS HASZNÁLATÁNAK TAPASZTALATAI ÉS LEHETŐSÉGEI A DEBRECENI EGYETEM KÖZGAZDASÁGTUDOMÁNYI KARÁNAK MENEDZSMENT ÉS MARKETING TANSZÉKÉN

Recommend Documents