1 Projektirányítás 1.1 Mit értünk projekten? A sokféle meghatározás közül az egyik legtömörebb, legjobb az alábbi: A projekt egyedi termék, szolgáltatás vagy eredmény létrehozására irányuló ideiglenesen zajló erőfeszítés. (Projektmenedzsment útmutató (PMBK Guide). Budapest Akadémiai Kiadó, 2006). A projekt főbb tulajdonságait kiemelhetjük, és ezektől függően eltérő fogalmazású definíciókat találhatunk ki. Van olyan álláspont is a szakirodalomban, hogy a projekt fogalmát nem is kell definiálni. A projekt tulajdonságait azonban elég jól összefoglalhatjuk: Konkrét cél érdekében folyik Egyedi terméket állít elő Az eredménynek bizonyos kritériumoknak meg kell felelni Általában rögzített költségvetése van (nehezen értelmezhető a költségvetés pl. egy nyílt forráskódú, szabad szoftver esetén) Erőforrásokat használ Van kezdete Van vége. A projekt mindig egyensúlyozás az úgynevezett projekt-háromszög csúcsai között. minőség idő költség Ez a három tényező általában egymás ellen hat. A gyorsan olcsón kiváló minőségben hármas nem teljesíthető maradéktalanul. Akkor vagyunk megfelelőek, ha az ügyfél ezt a hármast elfogadhatónak, sőt jónak ítéli. A kritériumokat célszerű a projekt elején rögzíteni, mert a hármas követelménycsomag bármelyik részének változása kihat a projekt egészére. Gondoljunk arra, hogy ha egy cél elérése rövid idő alatt szükséges, és nem rutínfeladatot kell megoldani. Az egyik lehetőség, hogy megbízunk egyszerre több független fejlesztő csapatot párhuzamosan a feladattal. Bizonyára jobb esélyünk van arra, hogy születik egy megfelelő minőségű megoldás rövid idő alatt, mintha egy utat követnénk. Az esetleg tévútra futott fejlesztésre fordított idő nem vész el. Természetesen a költségeink nőnek a párhuzamos fejlesztés miatt. Megnövelhetem
a rendelkezésre álló szellemi kapacitás minőségét is. Vannak tanácsadó cégek, ahol az a bevett gyakorlat, hogy egy újszerű feladathoz megvásárolják a téma legjobb szakértőit, és egy saját projektvezetőhöz rendelik őket. Ez csökkenti az időt, növeli a minőséget, csak nem lesz olcsó. A költség csökkenthető kevésbé tapasztalt fejlesztőcsapat alkalmazásával, de sok időt fog elvinni, amíg megismerik a terület sajátosságait, szabványait. A minőség rontása is egy elméleti lehetőség, de ez az irány hosszú távon nem járható. A rossz minőséget a piac hosszú távon nem fogadja el. A minőség javításának vannak lehetőségei (jól dokumentált komponens és integrációs teszt, a folyamatok előzetes metanyelvű leírása, a kód sebezhetőségének módszeres ellenőrzése, ), de ezek növelik a ráfordításokat. 1.2 Mitől sikeres egy projekt? A CHAS jelentés ( The Standish Group International) szerint a szoftverprojektek sikeressége az utóbbi években folyamatosan nő, de még így is 30 % alatt marad a sikeres projektek aránya. Az üzletileg sikeres projektek aránya még jóval kevesebb. Figyelemre méltó adat, hogy egy németországi vállalati felmérés szerint a megvásárolt kész szoftverek 50%-át soha nem vették használatba. Ez azt mutatja, hogy egy szoftver használhatósága csak a környezettel együtt értelmezhető, és a szoftver része a vállalati folyamatoknak. Jelentős költség és erőfeszítés kell az alkalmazások bevezetéséhez. Nem elegendő egy máshol esetleg jól bevált termék megvásárlása. Érdemes tehát megvizsgálni, hogy egy projekt mitől sikeres, vagy sikertelen. A projekteket egyszerűség kedvéért három csoportba soroljuk: Sikeres az a projekt, ami határidőre, a tervezett költségkereten belül valósul meg. Problémás az a projekt, aminek eredményét ugyan használatba vették, de vagy a költség, vagy a határidő, vagy a specifikáció nem teljesült. Megbukott az a projekt, amit vagy felfüggesztettek menet közben, vagy az eredményét soha nem vették használatba. Tréfásan azt szokták mondani, hogy egy szoftver projekt kétszer annyi ideig tart, és háromszor annyiba kerül. Mihez képest? Akármihez képest. A valóságos adat sok ezer projekt átlagában az, hogy a költségvetés túllépése 50 % körül van, nagy szélsőségekkel. A vállalatok szerint a három leggyakoribb oka a kudarcnak: nem reális határidő, nem megfelelő emberi erőforrások, nem eléggé definiált projektterjedelem. Mindhárom tényezőre megkísérlünk becsléseket tenni a későbbiek során.
Világos, hogy egy 60 embernapos projekt nem valósítható meg 1 nap alatt 60 programozóval, de az is valószínűsíthető, hogy egy ember 60 nap alatt rendkívül sok hibával fogja a feladatot elvégezni, ha egyáltalán elvégzi. Nem valószínű, hogy valaki egyszerre zseniális programozó, rendszertervező, tesztelő. Az emberi erőforrás minősége döntő tényező lehet a sikerben. A hozzá nem értésen nem segít sem az idő, sem a megnövelt prémium. Ha a projektről kiderül, hogy túlmutat a vállalat, vagy részleg keretein, akkor nem garantálható az eredményes befejezés mégoly jó megoldások esetén sem. A szoftverprojektek sajátossága, hogy a termékben a szállító tapasztalata és az adott területen szerzett jártassága (a know-how) is fontos része a szállításnak. Ma már sok cég elvárja a szállítótól, hogy a termék az eredetileg kitűzött felhasználási célokra alkalmas legyen. A szállítónak rendelkezni kell azokkal a tapasztalatokkal, eljárásokkal, ami a terméket az adott célra alkalmassá teszik. Ha a felhasználó jóváhagyta is a szállító rendszertervét, az nem mentesíti a célok elérésének kötelezettsége alól. A szerződések ilyen jellegű megfogalmazása a katonai beszállítói szerződésekben lett általános, majd átvette sok civil felhasználó is. Ezt az elvet fogalmazza meg az EURMETHD ajánlás is. Az informatika ma már a vállalat termelési struktúrájának része, így valójában az informatika a vállalat egy folyamatának része, és csak a teljes folyamattal együttesen lehet sikeres. Nem lehet sikeres pl. egy dokumentumkezelő szoftver, ha a cég nem tudja minősíteni a dokumentumok biztonsági szintjét, tartalmi besorolását, és nincs ügyrendje a dokumentumkezelésnek. A szállítónak meg kell fogalmazni azokat a keretfeltételeket, ami mellett a termék alkalmazható. Ide tartozik a szükséges emberi erőforrás, és annak képzettsége is. A sikerhez szükséges tényezők közül néhány: világos üzleti (műszaki) cél, projekt célok (cél-hármas) meghatározása, körültekintő szerződéskötés (EURMETHD), célok melletti elkötelezettség a szereplők részéről, jó projektvezető, elegendő erőforrás, megfelelő technológia (Ez külön fejezet a terméktervezésben! A szállító technológiája nem biztos, hogy optimális a feladathoz), megfelelő információkezelő és dokumentációs rendszer. 1.3 A projekt környezete Az informatikai projektek nem elszigetelten léteznek, hanem részei egy vállalati, nemzeti, EU gazdaságnak.
Sokszor hajlamosak vagyunk elfelejteni, hogy egy nagyvállalati rendszer sok szállal kapcsolódik egyéb rendszerekhez, melyekhez alkalmazkodni kell. Meglepően sokszor hagyjuk figyelmen kívül (még rendeletek, törvények szintjén is), hogy az Európai Unió tagjai vagyunk. Az EU támogatású projekteknél az EU ajánlásai kötelező érvényűek. A jelen (2009) magyar helyzetben rendkívül körültekintő módon kell eljárnunk a szerződések megkötésekor. Lassú a bírósági eljárás, és a fővállalkozók egy része tisztességtelen magatartást tanúsít az alvállalkozókkal szemben. A jó szerződés a prolémák egy részét meg tudja előzni. A termékfejlesztésben (szoftverfejlesztésben) saját hatáskörben csak a saját szervezetünket tudjuk befolyásolni, és a feladathoz igazítani. A szervezeti modelleket négy fő csoportba szokták sorolni: egyszerű szervezet, funkcionális modell, mátrix szervezet, projektcsapat modell. Az egyszerű szervezeten belül nincsenek hierarchia szintek. Egyszemélyi irányítás van. Ez a mikrovállalkozások tipikus formája. A céget a vezető közvetlenül irányítja. A tapasztalatok szerint ez a modell átlagosan 8 főig eredményes. Vezető munkatárs 1 munkatárs 2 munkatárs 3 munkatárs 4 1.1.ábra. Egyszerű szervezet A funkcionális modell testesíti meg a klasszikus vállalati szervezetet. A funkcionális szervezet előnye a szakértelem koncentrálása. Egy nagyvállalatnál az európai területre elegendő pl. egy diszk-szakértő csapat, egy kommunikációs csapat, stb... Könnyű a munkatársak továbbképzése, helyettesítése. Nehézségeket okoz azonban a különböző funkcionális egységek közös feladatainak megoldása. Nehéz a munkatársak folyamatos terhelésének biztosítása.
Vezető funkcionális vez. 1 funkcionális vez. 2 funkcionális vez. 3 1.2. ábra. Funkcionális szervezet Az egész szervezet rugalmatlan. A terhelés egyenletes biztosítása csak nagy szervezeteknél nem okoz gondot. Egy európai méretű hálózatban mindig van feladat, kiegyenlítődnek a munkacsúcsok és hullámvölgyek. Érdekes például az a megoldás mikor földrajzilag eltérő területen dolgozó munkatársak vannak ugyanabban a funkcionális csoportban.pl.: a müncheni marketing osztály dolgozója mindenki, függetlenül attól, hogy Budapesten vagy Londonban dolgozik. A beosztottak azonban nem mindig követik szívesen ezt a munkastílust. (Ma Magyarországon, de lehet hogy a jövő héten Bécsben dolgozunk. A családosok számára nem igazán vonzó munkarend). A lokális vállalatok funkcionális szervezetei kényelmesek, de a vállalat szempontjából rosszul kihasználható szervezetek. Ha növekszik a több funkcionális egységet igénylő feladatok száma, akkor szoktak a cégek mátrix szervezetek irányába elmozdulni. A mátrix szervezet azt jelenti, hogy egy dolgozó egyszerre több szervezethez tartozik. Egy munkatárs tartozik mondjuk a berlini hardver osztályhoz, és budapesti irodához.. A projekt egy további dimenziót adhat a mátrixhoz. A helyzetet bonyolíthatja, hogy a cégen belül a különböző csoportokat eltérő mátrixokba szervezhetjük. A szervezeteket a funkcionális és projekt vezetőkhöz való tartozás szorossága szerint szokták osztályozni, és további csoportokra bontani.
A koordinációs mátrixban mindössze annyi történik, hogy minden funkcionális egységben van kijelölt gazdája a többi funkcionális egységgel való kapcsolattartásnak. Az átfedési mátrix szervezetben már valóban megvan a projekt és funkcionális dimenzió is.a munkatársak egyszerre két szervezeti egységhez tartoznak. Az átfedés mátrix előnye, hogy hamar kiderül, kik a felesleges emberek, akik nem kapcsolódnak hosszabb ideig projekthez. Kiderülnek a hiányszakmák is. A módszer hatékony és rugalmas. Két komoly hibája van azonban. Ha valakinek két főnöke van, nem tudja, hogy kinek az elvárásait részesítse előnyben. Ez megnehezíti a dolgozók motiválását is. A másik probléma az, hogy a jobb projekttagokért belső harc folyik a projektvezetők között. A jobb pozíciójú projektvezetők jobb embereket szereznek, jobb premizálási feltételekkel, és torzulhat a cégen belüli értékrend. A rendelkezésre bocsátási mátrix részben kompenzálja az előző megoldások hibáit, de újakat is létrehoz. Projekt iroda Vezető funkcionális vez. 1 funkcionális vez. 2 funkcionális vez. 3 projektvezető 1 projektvezető 2 projektvezető 3 projektvezető 4 projektvezető 5 Projekthez nem rendelt funkcionális tagok Projekt tagok 1.3. ábra Rendelkezésre bocsátási matrix A munkatársak a projekt idejére a projektvezetőhöz vannak rendelve, és gyakorlatilag egy főnökük van. A funkcionális vezetőhöz csak addig tartoznak, amíg nincsenek projektben. A problémája a szervezetnek, hogy a projektben nem cél a munkatársak képzése. Ez a funkcionális csoport feladata lenne,de a legjobbaknak erre alig marad idejük, mert mindig projektben vannak.
Hosszabb projektek esetén a hozzárendelések stabilizálódnak, és a funkcionális csoport szerepe leértékelődik. Ennek lehet az is az eredménye, hogy állandó, de nagyon különböző színvonalú projekt csapatok jönnek létre egy cégen belül. A rendelkezésre bocsátási mátrix átalakul projektcsapat szervezetté. A projektcsapat szervezet a hozzárendelt erőforrásokkal jól tud gazdálkodni. A funkcionális vezetők megszünnek, és helyüket szakértők veszik át. A szakértő feladata, hogy műszakilag meghatározza azokat a felhasználó által homályosan megfogalmazott célokat, és javaslatokat tegyen a projektek létrehozására. Projekt iroda Vezető szakértő 1 szakértő 2 szakértő 3 Nincsenek funkcionális tagok projektvezető 1 projektvezető 2 projektvezető 3 projektvezető 4 projektvezető 5 Projekt tagok 1.4.ábra. Projektcsapat szervezet A projektcsapat szervezetnek is vannak hiányosságai: Nincs intenzív (vagy semmilyen) kapcsolat a projektcsapatok között. Nem alakulnak ki egységes vállalati megoldások, vagy külön eljárásokat kell erre kitalálni. A szakértelem nehezen összpontosítható szakmai területek szerint. A megfelelő szervezeti forma kialakítására sajnos nincs egyértelmű recept. Vannak nagy világcégek, ahol eljutottak egy 8 dimenziós mátrixhoz a kapcsolatok leírásában. A sokdimenziós mátrixok azonban csak a projekelmélettel foglalkozók számára áttekinthetőek. A gyakorlat nem igazolta a sok dimenziós mátrixok előnyösnek vélt tulajdonságait. A két, esetleg három dimenziós mátrixok alkalmazása az elfogadott gyakorlat. Az 1.5. ábra orientációs jellegű, és azt szemlélteti, hogy a különböző gyakoriságú és méretű feladatokra milyen szervezet általában a megfelelő. Természetesen más a projekt méretekkel dolgozik egy 6000 fős szoftverfejlesztő cég, és egy 50 fős válalkozás. Érdekes tapasztalat, hogy egy célterületen, de különböző projektekben dolgozó programozók munkájának összehangolása 100-150 fő környékén komoly nehézségeket okoz, és más módszreket igényel a munka irányítása.
Projekt mérete Projektcsapat modell Mátrix Funkcionális modell Egyedi Ismétlődő Folyamatos Gyakoriság 1.5.ábra. Modellválasztás szempontjai Az a tanulság, hogy a rutinfeladatok jól megoldhatók funkcionális szervezetben, míg az egyedi, nagy projektek megvalósítására projektszervezetet célszerű létrehozni. Magyar viszonyok között pl. egy atomerőmű környezeti mérőrendszerének létrehozása nem ismétlődő, többéves feladat, ami valószínűleg projekt szervezetben valósítható meg. Ahol évi 10 atomerőmű épül, ott megfontolandó egy mátrix szervezet létrehozása. Egy önkormányzat építési osztálya, aki hasonló ügyek százaival foglalkozik, valószínüleg funkcionális szervezetben működik hatékonyan. Ha a feldatokat a megrendelő oldaláról közelítjük, akkor az a probléma kerül előtérbe, hogy hogyan tudjuk a különböző beszállítók eltérő irányítási, fejlesztési, tervezési módszertanait összehangolni. A téma iránt érdeklődők számára az EURMETHD ajánlás sok hasznos ismeretet tartalmaz.