IZBRANI PRISPEVKI DSI 2006
B Vpliv razmerij u projektni skupini na kakovost uporabniške rešitve
Alenka Knlar
Eiektro-Slovenija. d. o. o., Hajdrihova 2. Ljubljana alenka.knlar@eles.si
Povzetek
V slovenskih podjetjih, ki imajo oddelek za informatiko, izdelamo veliko uporabniških reSitev. potrebnih za podporo poslovnih procesov, znotraj projektnih skupin, sestavlienih iz »hišnih« programeqev in analitikov ter izvajalcev nalog na projektu \i zunanjih podjetij Razmerja med Člani projektne skupine, ki jih sodelujoči vzpostavimo med delom aii zunai njega, pomembno vplivajo na kakovost izdelka uporabniške reSitve.
Ključne besede: razmerja, uporabniška reSitev. projektno delo. kakovost. |avna naročila
Abstract
INFLUENCE OF REALTIOWSHIPS IN PROJECT TEAM ON THE QUALITY Of SOFTWARE APPLICATION
In Slovenian enterprises that have an informatics department a number of software applications necessary to support business processes in combined project teams is being developed. The teams are composed of domestic programmers and analysts and of outsourced personnel It is evident that the relationships that have formed among project te3m members during the time of the project have an important influence on the quality of developed application. Keywords: relationships, software application, proiect work, quality, public procurement
1 POLOŽAJ RAZVOJA UPORABNIŠKIH REŠITEV 1.1 Splošna
U slovenskih podjetjih naletimo na več načinov obvladovanja in razvaja uporabniških rešitev, namenjenih podpori poslovnim procesom. Velikost oddelka za informatiko je navadno odvisna od tega, ali podjetje kupi rešitev, kot npr. Oracle e-Business Suit, SAP ali Navision, ali pa v celoti ali delno programira rešitve z različnimi orodji in na različnih bazah podatkov. U obeh primerih se pojavlja oddajanje določenih nalog zunanjim izvajalcem (angl. uutsourcing), saj podjetja, ki jim programiranje ne predstavlja temeljne dejavnosti, ne razpolagajo z vsemi znanji in dovolj velikim številom ljudi, potrebnih za izvedbo večjih razvojnih projektov.
Obvladovanje projektov (project matuigemeiit) je oblika poslovnih procesov, ki je predvsem poznana v gradbeništvu in povezanih dejavnostih, ko govorimo o gradnji cest, zgradb, izdelavi turbin za elektrarne ipd. Na področju informatike je obvladovanje projekta razvoja uporabniške rešitve precej abstrakten pojem. Dejstvo je, da pri inženirskem projektu priprava projekta stane mnogo manj in traja krajši čas kot izvedba samega projekta. V informacijskih projektih pa je zato pripravljalni Čas neredko daljši in zahteva vključitev visokoizobraženih /.aposlencev kot prvin
poslovnega procesa. Izdelek uporabniška rešitev je za večino nekaj neoprijemljivega, kakovost tega izdelka pa teže določljiva. Uporabniška rešitev namreč ima nekaj določil storitve, kot so zanesljivost, varnost, dostopnost in razumevanje strank, kar niso pogoste lastnosti izdelka. Če se na inženirskih projektih pogovarjajo gradbeniki in nosilci sorodnih poklicev med seboj, se morajo na projektih informacijske tehnologije pogovarjati ljudje različnih strok z različnimi specialnimi znanji. Pogosto to predstavlja večji problem v sporazumevanju kol pogovor dveh ljudi z različnim maternim jezikom.
1.2 Jauna podjetja iti javno naročilo
Podjetja v javni tasti pri naročanju zunanjih storitev omejuje Zakon o javnih naročilih |Z|N|, ki predvidi pogoje, ki jih predpiše naročnik in jih morajo izpolniti dobavitelji. Najpogostejši pogoj je cena. Avtorji zakona so se pri zahtevah nedvomno posvetili »običajnim projektom«, povezanim predvsem /, naročanjem opreme, manj pa so imeli v mislih projekte razvoja uporabniških rešitev.
Opredeliti zahteve uporabnikov v jeziku razvijalcev je v okvirih, ki jih postavlja zakon, dokaj težko. Vsi, ki so kdaj pisali take zahteve, vedo, kako zelo se
2Q0A - šlevilka 3 - letnik XIV
U I' □ K A II N A informatika 129
Alenka Koiar Vpliv razmerij v projektni skupini na kakovost uporabniške rešitve
med potekom projekta spreminjajo zahteve in kako težko je naknadno prilagajati programe novim pobudam uporabnikov. V prispevku prikazujem drugačen pogled na javne razpise. Zakonsko namreč ni dopustno, da diskriminatorno predpišemo, s kakšnimi ljudmi želimo delati. Ob tem ko predpišemo zahteve glede strokovnih znanj zunanjih izvajalcev, ni v navadi zahtevati od njih določenih značajskih lastnosti, ki pripomorejo k uspešnosti projektne skupine. Zavedati se moramo, da zgolj predpisati, katere standarde naj pri delu zunanji sodelavci uporabljajo, nikakor ne zadošča. Tako je navadno cena Lista, ki odločno vpliva na določitev zunanjega dobavitelja, v našem primeru izvajalca storitve razvoja (analize in programiranja) uporabniške rešitve.
2 STANDARDI IN METODE DELA
Informatiki skušamo s sodobnimi orodji podpreti poslovne funkcije in procese. Ti so običajno popisani v priročniku kakovosti, izdelanem po standardu ISO 9000/2000ITS0900M2000). Vendar pa njihova opredeljenost znotraj standarda ni dovolj podrobna, niso popisane razne izjeme in učinki posameznega procesa, naj si gre za poročila o davku na dodano vrednost, ki jih oddajamo davčni upravi, ali plačilni list zaposlenega. ISO standard torej razvijalcem uporabniške rešitve ne zadošča, poda jim le temeljno usmeritev procesa.
Razvoja uporabniških rešitev se tako ali drugače dotika še precej mednarodnih standardov, ki pa v okoljih razvoja uporabniških rešitev v slovenskih podjetjih niti ne predstavljajo temelja ali opore pri razvoju niti ne dajejo smernic za razvoj.
V slovenskem okolju postajajo priljubljene smernice ITH. (Information Technology Infrastructure Library) fITILJ. Ta pa se ne ukvarja toliko s procesi, ki jih informacijska tehnologija podpira, pač pa z organiziranjem same dejavnosti - temeljnih procesov v oddelku informatike. ITIL se opira na besedo »sledljivost«. Gre za sledljivost sprememb v informacijski infrastrukturi in uporabniških rešitvah. ITIL se ne ukvarja s sestavo projektnih skupin, primernih razvoju, niti ne podaja kakršnihkoli smernic v ta namen. Za premostitev problema pomanjkanja ustreznega standarda je novembra 2005 izšla serija standardov ISO/IEC 20000 Service Management Standards.
jezik, ki ga teorija pogosto predvidi in naj bi olajšal sporazumevanje med uporabniki in razvijalci uporabniških rešitev je UML (Unified Modelling Language).
Uporablja se v objektnem programiranju, saj naj bi zagotavljal uporabo najboljše prakse iz svetovnih razvojnih hiš. Vsakdanjost je nekoliko drugačna. Slovenska podjetja namreč uporabljajo relacijske baze podatkov iu pogosto nimajo strokovnjakov, ki bi se znali sporazumevati v UML. Ko poteka razvoj nenadzorovano ali ad hoc, se nihče ne ukvarja z risanjem diagramov UML. Kadar je zakon sprejet tako rekoč za nazaj, ga je treba informacijsko nemudoma podpreti in vsak se znajde po svoje.
LMR1S (Enotna metodologija razvoja informacijskih sistemov) |EMRiS| je v slovenski državni upravi poznana, vendar jo v prakso podjetja, razen teorije same, niso prenesla v večjem obsegu. Informatiki jo ocenjujejo za nekoliko »postopkarsko« in zamudno v primerih popravkov ter potrebe po razvoju, kadar je treba tega zaradi zunanjih dejavnikov udejanjiti dobesedno čez noč.
3 AGILNA METODOLOGIJA RAZU0JA
Leta 2000 je James A. I lighsmith razvil in objavil metodo Adaptive Software Development (prilagodljivi razvoj programske opreme), ki je ena izmed možnosti agilne metodologije razvoja programske opreme. Ustrezala naj bi sodobnim zahtevam poslovanja v nenehno spreminjajočem se, negotovem in nepredvidljivem okolju. Sporočilo metodologije avtorji pogojujejo s Štirimi predpostavkami:
•	Posamezniki in sodelovanje imajo prednost pred procesi in orodji.
•	Delujoči programi imajo prednost pred izčrpno dokumentacijo.
•	Sodelovanje z uporabnikom ima prednost preti pogajanji o pogodbi.
•	I liter odziv na spremembe ima prednost pred sledenjem načrtom.
Ljudje postanejo pomembnejši od predpisov, spodbujeno je sodelovanje med ljudmi, ki sodelujejo pri razvoju nove programske opreme. Motivacijo posameznika in skupine je treba spodbujati, ne pa omejevati s tehničnimi podrobnostmi. Metoda gotovo moti vse, ki želijo postopke predvsem dokumentirati in prisegajo na neprekinjeno sledljivost Ti bi se morali zavedati, da v tem primeru govorimo o programiranju in ne o rezultatih nekih meritev.
Pogled raz vojn i ka je usmerjen h kupcu. Manj pa je pogled kupca uporabnika usmerjen k dobavitelju. V mešanih razvojnih skupinah se morajo vsi počutiti dobro in težiti k skupnemu cilju. Uporabnik ni samo
130 updhaiiua INFORMATIKA
2006 - Številka 3 - letnik XIV
Alenk.! KoLu Vpliv razmerij v projektni skupini na kakovost uporabniške rešitve
nekdo, ki plača račun za opravljeni razvoj. V primeru razvoja s pomočjo zunanjega izvajanja dejavnosti namreč nastopata dve vrsti »kupcev«: programer in končni uporabnik i/, podjetja naročnika.
Vsaka formalna metoda razvoja naj bi v podjetju prispevala k večji učinkovitosti razvoja uporabniške rešitve in njeni kakovosti |Vavpotič Q5j. Večina podjetij pa metode ne formalizira in deluje v Skladu s svojo dobro prakso, ki se seveda razlikuje od podjetja do podjetja, tako kot se razlikujejo ljudje v skupinah in njihova zgodovina sodelovanja pri razvijanju uporabniških rešitev.
4 RAZMERJA
4.1 Teorija organizacije
Po Lipovcu [Lipovec 741 predstavlja organizacija sestavo razmerij. Mihelčič [MihelČiČ 03] predvidi, da vsako podjetje nastane zaradi razmerij tehnične nara-
ve, saj ni drugega pomembnejšega razloga za ustanovitev podjetja, kot je možnost ustvarjanja in prodaje proizvodov ter storitev. Rosabeth Moss Kanter | Kanter 441 pravi, da so podobno kot razmerja med ljudmi tudi poslovna družabništva živi sistemi, ki imajo nešteto možnosti. Združbe, ki bodo znale izrabiti te možnosti ter učinkovito obvladovati svoje povezave, bodo okrepile svojo vrednost v sredstvih/naložbah.
Na sliki l je prikazan grozd organizacijskih razmerij. Grozd je rezultat študije, izdelane na Gospodarski zbornici Slovenije leta 1988 | Mihelčič 88J. Prikazan je preplet petih vrst razmerij (tehnične, kadrovske, koordinacijske, komunikacijske in motivacijske narave) ter združitev po dveh izmed njih, ki jih zasledimo v vsaki združbi in tudi v projektni skupini. Glede na zaznane poudarke na posameznih razmerjih ali kombinaciji razmerij vemo, da se združba ali skupina nagibata ali k poslovnim učinkom (proizvodom oziroma storitvam) ali k ljudem in delu z njimi.
4.2 Vplivni dejavniki
Leta 2003 smo anketirali dobavitelje izdelave (programiranja) uporabniških rešitev za podjetje v javni lasti. Prosili smo jih, naj primerjajo podjetje z najboljšim podjetjem, ki mu dobavljajo enako storitev. Ugotovitve so pokazale, da je dobaviteljem, ki pogosto opravljajo svoje delo v prostorih naročnika in se srečujejo s programerji v podjetju ter uporabniki razvitih uporabniških rešitev, najbolj pomembno:
sodelovanje s »hišnimi« programerji in skrbniki uporabniških rešitev;
da ob razvoju hišni programerji aktivno sodelujejo in sproti prevzemajo (dele) rešitev;
. predpisana oblika predane dokumentacije ob koncu projekta; > ugodni delovni pogoji (prostor, svetloba, delovni pripomočki ipd.); • zapisane zahteve.
Ko potrebe zunanjih dobaviteljev uvrstimo v prikazani organizacijski grozd razmerij, ugotovimo, da je poudarek na dobrem počutju in s tem na občutku smiselnosti v delo vložene večje energije, v razmerjih komunikacijske in motivacijske narave.
Kljub pomanjkljivostim v omenjenih razmerjih pa podjetje dosega pri projektih
Poudarek na poslovnih učinkih
vpetost organizacijskih razmerij združbe v okolje
Poudarek na ljudeh
STRATEGIJA
MO-ŽNl NIHAJNI RAZPON UREJANJA ORGANIZACIJSKIH RA7MERIJ krajiio obdobja
daljio obdobje
(A) Prijetna organizacija (Organizacija spodbujane samoimciaiive (O) Organizacija nadzorovano samoiniciatlve 1 P.) Organizacija omojuno samo iniciativo Odtujona organizacija
Slika 1 Grozd orgarmacijsltih raimerij
2006 številka 3 - letnik XIV
upokadna informatika 131
Alenka Kotar: Vpliv razmerij v projektni skupini na kakovost uporabniške rešitve
razvoja programske opreme dobre rezultate. Kateri so torej dejavniki, ki povečujejo aii pa zmanjšujejo možnost uspeha projekta? I/ teorije, odgovorov ankete in izkušenj izvedeni štiri vrste dejavnikov, ki vplivajo na kakovost razmerij v projektni skupine (preglednica 1). Številke v stolpcih pomenijo težo posameznega dejavnika in so določene na podlagi pomena posameznega dejavnika na kakovost razmerij v projektni skupini.
Preglednica 1: Vpliui in njihova teža na kafcouost raimerij u projektnem t i mu
Biološko opredeljiva	Vpliv	Sposohoosti	Upliv
Starost	25	Komuniciranje	100
Spol	50	Širok pogled	100
Prilagodljivost	75	Spoštovanje	75
Kemija	75	Skromnost	50
Tisto nekaj"	50	Vodja	75
		Hobiji	25
Pridobljena	Vpliv	Zunanji vpliv	Ifpliu
Izobrazba	25	Standardi	25
Strokovno znan je	25	Pogoji dela	50
Skupna stvarnost	50	Število ljudi v skupini	50
Skupni cilj	50	Uporabniki	100
		Obvestila	75
Ko razmerja in dejavnike, ki vplivajo nanje, vpne-mo v grozd {slika 1), ugotovimo, da je v projektnih skupinah razvoja uporabniških rešitev poudarek na ljudeh, na vsakem posamezniku in ustvarjanju njegovih povezav z drugimi člani projektne skupine (slika 2), Povezave pa ustvarjamo tako s komuniciranjem kot tudi s standardi ter predpisi.
Premik od organizacije nadzorovane samoinicia-tive k organizaciji spodbujene samoiniciative lahko po metodi predstavljeni v [Mihelčič in [Mihelčič 04], ocenjujemo z izidom 60. Ta izid pomeni, da je za kakovostno ekipo za izdelavo uporabniške rešitve potrebna prijazna organizacija spodbujene samoiniciative.
4.3 Predvideti uspeh
V podjetjih, ki se jili posredno dotikamo s člankom, programiranje uporabniških rešitev za podporo po-
slovanju ni temeljna dejavnost podjetja. Oddelki informatike predstavljajo manjši del zaposlenih v podjetju (povprečno okrog 5 %).
Projektno skupino za razvoj nove uporabniške rešitve sestavljajo zaposleni v informatiki, njihovi zunanji dobavitelji (največkrat programerji in ne tako pogosto analitiki procesov, saj je za uspeh projekta pomembno, da vsaj nekaj analitikov prihaja iz podjetja in ne od zunaj) ter uporabniki rešitve, ki izvajajo neko drugo funkcijo v podjetju oz. so nosilci dela poslovnega procesa, ki ga bo podprla rešitev.
Projektno skupino sestavi vodja projekta, tega pa določi lastnik projekta - notranji kupec. Pri dopolnjevanju skupine z. zaposlenimi iz podjetja naletimo na ovire, ki jih navadno postavljajo funkcijski vodje -nihče ne želi izgubiti najboljših ljudi. Zunanje sodelavce moramo največkrat pridobiti z javnimi razpisi. V splošno prakso pa žal ne sodi, da bi ene ali druge sodelavce izbirali na podlagi osebnosti, njihovega načina dela s sodelavci ali po katerem koli v preglednici 1 navedenih sod i lih, razen morda po formalni izobrazbi in drugih strokovnih znanjih. Žal to ni dovolj za prehod skupine v ekipo, kar se zgodi, ko postane
SiandarOi 25	
Obvestila 75	
S100	
Širok pogled
I I
Komunrfciranje Vodja I 100 I t t
I S 100 I
Skupna
75 5po3tova*je75 SkronvjfJst 50 Skupnn cilj 50
/
S 7üj/ S176 Kepfya 75 50 glisto nekaj«50 ^Uporabniki 100
S 225
S 50 / Sl ijudev
/ S 50	
Starost	25
Spol	50
Hobjji	25
	S 100
I Pniagodljivosl
50
75
S 75
S 300
skupifii „ !
Z	I
'	S 50 I
t
Dejavniki, pomembni pri IT projektih, premaknejo organizacijo proti samoiniciativni m prtjazm
S 700
Slika £ Uteženost grozda raimerij z vplivnimi dejavniki in zasuk proti prijazni organizaciji
100 | stvarnost
/
132 ueoninuí INFORMATIKA
7ÜÚ& - številka 3 - letnik XIV
Alenka Kolar Vpliv razmerij v projektni skupini na kakovost uporabniške reiitve
namen skupine razumljiv vsem Članom in vsak odigra predpisano vlogo takt), da v največji meri uveljavi svojo nadarjenost in usposobljenost.
Projektni vodja je tako pred zahtevno nalogo z razpoložljivimi kadri doseči največ. Kateri dejavniki so najbolj in kateri manj pomembni? Pri iskanju odgovora si lahko pomaga s preglednico l. Projektna skupina, v kateri ni dovolj pomembnih dejavnikov, je vnaprej obsojena na neuspešno delo, družba pa na neka-kovosten izdelek.
5	SKLEP
Pravila, standardi in dokumentacija omejujejo in hkrati pomagajo projektnim skupinam pri razvoju uporabniških rešitev. Ker gre pri razvoju uporabniških rešitev za podporo poslovanja za multidisciplinarne skupine iz različnih okolij, so lastnosti posameznika v skupini, ki šteje do deset članov, izredno pomembne. Žal jih iz različnih vzrokov ne moremo vedno izbirati. Če pa jih poznamo, utegnemo iz. ugodnih soti čin kovanj teh lastnosti potegniti najboljše učinke.
6	VIRI IN LITERATURA
Mihelčič 03
Miran Mihelčič: Organizacija ki ravnatelje vanje, Založba FE in FRI, Ljubljana, 2003.
ZJN
Zakon o javnih naročilih, Uradni list Republike Slovenije št. 39/00. 12. 5. 2000.
IS09000/2000
PSIST ISO/DIS 9000:2000; Sistem vodenja kakovosti -Zahteve. 3. izdaja; maj 2000.
ITIL
ITIU The Key to Managing IT Service; Best practice for Service Delivery, Office of Goverment Commerce, London, 2001. EMRIS
Krisper, Marjan; Rupnik, Rok; Bajee, Marko; Rožanec, Alenka; Zrnec, Aljaž; Vavpotič, Damjan; Osojmk, Rok; Tomažič, Roman: Enotna metodologija razvoja informacijskih sistemov (EMRIS); Vlada Republike Slovenije; Center vlade za informatiko, 2003. Vavpotič 05
Vavpotič. Damjan; Bajee, Marko; Krisper, Marjan: Meaunng and improving software development methodology value by considering tehnical and social suitability of its constituent elements, Univerza v Ljubljani, Fakulteta za računalništvo in informatiko, 2005. Lipovec 74
Filip Lipovec, Teorija organizacije. Univerza v Ljubljani Ekonomska fakulteta, Ljubljana, 1974. Mihelčič 04
Miran Mihelfilč, Principles of Organization Analysis: Sugestión of Method and Application in Practice, EGOS Library, 2004. Kanter 94
Rosabeth Moss Kariler; Collaborative Advantege: The Arto f Alliances, Harvard Business Review, julij-avgust 1994,96-108. Mihelčič 88
Miran Mihelčič, Cita Bračko, Janez Gabrijelčič, Miro Kline, Janez ŠČek, Ivan štucin; Metodologija ugotavljanja kakovosti ali popolnosti organizacije (gospodarskih) zdruib; raziskovalno delo. Gospodarska zbornica Slovenije, 1988.
Alenka Kolar |e leta 197? diplomirala na Fakulteti za strojništvo v Ljubljani in leta 1998 magistnrala na Fakulteti za organizacijske vede v Kranju Zaposlena |e hila na Uradu za standardizacija in meroslovje kot vodja laboratorija za maso. nato v avtomobilski industriji kot vudja zagotavljanja kakovosti, ud leta 1999 pa dela v EI ektro-Slovenija, d. 0. 0. kjer od leta 2001 vodi službo v sektorju za poslovno informatiko.
2006-šlevitka 3-letnik XIV
ufuhiiiui informatika 133