Weckman Teppo Kansainvälinen ohjelmistokehitys Ongelmat projektinhallinnassa ja hajautetuissa tiimeissä Vaasa 2022 Tekniikan ja innovaatiojohtamisen yksikkö Tietojärjestelmätieteen pro gradu -tutkielma Digitaalisen liiketoiminnan kehittäminen 2 VAASAN YLIOPISTO Tekniikan ja innovaatiojohtamisen yksikkö Tekijä: Weckman Teppo Tutkielman nimi: Kansainvälinen ohjelmistokehitys : Ongelmat projektinhallin- nassa ja hajautetuissa tiimeissä Tutkinto: Kauppatieteiden maisteri Oppiaine: Digitaalisen liiketoiminnan kehittäminen Työn ohjaaja: Tomi Pasanen Valmistumisvuosi: 2022 Sivumäärä: 66 TIIVISTELMÄ: Globalisaatio on prosessi, joka on jo vuosia vaikuttanut voimakkaasti yhteiskunnan kehitykseen. Ohjelmistokehitys ei tässä trendissä muodosta poikkeusta. Ohjelmistokehityksessä globalisaatio näkyy suunnittelu- ja kehitystyön, etenkin ohjelmistojen toteutuksen ja testauksen, hajautumi- sena useamman valtion alueelle. Kyse on pienimmillään siitä, että työ suoritetaan eri maassa, kuin mistä se tilataan. Laajimmillaan hajautuksessa työtä suoritetaan useassa eri maassa tai koh- teessa. Tässä työssä tarkastellaan teknologisen kehityksen mahdollistamaa kansainvälistä ja ha- jautettua ohjelmistokehitystä. Kansainvälinen ohjelmistokehitys on lisääntynyt jo vuosia ja tie- tyillä toimialoilla sen voi ajatella olevan jo alan yleinen normi. Kansainvälisesti hajautetulla oh- jelmistokehityksellä saavutetaan monia etuja, mutta siihen liittyy myös vaikeuksia, joita ei aina osata ottaa riittävästi huomioon. Tämän takia hajautettujen ohjelmistokehitysprojektien epäon- nistumisprosentti on korkea verrattuna paikallisesti toteutettuihin kehitysprojekteihin. Työn tar- kastelun näkökulmana on projektinhallinta kansainvälisessä sovelluskehityksessä sekä hajautet- tujen tiimien toiminta. Työssä selvitetään, millaisia ongelmia kyseisten projektien hallintaan sekä virtuaalitiimien toimintaan liittyy ja miten ongelmien vaikutuksia voi minimoida tai poistaa. Työ on toteutettu narratiivisena kirjallisuuskatsauksena. Aineiston haussa on käytetty Interne- tistä löytyviä hakutietokantoja, joista on ollut luontevaa olettaa löytyvän tietojärjestelmätietee- seen liittyviä tutkimuksia ja artikkeleita. Aineistohaku on rajattu englanninkieliseen aineistoon. Hakusanoina tietokannoissa on käytetty kansainväliseen ja hajautettuun sovelluskehitykseen ja virtuaalitiimeihin liittyviä sanoja. Merkittävimpinä hyötyinä ohjelmistokehityksen kansainvälistymisessä nähdään muun muassa siitä saatavat kustannussäästöt sekä mahdollisuus rekrytoida osaavaa työvoimaa. Kansainväli- sesti hajautetun ohjelmistokehityksen esteet liittyvät työskentelyn maantieteelliseen, ajalliseen, kulttuurilliseen ja organisatoriseen etäisyyteen. Nämä etäisyydet monimutkaistavat hajautetun tai virtuaalisen tiimiin toimintaa verrattuna paikallisesti työskentelevään tiimiin. Esteisiin on py- rittävä vastaamaan sopeuttamalla käytetyt projektinhallinnan menetelmät hajautettuun työs- kentelyyn. Erityistä huolta on pidettävä siitä, että hajautetun työryhmän roolit ja sisäinen vas- tuunjako ovat kaikille ryhmän jäsenille selkeitä. Jos hajautetun työryhmän jäsenet tulevat erilai- silta kielialueilta ja kulttuurisista taustoista, on ryhmän johtamisessa varmistettava, että kaikki osallistujat jakavat yhteisen vision tehtävästä ja kommunikaatio hoidetaan niin, että väärinkäsi- tykset pystytään minimoimaan. Kansainvälisesti hajautetulla ohjelmistokehityksellä saavutetun kokonaishyödyn laskeminen on vaikeaa, koska osa kustannuksista on piileviä ja sen takia hanka- lia vertailla saavutettuihin hyötyihin. Kansainvälisellä ohjelmistokehityksellä katsotaan saavute- tun merkittäviä hyötyjä, joskin hyödyt ovat monesti tavoiteltuja vaatimattomampia. Työssä tun- nistetut ongelmat vastaavat keskeisiä projektinhallinnan yleisiä osa-alueita. Odotetusti hajautet- tujen tiimien keskeiset vaikeudet liittyivät tiedonvälitykseen ja kommunikointiin. AVAINSANAT: Offshore, GSD, Ohjelmistokehitys, Alihankinta, Ulkoistus, Virtuaalitiimi 3 Sisällys 1 Johdanto 6 1.1 Työn tavoite ja rajaus 6 1.2 Aikaisempi tutkimus 7 1.3 Tutkimusmenetelmät 7 1.4 Työn rakenne 9 2 Globaali ohjelmistokehitys 10 2.1 Historia 12 2.2 Nykytilanne 12 2.3 Hyödyt 13 2.4 Haitat 16 2.5 GSD-prosessi 20 2.5.1 Ketterät menetelmät 20 2.5.2 Perinteinen ohjelmistokehitys 22 3 Projektinhallinta globaalissa kontekstissa 24 3.1 Globaali projektinhallinta 24 3.1.1 Projektiryhmän jäsenet 26 3.1.2 Projektirakenne 28 3.2 GSD projektin hallinta 30 3.2.1 Integraation hallinta 31 3.2.2 Tietämyksen hallinta 32 3.2.3 Laajuuden ja resurssien hallinta 35 3.2.4 Suorituksen johtaminen 36 3.3 Riskienhallinta ja toteutettavuus 39 3.3.1 Riskienhallinnan viitekehyksiä 41 3.3.2 Riskienhallinta ja GSD 43 3.4 Kulttuurilliset seikat 44 3.4.1 Kulttuurien väliset erot 44 3.4.2 Kommunikaatio 45 4 4 Virtuaalitiimit 47 4.1 Kommunikaatio 48 4.2 Hajautetun tiimin rakenne 48 4.3 Virtuaalitiimin johtaminen 50 4.4 Virtuaalisuuden aste ja etäisyys 52 5 Johtopäätökset 56 5.1 Tutkimuksen luotettavuus 57 5.2 Jatkotutkimuksen aiheita 58 Lähteet 59 5 Kuviot Kuvio 1. Keskitetty projektirakenne. 29 Kuvio 2. Hajautettu projektirakenne. 30 Kuvio 3. GSD-projektinhallinnan viitekehys. 31 Kuvio 4. GSD Tietämyksen hallinta. 33 Kuvio 5. Riskienhallinnan pääprosessit. 42 Kuvio 6. Riskienhallinta projektinhallinnassa. 43 Kuvio 7. Virtuaalitiimi. 49 Kuvio 8. Löyhästi kytketty tiimi. 49 Kuvio 9. Virtuaalitiimin johtamisen tärkeimmät osatekijät. 50 Kuvio 10. Virtuaalitiimin yleisimmät ulottuvuudet. 53 Taulukot Taulukko 1. Hajautuksen ja yhteistyön mallit. 11 Taulukko 2. GSD:n hyödyt. 15 Taulukko 3. GSD:n hyötyjen toteutuminen. 18 Lyhenteet CSD Collaborative Software Development (Yhteistyö ohjelmistokehitys) DSD Distributed Software Development (Hajautettu ohjelmistokehitys) FDD Feature-driven development GSD Global Software Development (Globaali ohjelmistokehitys) GSE Global Software Engineering (Kansainvälinen ohjelmistosuunnittelu) SAFe Scaled Agile Framework XP Extreme Programming 6 1 Johdanto Globalisaatio on ollut vallitseva trendi yhteiskunnassamme jo vuosien ajan. Se vaikuttaa kaikkiin elämän osa-alueisiin, myös ohjelmistokehitykseen. Ohjelmistokehityksen osalta globalisaatiota ovat vauhdittaneet teknologian kehittyminen, halpeneminen sekä tie- donsiirtonopeuksien kasvu. Nyt eri puolilla maailmaan työskentelevien henkilöiden on mahdollista kommunikoida keskenään käytännössä ilman viiveitä. Koska yhä useampi ohjelmistoalalla toimiva organisaatio hakee menestystä kansainvälis- tymällä ja hajauttamalla tai ulkoistamalla toimintaansa, on tärkeää ymmärtää, mitkä te- kijät vaikuttavat kansainvälisten projektien onnistumiseen ja mitkä seikat toisaalta vä- hentävät todennäköisyyttä onnistua. Jain ja Suman (2018) esittävät, että merkittävä osa kansainvälisistä ohjelmistoprojekteista ei ole täyttänyt niille asetettuja vaatimuksia. Näin ollen on keskeistä selvittää, miten kansainvälisissä ohjelmistoprojekteissa onnistumisen todennäköisyyttä voi kasvattaa ja miten sen pahimpia ongelmakohtia on mahdollista välttää. Työskentelen itse yrityksessä, jossa tehdään töitä kansainvälisissä tiimeissä ja yhteistyön on onnistuttava yli maantieteellisten ja kulttuurillisten rajojen. Kyseiseen aiheeseen on itselläni myös omakohtainen tuntuma ja kiinnostus. 1.1 Työn tavoite ja rajaus Työn tarkastelun kohteena on projektinhallinta sekä hajautettujen tiimien toiminta kan- sainvälisessä ja hajautetussa ohjelmistokehityksessä. Työssä pyritään selvittämään, mil- laisia ongelmia kansainvälisten ohjelmistoprojektien projektinhallintaan sekä virtuaalitii- mien toimintaan liittyy. Lisäksi pyritään selvittämään, miten työssä tunnistettujen ongel- mien vaikutuksia voisi minimoida tai poistaa kokonaan. 7 Ensisijaisina tutkimuskysymyksinä ovat: Mitkä ovat kansainväliseen/ hajautettuun ohjel- mistokehitykseen liittyvän projektinhallinnan vaikeudet? Mitkä ovat virtuaalitiimiin/ ha- jautettuun tiimin liittyvät vaikeudet? Toissijaisena kysymyksenä on, miten näitä vaikeuk- sia voi minimoida. 1.2 Aikaisempi tutkimus Kansainvälisestä ohjelmistokehityksestä ja siihen liittyvästä projektinhallinnasta on tehty melko paljon tutkimusta. Tutkimukset yleisesti käsittelevät kuitenkin vain jotain projektinhallinnan osa-aluetta. Project Management Instituten (PMI) Project Management Body of Knowledge (PMBOK) käsittelee projektinhallintaa laaja-alaisesti, mutta sekään ei huomioi kansainvälisen tai hajautetun ohjelmistokehityksen vaatimuksia (Jain & Suman, 2018). 1.3 Tutkimusmenetelmät Työ on toteutettu narratiivisena eli kuvailevana kirjallisuuskatsauksena. Kangasniemi ja muut (2013) mukaan narratiivisessa kirjallisuuskatsauksessa valittua aihetta tarkastel- laan ja analysoidaan valitun kirjallisuuden pohjalta. Nimensä mukaisesti, narratiivisessa kirjallisuuskatsauksessa tuotetaan valitun aineiston pohjalta laadullinen, kuvaileva vas- taus tutkimuskysymyksiin. Varsinaisen työn vaiheistin tutkimuskysymyksen valintaan, ai- neiston valintaan, aineiston käsittelyyn sekä tulosten analysointiin. Aineiston haussa olen käyttänyt seuraavia hakutietokantoja: • Academic Search Elite • ACM Digital Library • IEEE Xplore • Research Gate • Science Direct 8 • SpringerLink • Wiley Online Library Lisäksi olen käyttänyt tietyissä tilanteissa Google Scholar-hakupalvelua. Aloitin aineiston haun tekemällä haun seuraaviin hakutietokantoihin: • ACM Digital Library • IEEE Xplore • Research Gate • Science Direct. Hakutietokannoissa käytin seuraavia hakuehtoja: • ("global software development" or "distributed software development") and ("Risk management" or "quality" or "project management") • ("global software development" or "distributed software development") and ("problem" or "challenge") • ”virtual team” • ”distributed team” Rajasin hakuehdot englanninkielisiin artikkeleihin. Artikkelien julkaisuvuodeksi rajasin välin 2015–2020. Näin löydetyistä artikkeleista lähdin liikkeelle. Ensimmäisessä vai- heessa hakutietokannoista löytämistäni artikkeleista olen pureutunut vielä syvemmälle tutkimalla lähteitä, joihin ko. artikkeleissa viitataan. Käyttämäni artikkelit olen valinnut sen perusteella, miten hyvin ne mielestäni osuvat käsiteltävään aiheeseen. Tässä vai- heessa hyväksyin mukaan artikkeleita, jotka eivät kuuluneet julkaisuvuoden osalta alku- peräisen rajauksen piiriin. 9 1.4 Työn rakenne Ensimmäisen luvun, johdannon, jälkeen käyn luvussa kaksi läpi yleisesti globaalia ohjel- mistokehitystä. Siinä esittelen, mitä kyseisellä käsitteellä tarkoitetaan. Yleisellä tasolla esitellään myös siitä saatavat hyödyt ja ilmeisimmät siihen liittyvät haitat. Luku kolme käsittelee kansainvälistä ohjelmistokehitystä projektinhallinnan näkökul- masta. Luvussa käydään läpi projektinhallinnan eri osa-alueita ja hajautetun ohjelmisto- kehityksen vaikutuksia niihin. Luvussa neljä käsitellään virtuaalitiimejä ja niihin liittyviä vaikeuksia. Luvussa esitellään erilaiset tavat modularisoida virtuaalitiimi sekä tavat, joilla virtuaalitiimi voidaan hajaut- taa. Luku viisi sisältää yhteenvedon ja kehitysehdotuksia jatkotutkimukseksi. 10 2 Globaali ohjelmistokehitys Yleisesti ohjelmistojen kehitysprosessi koostuu ohjelmiston rakentamiseksi tarvittavista toimista ja tehtävistä. Vaikka PMBOKin tarjoama projektikehityksen viitekehys ei suoraan ole Jainin ja Sumanin (2018) mukaan sovellettavissa globaaliin ohjelmistokehitykseen (Global Software Development, jatkossa GSD), se tarjoaa kuitenkin hyvän perusrungon yleiselle ohjelmistokehityksen lisäksi myös GSD:lle. Näin ollen voidaan katsoa, että oh- jelmistokehitysprosessin tavoitteena on myös GSD:ssä tuottaa laadukkaita ohjelmistoja budjetin ja aikataulun rajoissa. Prosessi ohjeistaa ohjelmiston kehitysprojektiin osallistu- vat henkilöt suorittamaan vaadittavat tehtävät, jotta ohjelmisto saadaan toteutettua. (Project Management Institute, 2013, s. 3–6; Jain & Suman, 2018) Globalisaatiolla on vahva vaikutus kaikkeen, myös ohjelmistokehitykseen. GSD:hen liittyy omia vaatimuksiaan, joihin on vastattava, jotta siinä on mahdollista menestyä. GSD:n eri- tyiset tarpeet erottavat sen keskitetymmästä sovelluskehityksestä. Näiden tarpeiden ta- kia prosessit, joita GSD:ssä sovelletaan, esimerkiksi perinteisemmät kehitysmenetelmät tai ketterät menetelmät, on räätälöitävä siihen sopiviksi. (Jain & Suman, 2015) Kansainvälisen ohjelmistokehityksen termit eivät kuitenkaan ole alan kirjallisuudessa täysin vakiintuneet. Esimerkiksi Sangwan ja muut (2006, s. 3–4) määrittelevät GSD:n työskentelyksi, jossa ohjelmistokehitystä tekevät tiimit toimivat maantieteellisesti eri paikoissa. Yhteistyötä tekevät tiimit voivat myös kuulua samaan tai eri organisaatioihin. Sen sijaan ul Haq ja muut (2011) mukaan GSD on asiakkaan ja toimittajan välinen sopi- mussuhde, jossa asiakas ulkoistaa kaiken tai osan ohjelmistokehityksestä toimittajalle, joka tarjoaa sovitut palvelut sovittua korvausta vastaan. Muita GSD:n lisäksi käytettyjä termejä ovat muun muassa, hajautettu ohjelmistokehitys (Distributed Software Development, DSD), kansainvälinen ohjelmistosuunnittelu (Global Software Engineering, GSE) ja yhteistyö ohjelmistokehitys (Collaborative Software Deve- lopment, CSD). Näitäkään termejä ei kirjallisuudessa käytetä aivan yksiselitteisesti. (Sharma ja muut, 2015; Denhere ja muut, 2015). Lisäksi käytössä ovat termit offshore ja 11 onshore. Offshore tarkoittaa sitä, että työ tehdään jossain toisessa maassa ja onshorella tarkoitetaan tilannetta, jossa työ tehdään samassa maassa, jossa se tilattiin (El Bajta ja muut, 2018). Prikladnicki ja Audy (2010) esittävät loogisen jaottelun DSD:lle, GSD:lle, offshorelle ja onshorelle sekä ulkoistamiselle (outsourcing). Offshore ei tarkoita sitä, että työ olisi ul- koistettu kolmannelle osapuolelle. Myös sama yritys voi teettää työtä offshorena ilman ulkoistusta, omassa ulkomailla sijaitsevassa toimipisteessään. Eli offshore-työtä voi teet- tää ilman ulkoistusta ja ulkoistaa voi niin, ettei työtä tehdä offshorena. Käytännössä GSD on offshore-työtä. Prikladnicki ja Audy (2010) määrittelevät hajautetun ohjelmistokehi- tyksen (DSD) niin, että siinä tiimin jäsenet työskentelevät maantieteellisesti hajautet- tuina. Globaalissa ohjelmistokehityksessä (GSD) hajautuksen mittakaava on suurempi ja hajautuksen taso vähintäänkin kansainvälinen. Taulukossa 1 on selvennetty termistöä maantieteellisen etäisyyden ja organisaatioiden suhteen. Taulukko 1. Hajautuksen ja yhteistyön mallit. Organisaatio Sama organisaatio Eri organisaatio Maantieteellinen etäisyys Sama fyysinen paikka Keskitetty työsken- tely Keskitetty työsken- tely + ulkoistus Sama maa DSD DSD + ulkoistus Eri maa GSD/ offshore GSD/ offshore + ul- koistus 12 2.1 Historia Kansainvälisten kehitysryhmien toteuttamilla ohjelmistoilla on pitkä historia. Jo 1960-lu- vulla IBM teki ohjelmistokehitystä hajautetusti useammassa eri maantieteellisessä pai- kassa ja jopa useammalla mantereella (Cusumano, 2008). Suuret kansainväliset trendit, kuten globalisaatio ja tietoteknisen koulutustason nousu ympäri maailmaa, ovat vaikuttaneet myös kansainvälisen ohjelmistokehityksen muotou- tumiseen (Denhere ja muut, 2015). Globalisaation myötä esteet kansainvälisen ohjelmis- tokehityksen toteuttamisen edessä ovat pienentyneet ja viimeistään 1990-luvulta läh- tien kansainvälinen ohjelmistokehitys on kasvanut voimallisesti (Prikladnicki ja muut, 2006). Koska iso osa ohjelmistokehityksestä on kommunikointia kehitykseen osallistuvien mui- den henkilöiden kanssa ja koska henkilökohtainen vuorovaikutus on kansainvälisessä oh- jelmistokehityksessä maantieteellisten erojen vuoksi hankalampaa, on yksi tärkeä kan- sainvälisen ohjelmistokehityksen mahdollistanut tekijä ollut kommunikaatioteknologian kehittyminen (Herbsleb & Mockus, 2003). Kommunikaatioteknologian kehitys on tuonut kansainvälisen ohjelmistokehityksen käyttöön monia työkaluja, kuten esimerkiksi sähkö- postin, videoneuvottelut, erilaiset chat-työkalut ja mahdollisuuden jakaa henkilökohtai- sen tietokoneen työpöytä neuvottelukumppanin kanssa. Lisäksi on kehitetty erilaisia projektinhallinnan työvälineitä, jotka helpottavat projektin hallintaa kansainvälisessä kontekstissa. (Jain & Suman, 2018) 2.2 Nykytilanne Jainin ja Sumanin (2015) mukaan ohjelmistokehitys jakautuu yhä enemmän maantieteel- lisesti ja kansainvälisestä sovelluskehityksestä on tullut tietyillä sovellusalueilla vallitseva normi. Ohjelmistokehityksen globalisaatio tapahtuu joko niin, että kehitys tai osa siitä annetaan organisaation ulkopuolisen yhteistyökumppanin hoidettavaksi (offshore 13 outsourcing) tai sitten organisaatio perustaa ulkomaille oman erillisen osaamiskeskuk- sen (offshore insourcing). Silloin kun sovelluskehitykseen osallistuvat kehitystiimit jakau- tuvat työskentelemään maantieteellisesti useamman valtion alueelle, voidaan puhua globaalista ohjelmistokehityksestä (GSD). Keskitetyssä ympäristössä tapahtuvan sovelluskehityksen avuksi löytyy standardoituja prosessimalleja. Hajautettua kehitystä tukevista malleista sen sijaan on puutetta. Yrityk- sissä on hajautetussa sovelluskehityksessä sovellettu pidemmän aikaa perinteisiä pro- sesseja, kuten vesiputousmallia. Koska hajautettujen projektien epäonnistumisaste on ollut erittäin korkea, yritykset ovat alkaneet enenevästi siirtyä käyttämään ketteriä me- netelmiä, joilla toivotaan päästävän parempaan onnistumisprosenttiin. Ketterien mene- telmien edut näkyvät erityisesti muutoksenhallinnassa. (Cusumano, 2008) 2.3 Hyödyt GSD on nykyaikainen liiketoimintamalli, joka mahdollistaa yritykselle kansainvälisen kil- pailun merkittävin kustannussäästöin. Ohjelmistoyhtiöt siirtävät kehitystyötään kansain- välisemmäksi strategisten ja taloudellisten etujen toivossa (Jiménez ja muut, 2009). Jain ja Suman (2018) esittävät, kehitystoiminnan siirtämiselle kansallisten ja organisatoristen rajojen yli, tärkeimmäksi hyödyksi mahdollisuuden vähentää kustannuksia käyttämällä vähemmän kehittyneiden talouksien tarjoamaa koulutettua työvoimaa. Muina hyötyinä kustannussäästöjen ohella Conchúir ja muut (2009a) mainitsevat mahdollisuuden pal- kata osaavia työntekijöitä ja päästä lähemmäs markkinoita ja kuluttajia sekä näin hyö- dyntää markkinoita lähellä toimivan toimittajan paikallistuntemusta. Tietyissä tapauk- sissa yritykset saattavat myös hyötyä kohdevaltion suotuisasta politiikasta ja verohelpo- tuksista (Gopal ja muut, 2002). Ulkomailla toimivalta yhteystyökumppanilta palveluita hankkiva yritys saattaa hyötyä jär- jestelystä lisäksi sitä kautta, että yhteistyökumppani on kokenut toimija vastaavanlaisissa kehitysprojekteissa. Tällöin sen työn laatu ja palvelun taso on päässyt kehittymään 14 korkeaksi ja lisäksi sillä saattaa olla hallussaan esimerkiksi kyseisessä tehtävässä tarvitta- vaa spesifistä teknologiaa (Khan ja muut, 2010). Asiakasyrityksen motivaationa yhteis- työlle saattaa myös olla keskittyminen puhtaasti omaan ydinliiketoimintaan, jolloin pro- sessien ja järjestelmien toteutus ulkoistetaan yhteistyökumppanille. Yhteistyökumppa- nin kanssa toteutettava toimintojen ulkoistaminen saattaa tuottaa hyötynä vielä sen, että asiakasorganisaatio saa jaettua ohjelmistokehitykseen liittyvän riskin toisen organi- saation kanssa (Niazi ja muut, 2016b). Edellä mainittuja GSD:n hyötyjä Ågerfalk ja muut (2008) nimittävät ”tunnetuiksi” hyö- dyiksi. ”Tunnettujen” hyötyjen lisäksi he ovat tunnistaneet vielä joukon ”tuntemattomia” hyötyjä. ”Tuntemattomat” hyödyt he ryhmittelevät organisaatioon liittyviin hyötyihin, tiimiin liittyviin hyötyihin sekä prosesseihin ja tehtäviin liittyviin hyötyihin. Heidän mu- kaansa ”tuntemattomista” hyödyistä kaksi liittyy pääasiassa organisaatioon. Organisaa- tiotasolle kytkeytyvät hyödyt ovat innovaatiot ja jaetut parhaat käytännöt sekä parantu- nut resurssien allokaatio. Innovaatioita ja hyviä käytäntöjä syntyy ja jaetaan, kun erilai- sista taustoista tulevat henkilöt tekevät töitä keskenään. Resurssien parantunut allokaa- tio voi syntyä muun muassa siitä, että halvan työvoiman maista saadaan haettua kustan- nussäästöjä, jolloin kustannustasoltaan arvokkaammat henkilöresurssit voidaan sijoittaa organisaation kannalta strategisesti kannattavampiin tehtäviin. Tiimin tasoon liittyviä ”tuntemattomia” hyötyjä Ågerfalk ja muut (2008) tunnistavat kolme kappaletta. Ne ovat parantunut tehtävien modularisaatio, vähentyneet koordi- naatiokustannukset ja tiimien lisääntynyt itsenäinen toiminta. Prosesseihin ja tehtäviin liittyviä ”tuntemattomia” hyötyjä he esittävät kolme kappaletta. Niitä ovat määrämuo- toinen viestintä, parantunut dokumentaatio ja selkeästi määritellyt prosessit. Ågerfalk ja muut (2008) esittämät hyödyt GSD:lle on esitetty taulukossa 2. 15 Taulukko 2. GSD:n hyödyt (Ågerfalk ja muut, 2008). Organisaation hyödyt Tiimin hyödyt Prosessin/ tehtävän hyödyt ”Tunnetut” hyödyt • Kustannussäästöt • Osaavan työvoiman saatavuus • Lyhyempi aika markki- noille pääsyyn • Markkinoiden ja asiak- kaan läheisyys ”Tuntemattomat” hyödyt • Innovaatiot ja jaetut parhaat käytännöt • Parantunut resurssien allokointi ”Tuntemattomat” hyödyt • Parantunut tehtävien modularisointi • Vähentyneet koordi- naatiokustannukset • Lisääntynyt tiimien it- senäinen toiminta ”Tuntemattomat” hyödyt • Määrämuotoinen viestintä, josta jää auditoitava jälki • Parantunut dokumentaatio • Selkeästi määritellyt pro- sessit Ebertin ja De Neven (2001) mukaan GSD ohjaa parhaassa tapauksessa tiimit jakamaan tehtävänsä järkeviin osakokonaisuuksiin. Osiin jakaminen mahdollistaa sen, että osako- konaisuudesta vastaava taho pystyy ottamaan omasta osuudestaan kokonaisvastuun. Ebertin (2011, s.18) mukaan innovaatiot lisääntyvät ja parhaat käytännöt leviävät ympä- ristöissä, joissa erilaisista koulutuksellisista, organisatorisista ja kulttuurillisista lähtökoh- dista tulevat tiimin jäsenet työskentelevät yhdessä. Näin ollen erilaisista taustoista tule- vat projektiryhmän jäsenet lisäävät parhaassa tapauksessa ryhmän tuottavuutta tuo- malla ryhmän toimintaan erilaisia tapoja työskennellä sekä ratkaista ongelmia. Espinosa ja Carmel (2004) ovat esittäneet, että kansainvälisten tiimien on mahdollista tietyin rajoituksin nopeuttaa kehitystyötä käyttämällä ”follow-the-sun”-periaatetta. ”Fol- low-the-sun”-periaatteessa kansainväliset tiimit on sijoitettu maantieteellisesti eri 16 aikavyöhykkeille niin, että tiimien työajat eroavat toisistaan. Tällöin tiimit eivät työsken- tele samaan aikaan työstäen samoja tehtäviä. ”Follow-the-sun”–periaate mahdollistaa tarvittaessa ympärivuorokautisen työskentelyn, jolloin työt voidaan siirtää tiimiltä toi- selle edellisen tiimin lopettaessa työskentelyn seuraavan tiimin aloittaessaan vuoroaan. Jatkuvasti käytettynä, etenkin ohjelmistokehitystyössä, ”follow-the-sun” ei heidän mu- kaansa kuitenkaan ole toimiva ratkaisu, koska siihen liittyvät koordinaatio-ongelmat kas- vavat liian suuriksi. Hajaantuneisuus lisää tiimin itsenäisyyttä. Itsenäisyyden lisääntyminen johtuu siitä, että hajautumisen kasvamisen myötä kommunikaatio hidastuu. Lisäksi koska hajautetussa ympäristössä joudutaan kommunikoimaan enemmän kirjallisesti ja käyttämällä erilaisia kommunikaatioteknologioita, tallentuu suuri osa viesteistä sähköisessä muodossa. Se luo viestintään määrämuotoisuutta ja dokumentoi toimintaa. (Gumm, 2006; Conchúir ja muut, 2009a) 2.4 Haitat Hyötyjen lisäksi GSD-projekteihin liittyy myös lukuisia ongelmia. Maantieteellisesti ha- jautettujen projektien hallinta on monimutkaisempaa kuin paikallisesti toteutettujen projektien. Hajautetun projektin hallinnassa kohdataan normaalin projektinhallinnan vaikeudet ja sen lisäksi vielä hajautuksesta syntyvät omat tarpeensa (Casey, 2010). Jainin ja Sumanin (2018) mukaan GSD-projektien epäonnistumisriskiä lisäävät maantieteelli- seen, ajalliseen, kulttuuriseen ja organisatoriseen hajauttamiseen liittyvät riskit. Näitä riskejä ovat muun muassa korkeammat koordinaatiokustannukset, vähentynyt henkilö- kohtainen kommunikaatio ja kulttuuriin liittyvät väärinkäsitykset. Herbsleb ja Mockus (2003) painottavat riskeinä vielä erityisesti eri puhuttuihin kieliin liittyviä ongelmia. Näi- den potentiaalisten uhkien takia projektin yhteydessä on tehtävä riittävä riskiarvio ja projektin aikana on panostettava riskienhallintaan. Jos GSD-projektia on toteuttamassa osallistujia eri organisaatioista, he saattavat noudattaa erilaisia prosesseja, joka johtaa helposti ongelmiin integraatiossa. Tästä aiheutuu helposti turhautumista, 17 epäluottamusta ja väärinkäsityksiä, jotka puolestaan johtavat viivästymisiin, virheisiin ja heikentyneeseen laatuun. Useammassa eri maassa toimittaessa, pitää myös ottaa huo- mioon se, että eri maiden lainsäädännöissä ja vallitsevissa käytännöissä voi olla eroa (Sa- leem, 2019). Khan ja muut (2011) esittävät GSD-projektien riskiä lisäävän lisäksi sen, että monet organisaatiot aloittavat globaalin ohjelmistokehityksen niin, ettei heillä ole etu- käteen käsitystä oman projektijohtamisensa kyvystä selviytyä kansainvälisen toiminnan vaatimuksista. Epäonnistumiset projektijohtamisessa lisäävät riskiä projektin kustannus- ten kasvusta ja aikataulun pettämisestä. Herbsleb ja Moitra (2001) jaottelevat artikkelissaan GSD:hen liittyvät vaikeudet yllä esi- tetystä vielä hieman eri tavalla. He jaottelevat ne strategisiin, kulttuurillisiin, kommuni- kaatioon, tiedon hallintaan, projektin ja prosessien hallintaan sekä teknisiin kysymyksiin. Strategiset hankaluudet liittyvät työtehtävien ja työkokonaisuuksien jakamiseen sekä joissain tilanteissa GSD:tä kohtaan tunnettuun vastustukseen. Mahdolliset kulttuurilliset ongelmat muodostuvat erilaisten kulttuurien keskinäisestä hankauksesta ja kulttuu- rieroista johtuvista näkemyseroista. Kommunikaation ja tiedon hallinnan vaikeudet liit- tyvät GSD:ssä suurelta osin siihen, että epävirallinen kommunikaatio puuttuu, eikä tieto ja tietämys siirry eri fyysisten sijaintipaikkojen välillä. Projektin ja prosessien hallinnan hankaluudet koostuvat eri sijaintipaikoissa työskentelevien tiimien työn synkronoinnista. Tekniset ongelmat liittyvät käytettyihin teknologioihin, kuten tiedonsiirtoteknologiaan ja muihin työvälineisiin. Conchúir ja muut (2009a) mukaan GSD:n potentiaalisesti tarjoamat edut on kuitenkin mahdollista saavuttaa vain osittain hajautetusta työskentelystä johtuvien ongelmien ta- kia. Heidän mukaansa ne voidaan jaotella maantieteellisiin, ajallisiin ja sosiaalis-kulttuu- rillisiin ongelmiin. Ne vaikuttavat keskeisimmin viestintään, joka vaikeutuu ja kallistuu hajautuksen myötä, mutta myös koordinointiin ja yhteistyöhön. Tutkimuksessaan Conchúir ja muut (2009b) seurasivat kolmea kansainvälistä ohjelmistokehitystä tekevää organisaatiota. Heidän havaintonsa GSD:n oletettujen hyötyjen toteutumisesta on ku- vattu taulukossa 3. 18 Taulukko 3. GSD:n hyötyjen toteutuminen (Conchúir ja muut, 2009b). Oletettu hyöty Toteuman määrä/ havainnot Arvio toteumasta Alentuneet kustan- nukset • Selvä palkkaero länsimaiden ja kehitty- vien maiden välillä • Hajautettuna olivat vain vähemmän monimutkaiset ja alhaisen lisäarvon työt. • Merkittäviä lisäkustannuksia viestin- nässä ja koordinoinnissa yms. Osittain toteutunut Aikavyöhykkeiden hyödyntäminen • Eri aikavyöhykkeillä työskentely ei tuo- nut hyötyjä, mutta se vähensi yhteistä työskentelyaikaa sekä pakotti jousta- maan työajoissa. • ”follow-the-sun”-periaatetta käytettiin vain vähän, esimerkiksi testauksessa. Ei hyötyä Toimipisteiden välinen työn modulaarisuus • Modulaarisuus voi vähentää tarvitta- van viestinnän määrää toimipisteiden välillä. • Voi haitata tiimiytymistä toimipistei- den välillä. Osittain toteutunut Ammattitaitoisten työntekijöiden saata- vuus • GSD mahdollistaa ammattitaitoisten työntekijöiden rekrytoinnin. • Työtekijöiden vaihtuvuus voi olla kor- kea. • Kaikille tarvittaville osaamisalueille ei välttämättä löydetä työntekijöitä hel- posti. Osittain toteutunut 19 Oletettu hyöty Toteuman määrä/ havainnot Arvio toteumasta • Sosio-kulttuurillisia ongelmia on run- saasti. Innovaatio ja jaetut parhaat käytännöt • Tiedonjakaminen heikkenee, jos mata- lapalkkaiset kollegat koetaan uhaksi. Ei hyötyä Lyhyt etäisyys markki- noihin ja asiakkaaseen • Vaikka lyhyt etäisyys tarjoaa parem- man kontaktin asiakkaaseen, kulttuu- riin liittyvät ongelmat lisääntyvät. Osittain toteutunut Herbslebin ja Mockusin (2003) mukaan hajautettujen tiimien jäsenillä on selvästi vähem- män henkilökohtaista ja epävirallista kanssakäymistä keskenään. He kuuluvat erilaisiin kulttuureihin, puhuvat mahdollisesti eri kieliä ja työskentelevät eri aikavyöhykkeillä, jo- ten heidän yhteistyönsä ja tuottavuutensa ei pääse kasvamaan samalla tavalla kuin kes- kitetymmässä ympäristössä (Anantatmula & Thomas, 2010). Vaikka kaikki hajautetun tiimin jäsenet puhuisivatkin yhteistä kieltä, se ei Ebertin ja De Neven (2001) mukaan vielä riitä takaamaan täydellistä yhteisymmärrystä. Yhteisestä pu- hutusta kielestä huolimatta kaikki tiimin jäsenet eivät välttämättä ymmärrä kaikkien kä- sitteiden merkitystä täysin samalla tavalla. Esimerkiksi englantia äidinkielenään puhu- valle tietyt sanat tai lauserakenteet saattavat merkitä asioita, jotka eivät toisenlaisesta kielitaustasta tulevalle henkilölle helposti aukea. Kielen täsmällisen merkityksen ymmär- täminen korostuu erityisesti, kun ollaan tekemässä kirjallisia sopimuksia. GSD:n kokonaiskustannuksia ja sillä saavutettavia hyötyjä voi olla vaikea laskea, koska osa GSD:n kustannuksista tulee piilokustannuksina. GSD:n kustannussäästöjen arvioin- nissa tulisi ottaa huomioon muun muassa eri aikavyöhykkeillä työskentelystä aiheutuvat kustannukset, tarvittavien työvälineiden käyttökustannukset sekä työntekijöiden päte- vyys ja heidän kokemuksensa. Jotta GSD olisi kannattavaa, pitäisi hajautettuun työhön liittyvistä ylimääräisistä kustannuksista, kuten matkustamisesta, työvälineistä tai 20 koulutuksista, aiheutuvien kulujen jäädä pienemmiksi kuin GSD:n kustannushyödyt. (Jain & Suman, 2018) 2.5 GSD-prosessi Globaali ohjelmistokehitys (GSD) sekä globaalisti hajautetut tiimit yleistyvät jatkuvasti. Perinteinen syy GSD:hen on ollut kustannussäästöjen hakeminen siirtämällä työtä hal- vemman kustannustason maihin. Halvempien henkilöstöresurssien ohella GSD:n avulla voidaan päästä palkkaamaan myös uusia työntekijöiltä uusilta alueilta. Tämä auttaa li- säksi uusille markkina-alueille siirtymisessä. Perinteisille johtamismalleille GSD tuo vaa- teita. GSD lisää erilaisten toimijoiden ja yhteistyötahojen määrää, jolloin johtamismalleja voidaan joutua sopeuttamaan vastaamaan tilannetta. (Noll ja muut, 2016) Suurimmassa osassa tapauksista kansainvälistä sovelluskehitystä tehdään asiakas- ja pal- veluntarjoajayritysten kesken. Tällöin asiakas hyötyy kustannussäästöistä ja palveluntar- joaja saattaa hyötyä valtion myöntämistä tuista, esimerkiksi verohelpotuksista. Asiakas pystyy myös jakamaan riskejään, ulkoistamaan teknistä työtä ja keskittymään ydinliike- toimintaansa. (Niazi ja muut, 2016b; Jain & Suman, 2015) 2.5.1 Ketterät menetelmät Vaikka ketterien menetelmien juuret juontuvat 1990-luvulle, ketterien menetelmien al- kuna pidetään yleensä vuotta 2001, jolloin ajatus ketterästä ohjelmistokehityksestä vi- rallisesti esiteltiin suurelle ohjelmistokehittäjien yhteisölle (Agile Alliance, 2020). Kette- rien menetelmien pohjalla on tarve vastata muutokseen kesken ohjelmistokehityspro- jektin. Ketterä kehitys on ylätason käsite ja sen alle kuuluu lukemattomia viitekehyksiä ja käytäntöjä, jotka perustuvat ketterän ohjelmistokehityksen julistukselle: Agile Manifes- tolle. Ketterän kehityksen viitekehyksiä ovat muun muassa Scrum, Extreme Programming (XP), Feature-driven development (FDD) ja Scaled Agile Framework (SAFe). 21 Näiden kahden suuren ohjelmistokehitystrendin, ketterien menetelmien ja kansainväli- sesti hajautetun työskentelyn, yhdistäminen muodostaa kuitenkin yhden suurimmista hajautettuun ohjelmistokehitykseen liittyvistä ongelmista (Cusumano, 2008). Hankaluu- det tulevat selvemmin esiin, kun ohjelmistokehitystiimit kasvavat suuriksi. Ketterien me- netelmien käyttöönotosta haetaan tällä hetkellä ohjelmistokehityksessä hyötyjä ja se ko- rostaa niiden ja GSD:n välisiä ongelmakohtia. Layman ja muut (2006) tuovat esiin, että ketterässä ohjelmistokehityksessä epämuodollinen ja spontaani kommunikaatio on kes- keisessä osassa. Hajautetussa työskentelyssä tällaisen kommunikaation mahdollisuus kuitenkin vähenee. Lisäksi myös mahdolliset kulttuurilliset erot heikentävät kommuni- kaation tehokkuutta. Ebert ja Paasivaara (2017) näkevät hajautetun ohjelmistokehityk- sen ja ketterien menetelmien välisenä ongelmana skaalautuvuuden. Ketterien menetel- mien mallit, kuten Scrum, on kehitetty paikallisempaan työskentelyyn ja monesti myös kohtalaisen pienten kehitystiimien käyttöön. Niiden käyttöönotto suurissa kansainväli- sesti hajautetuissa kehitystiimeissä on hankalaa. Käytettäessä ketteriä ohjelmistokehitysmenetelmiä hajautetusti toteutetussa ohjelmis- tokehitysprojektissa, joudutaan ketteriä menetelmiä mukauttamaan kyseiseen ympäris- töön. Robinson (2019) väittää, ettei ainakaan Scrum sellaisenaan sovellu käytettäväksi globaalissa ohjelmistokehityksessä ilman modifiointia. Modifioiduilla ketterillä menetel- millä on kuitenkin saavutettu onnistuneita tuloksia kansainvälisissä ohjelmistoprojek- teissa. Ketterän ja hajautetun ohjelmistokehityksen yhdistelmästä käytetään nimitystä Distributed Agile Software Development. Distributed Agile Software Development pyrkii vastaamaan vaatimuksiin, jota näiden kahden ohjelmistokehitystrendin yhteensovitta- misessa on havaittu, kuten esimerkiksi kommunikaatioon ja koordinaatioon liittyviin on- gelmiin. Yhdistelmä pyrkii tarjoamaan etuja molemmista menetelmistä, vaikka ne perus- teiltaan ovatkin monilta osin keskenään hyvin ristiriitaisia (Kaur & Sharma, 2014). Kette- rissä menetelmissä korostetaan sekä tiimin jäsenten että tiimin jäsenten ja asiakkaan vä- listä tiivistä yhteistyötä sekä epämuodollista kommunikaatiota. GSD:ssä sen sijaan ohjel- mistokehitykseen osallistuvat henkilöt on hajautettu maantieteellisesti, ja he 22 kommunikoivat paljon muodollisemmin käyttäen erilaisia kommunikaatiovälineitä. Vies- tintäohjelmistojen kehittyminen ja etenkin tiedonsiirtonopeuksien riittävä kasvu ovat kuitenkin mahdollistaneet kasvokkain tapahtuvan viestinnän korvaamisen kommunikaa- tiovälineiden käytöllä ketterissä kehitysprojekteissa (Robinson, 2019). Suuret aikaerot saattavat silti vaikeuttaa yhteisten säännöllisten palaverien pitämistä, vaikka viestintä- tekniikka sen muuten mahdollistaisikin. Vaikka Scrum ei sellaisenaan täysin sovikaan käy- tettäväksi GSD:ssä, sen osioita ja käytäntöjä on käytetty paljon hyödyksi myös GSD:ssä. Vallon ja muut (2018) ovat työssään (vuosina 1999–2016) huomanneet, että monissa GSD-projekteissa on omaksuttu Scrumista käyttöön esimerkiksi seisomakokokoukset (standup meeting), backlogit, sprintit ja sprintteihin liittyvät retrospektiivit sekä demot. Myös normaaleista ketteristä menetelmistä tutut jatkuva integraatio, käyttötapaukset ja pariohjelmointi ovat yleisesti käytössä. Alzoubi ja muut (2016) suosittelevat suunnittelemaan viestinnän huolellisesti, jotta ket- terien menetelmien ja kansainvälisesti hajautetun ohjelmistokehityksen yhdistämisestä aiheutuvat vaikeudet saataisiin minimoitua. Keskeistä tässä on työskentelyä tukevan kommunikaatioteknologian käyttö ja dokumentaation riittävä hyvä ylläpito. Jotta hajau- tetun ryhmän reaaliaikainen kommunikaatio olisi mahdollista, tulisi työajat saada sovit- tua niin, että ryhmän jäsenillä olisi yhteinen aikaikkuna, jolloin on mahdollista pitää re- aaliaikaisia palavereja. Sikäli kuin mahdollista, myös fyysisiä tapaamisia tulisi järjestää. Näitä voisivat olla esimerkiksi ryhmäkokoukset projektien alussa ja vierailut projektin ai- kana eri toimipisteiden tai ryhmien välillä. 2.5.2 Perinteinen ohjelmistokehitys Ketterien menetelmien ja hajautetun ohjelmistokehityksen yhteensovittamisesta aiheu- tuvien vaatimusten johdosta monet yritykset ovat tehneet tietoisen ratkaisun käyttää GSD-projektiensa projektinhallinnassa perinteisempiä, vesiputousmallin kaltaisia, mene- telmiä (Cusumano, 2008). Näin toimimalla menetetään iteratiivisten ja ketterien teknii- koiden tuoma etu siitä, että pystytään vastaamaan nopeasti vaatimusten muutoksiin 23 projektin ollessa jo käynnissä. Perinteisten projektinhallintamenetelmien käyttäminen GSD-projektissa vähentää kuitenkin kommunikointiin ja koordinointiin liittyviä ongelmia. Cusumano (2008) kehottaa käyttämään jokaisessa projektissa kyseiseen projektiin ja ti- lanteeseen parhaiten sopivaa mallia ja tekniikkaa. Hänen hyväksi havaitsemansa käy- täntö on se, että projekti aloitetaan iteratiivisena prosessina, toteutusvaiheessa siirry- tään perinteiseen menetelmään, esimerkiksi vesiputousmalliin ja projektin lopussa vaih- detaan taas takaisin iteroivaan malliin. Käytännössä tämä voisi tarkoittaa esimerkiksi sitä, että ohjelmiston toimittajan edustaja työskentelee asiakkaan lähellä. Asiakkaan lähellä hoidetaan projektinhallinta ja vaatimusmäärittely. Yksityiskohtaisempi suunnittelu, to- teutus, testaus ja integraatio hoidetaan hajautettuna työskentelynä. Tämän jälkeen to- teutetut osat tuodaan asiakkaalle hyväksymistestausta varten, jonka jälkeen tehdään uusi iteraatio. 24 3 Projektinhallinta globaalissa kontekstissa Project Management Instituten (2013, s. 3–5) mukaan projekti on tilapäinen panostus tuotteen, palvelun tai muun vastaavan tekemiseksi. Projektinhallinnassa projektiin sovelletaan sopivia tietoja, taitoja, työkaluja sekä tekniikoita, jotta projektin vaatimukset saadaan täytettyä. Projektinhallintaan kuuluu viisi prosessiryhmää, jotka ovat: aloitus, suunnittelu, toteutus, seuranta ja valvonta sekä projektin päättäminen. 3.1 Globaali projektinhallinta Bannerman ja muut (2012) mukaan globaalilla ohjelmistokehityksellä (GSD) tarkoitetaan ohjelmistokehitystä, jota toteutetaan useamman valtion tai mantereen alueella. GSD lisää tuntuvasti projektien potentiaalia ja kuten Ågerfalk ja muut (2008) esittävät, se takaa muun muassa pääsyn käyttämään laajempaa osaavaa henkilöresurssipohjaa, tuo kustannusetuja ja mahdollistaa vuorokauden ympäri työskentelyn. Silti GSD lisää myös huomattavasti vaatimuksia projektinhallintaan. Nämä vaatimukset syntyvät GSD- projektien monimuotoisuudesta ja monimutkaistumisesta (Holmström ja muut, 2006). Maantieteellisen jakautumisen lisäksi hajautettu projektiryhmä kohtaa mahdollisesti erilaisista aikavyöhykkeistä ja kulttuurieroista johtuvia vaikeuksia. Kulttuurieroihin kuuluvat muun muassa erilaiset kielet, kansalliset perinteet, arvot ja käyttäytymisnormit (Jaanu ja muut, 2012). Saleem (2019) väittää, että syynä useiden GSD-projektien epäonnistumiseen on yrityk- sen tai organisaation lähteminen mukaan kansainväliseen ohjelmistokehitykseen ilman riittävää valmistautumista etukäteen. Kompastuskiveksi muodostuu monesti projektin- hallinta, jota ei osata sopeuttaa oikein vastaamaan GSD:n vaatimuksia. Ebert ja De Neve (2001) havaitsivat, että suurissa kansainvälisesti hajautuneissa kehitysorganisaatioissa saattaa syntyä ongelmia kehitystiimien välisessä töiden koordinoinnissa. Äärimmäinen esimerkki on tilanne, jossa eri tiimit työstävät yhteisestä globaalista, niin sanotusta pe- rustuotteessa, paikallisia omia versioitaan. Tällöin vaarana on, että kehitysversiot 25 saattavat eriytyä toisistaan niin, ettei niiden keskitetty, globaali kehittäminen ja eri versi- oiden synkronointi ole enää jatkossa mahdollista. Huono kommunikaatio ja koordinointi ovat usein syynä siihen, että hajautetussa ohjel- mistonkehityksessä syntyy ongelmia. Kun ihmiset työskentelevät keskitetysti samassa paikassa, he jakavat luontaisesti tietoa keskenään epävirallisessa kanssakäymisessä. Tieto esimerkiksi asiantuntemuksesta, tehtävien prioriteetista ja tilanteesta siirtyy viral- listen ja puolivirallisten kokousten lisäksi myös erilaisissa kahvi- ja käytäväkeskusteluissa. Tällaista tiedonsiirtoa ei pääse tapahtumaan yhtä helposti hajautetussa työskentely-ym- päristössä, ja tutkimukset osoittavatkin vahvasti kommunikaation vähenevän, kun työto- verit ovat fyysisesti erossa toisistaan. Nämä hajautetussa ympäristössä menetetyt kom- munikaation yksityiskohdat ovat kriittisen tärkeitä tehokkaan viestinnän ja koordinoinnin muodostamisessa. Näiden puuttuminen saattaa herkästi vaikeuttaa kommunikaatiota ja hidastaa työskentelyä. Koska hajautetussa ympäristössä suora ja reaaliaikainen kommu- nikaatio vähenee, korostuu epäsuoran viestinnän rooli. (Herbsleb & Mockus, 2003; El Bajta ja muut, 2018) GSD lisää projektien monimutkaisuutta verrattuna paikallisesti toteutettuihin projektei- hin. Sen tähden projektinhallinta on erityisen tärkeässä roolissa GSD-projekteissa koko projektin keston ajan. Täsmällisellä projektinhallinnalla varmistetaan projektin tavoittei- den asianmukainen saavuttaminen. El Bajta ja muut (2018) mukaan GSD-projektien pro- jektinhallinnassa tulisi erityisesti panostaa tarkkaan etukäteissuunnitteluun sekä projek- tin aikaiseen seurantaan ja valvontaan. Ohjelmistokehitysprojekteissa käytetään enene- vissä määrin ketteriä ohjelmistokehitysmenetelmiä. Sen osalta GSD-projektit eivät muo- dosta poikkeusta ja ketterät menetelmät ovatkin usein käytössä myös GSD:ssä. Paikalli- sesti toteutettuna ketterät menetelmät tukeutuvat pitkälti nopeaan ja säännölliseen kommunikaatioon sekä välittömään palautteen antoon. Samalla ketterissä menetel- missä määrämuotoisen dokumentaation laatiminen priorisoidaan alemmas kuin perin- teisissä ohjelmistonkehitysmenetelmissä. GSD:ssä työskentelyn hajauttaminen kuitenkin vähentää projektiryhmän sisäistä kommunikaatiota ja heikentää epävirallista viestintää. 26 Se myös hidastaa palautteen antamista. Ketteriä menetelmiä joudutaan näiltä osin usein muokkaamaan GSD:hen sopiviksi. (El Bajta ja muut, 2018) Ebert ja muut (2016) kritisoivat GSD:n mukanaan tuomaa ”follow-the-sun” –periaatetta, jossa kaikki tiimit eivät työskentele samaan aikaan, mutta joku tiimi on mahdollisesti koko ajan työssä. Tällainen työskentelymalli saattaa tehdä projektinhallinnasta vaikeam- paa ja monimutkaisempaa. Ongelmia voi seurata myös esimerkiksi työvälineiden ylläpi- dossa ja varmuuskopioiden ottamisessa, jos niihin liittyvien huoltotöiden tekemistä var- ten ei jää tarpeellisia huoltoikkunoita. Menestyäkseen kansainvälisessä ohjelmistokehityksessä yrityksen tulee hallita yllä mai- nittuja GSD-projekteihin liittyviä riskejä. Parhaimmillaan globaalisti toteutettu projekti yhdistelee ja sekoittaa erilaisia tapoja sekä ideoita ja luo näin tehokkaasti uusia innovaa- tioita (Ebert & De Neve, 2001). Saleem ja muut (2019) mukaan GSD:ssä kohdataan kui- tenkin usein hankaluuksia. GSD:n vaikeudet liittyvät suurelta osin kehitysprojektin sidos- ryhmien sisäiseen viestintään ja yhteistyöhön. 3.1.1 Projektiryhmän jäsenet Ebert ja De Neve (2001) ovat todenneet tekemässään tapaustutkimuksessa, että samaan maantieteelliseen paikkaan keskitetyt projektitiimit saavuttivat yli 50 prosenttia suurem- man tehokkuuden ohjelmiston suunnittelussa ja toteutuksessa sekä tehtyjen virheiden havaitsemisessa, kun niitä verrattiin hajautettuihin tiimeihin. Työskentelyn tehokkuutta heikensivät myös osa-aikainen työskentely ja työn kierto. Projektityöskentelyn tehokkuu- den optimoimiseksi projektin jäsenet tulisi sijoittaa työskentelemään lähelle toisiaan, mielellään samaan tilaan. Heidän työaikansa tulisi allokoida projektille täysipäiväisesti. Näillä toimenpiteillä voidaan heidän mukaansa päästä merkittävään työskentelyn tehok- kuuden lisäykseen. Hajautetussa projektissa tällaiset työjärjestelyt eivät yleensä ole kui- tenkaan mahdollisia. 27 Tutkimuksensa pohjalta Ebert ja De Neve (2001) ehdottavat projektin henkilöiden allo- kaatioon seuraavia parannuksia: • Kokopäiväinen allokaatio. Sijoitetaan mahdollisimman suuri osa projektin työhön osallistuvista henkilöistä kokopäiväisiksi tai melkein kokopäiväisiksi projektin työntekijöiksi. • Luotettava allokaatio. Varmistetaan, että projektin käyttöön varatut henkilöt ovat varmasti käytettävissä. Tässä auttaa, jos henkilöiden käytettävyydestä sovitaan selkeillä alkamis- ja päättymispäivillä. • Paikallinen työskentely. Pyritään varmistamaan, että projektiryhmä mahdolli- suuksien mukaan toimii keskitetysti yhdessä paikassa. Hajautetusti työskentelevä tiimi työskentelee tehottomammin kuin keskitetysti samassa paikassa työskente- levä tiimi. • Kehityksen erottaminen ylläpidosta. Erotetaan uusien toiminnallisuuksien kehit- täminen ohjelmiston ylläpitotöistä ja virheiden korjauksesta. Kehitys ja ylläpito tulisi organisoida erikseen. Henkilöiden allokoiminen molempiin tehtäviin sotii kokopäiväistä allokaatiota vastaan, vaikka henkilö työskentelisikin saman ohjel- miston parissa täyspäiväisesti. Ebert ja De Neve (2001) esittävät lisäksi, että työtehtävien suunnittelussa pitäisi pyrkiä tiimin jäsenten asiantuntemuksen laajentamiseen. Liian kapea asiantuntemus tai osaa- misalue projektissa, saattaa heikentää tiimiläisen kykyä tai halua ottaa kokonaisvastuuta projektin tuloksista. Tiimiläisten asiantuntemuksien laajentaminen tuo tehokkuutta tii- min työskentelyyn sekä parantaa motivaatiota ja kokonaisnäkemystä projektista. Jos pro- jektin työskentelykulttuuri on aikaisemmin tukenut kapea-alaista asiantuntemusta, saat- taa muutos tuntua aluksi vaikealta, mutta se kannattaa. Ebertin ja De Neven (2001) mukaan henkilöstön vaihtuvuus ja sitoutuneisuus vaihtelee eri puolilla maailmaa. Euroopan ulkopuolella vaihtuvuus saattaa monesti olla selvästi suurempaa kuin Euroopassa. Yllätyksenä saattavat tulla lisäksi paikalliset työaikaan, or- ganisaatioihin tai ammattiliittoihin liittyvät säännöstöt. Lisäkustannuksina pitää varautua 28 mahdollisiin matkustamiseen, viestintään ja testaus- sekä työvälineisiin liittyviin kuluihin. Nämä kulut saattava syntyä hieman yllättäen vasta myöhäisemmässä projektin vaiheessa. Oman kokemukseni mukaan saattaa myös olla, ettei osaa työvälineistä tai ympäristöistä välttämättä saa käyttää joka maassa. Tällaisia saattavat olla esimerkiksi laitteet, joihin liittyy voimakasta salausteknologiaa. On lisäksi varauduttava siihen, että kulttuurierot ja erilaiset kielitaidot voivat vaikuttaa työskentelyilmapiiriin. 3.1.2 Projektirakenne Yksi globaalien projektien johtamiseen vaikuttavat tekijä on globaali projektirakenne. Binder (2007) esittelee kaksi projektirakenteen perustyyppiä: keskitetyn ja hajautetun. Projektin rakenteeseen vaikuttavat muun muassa projektin monimutkaisuus, projektia työstävien tahojen organisaatiorakenne sekä organisaation kokemus GSD-hankkeissa. Projektirakenteen kaksi päätyyppiä on esitetty kuvioissa 1 ja 2. Keskitetyssä rakenteessa kaikki projektiryhmän jäsenet tai suurin osa heistä, raportoi suoraan projektipäällikölle (Binder, 2007). Keskitetty rakenne sopii parhaiten projekteille, jotka eivät ole kooltaan kovin suuria tai rakenteeltaan liian monimutkaisia. Keskitettyä rakennetta puoltaa vielä se, jos projektin jäsenet ovat voimakkaasti hajautuneet keske- nään, he ovat tottuneet työskentelemään itsenäisesti ja heillä on riittävästi kokemusta hajautetusta työskentelystä. Keskitettyä rakennetta voidaan joutua käyttämään myös ti- lanteissa, joissa paikallinen koordinointi ei jostain syystä muuten ole mahdollista. Keski- tetty rakenne ei ole monestikaan paras vaihtoehto kansainvälisten projektien toteutuk- sessa. 29 Kuvio 1. Keskitetty projektirakenne (Binder, 2007). Hajautetussa rakenteessa projektiryhmän jäsen raportoi paikalliselle koordinaattorilleen, joka edustaa paikallisesti projektipäällikköä (Binder, 2007). Paikallinen koordinaattori ra- portoi projektipäällikölle ja saa häneltä ohjeistuksensa. Hän toimii tavallaan projektipääl- likkönä omalle aliprojektilleen. Hajautettu rakenne on suositeltavin vaihtoehto suurim- massa osassa kansainvälisiä projekteja. 30 Kuvio 2. Hajautettu projektirakenne (Binder, 2007). 3.2 GSD projektin hallinta Jain ja Suman (2018) ovat esittäneet viitekehyksen GSD-projektinhallinnalle. Viitekehyk- sen keskeiset osat on esitelty kuviossa 3. Viitekehys koostuu projektiin liittyvistä sidos- ryhmistä, työkaluista, tekniikoista sekä osaamisalueista (knowledge area). Viitekehyk- sessä mainitut osaamisalueet mukailevat PMI:n PMBOKissa kuvattuja osaamisalueita GSD:n kannalta keskeisin osin. Osa-alueet ovat GSD Integraation hallinta, toteutettavuu- den ja riskien hallinta, virtuaalitiimin hallinta, tietämyksen hallinta, laajuuden ja resurs- sien hallinta sekä suorituskyvyn hallinta. 31 Kuvio 3. GSD-projektinhallinnan viitekehys (Jain & Suman, 2018). Seuraavassa käydään tarkemmin läpi Jainin ja Sumanin (2018) esittämän projektinhallin- nan viitekehyksen osa-alueista integraation, tietämyksen, laajuuden ja resurssien hallin- taa sekä suorituskyvyn hallintaa. Riskienhallintaa ja virtuaalitiimejä käsitellään myöhem- min omina kohtinaan. 3.2.1 Integraation hallinta Jainin ja Sumanin (2018) mukaan GSD Integraation hallinnassa nimensä mukaisesti in- tegroidaan ja koordinoidaan muiden GSD-projektinhallinnan viitekehyksen osa-alueiden keskinäistä toimintaa. Siihen kuuluu muun muassa etätiimien hallinta, projektin suunnit- telu, projektin hallinnointi sekä tarvittaessa projektisuunnitelman päivittäminen. GSD 32 Integraation hallinnan kaksi keskeistä osa-aluetta ovat viestinnän sekä koordinaation hal- linta. Daim ja muut (2012) mukaan viestintä lisää luottamusta sekä parantaa ihmissuhteita. Viestintää tukevalla yrityskulttuurilla on tässä suuri merkitys. Viestintävälineiden käyttö parantaa viestintää hajautetussa tiimissä ja vähentää näin hajautuksesta aiheutuvia ne- gatiivisia vaikutuksia. Tämä vaatii kuitenkin Jainin ja Sumanin (2018) mukaan sitä, että viestintä suunnitellaan riittävän hyvin. Viestinnän eri osa-alueet, kuten viestintätavat, sii- hen käytetyt työvälineet ja se miten usein projektiryhmän jäsenet ovat yhteydessä toi- siinsa, on suunniteltava ja sovittuja käytäntöjä on valvottava työskentelyn aikana. Vies- tintä voi pahimmillaan jopa häiritä työntekoa, jos se on suunnittelematonta tai sitä on liikaa. Koordinaation hallinta on eri toimipisteiden välillä toteutettavien, toisistaan riippuvais- ten, toimintojen yhteensovittamista (Jain & Suman, 2018). Riittävä kommunikaatio on perusedellytys integraation onnistumiselle. GSD:ssä projektitiimin hajautuminen on myös otettava huomioon tehtävien jakamisessa, jotta toisistaan riippuvat tehtävät voi- daan hoitaa mahdollisimman tehokkaasti. Hajautettujen tiimien välistä koordinaatiota voidaan parantaa muun muassa tiimiläisten vierailujen, yhteisesti sovittujen prosessien, kokousten ja työvälineiden sekä riittävän kommunikaation ja tietämyksenhallinnan avulla. 3.2.2 Tietämyksen hallinta Jainin ja Sumanin (2018) esittämän määritelmän mukaan tietämyksen hallinta muodos- taa prosessin, jonka tehtävänä on hallita organisaation tietoa. Hallintaan kuuluu tiedon luominen, käyttäminen ja tiedon jakaminen. Tietämyksen hallinta on tärkeä ja keskeinen osa ohjelmistoprojekteja. Tiimin jäsenten kulttuurillisen, maantieteellisen ja ajallisen ha- jautumisen myötä tietämyksen hallinta korostuu vahvasti GSD-projekteissa. GSD on hyö- dyttänyt sovelluskehitystä monin tavoin, mutta samalla hajautetun tiimin jäsenten 33 välinen tiedon jakaminen on yksi sen keskeisiä huolenaiheita. GSD:n maantieteelliset ja ajalliset etäisyydet heikentävät tiedon jakamista. Lisäksi GSD:n sosiaalis-kulttuuriset ja organisatoriset etäisyydet saattavat aiheuttaa eroja siihen, miten tietoa ja tietämystä kä- sitellään sekä siihen, miten tietoa tulkitaan ja ymmärretään. (Razzak & Smite, 2015; Dingsøyr & Smite, 2014) Earl (2001) on ehdottanut 7-osaista viitekehystä tietämyksen hallinnan strategioille. Jai- nin ja Sumanin (2018) mukaan näistä seitsemästä osasta kuutta voidaan käyttää GSD:n tietämyksen hallinnassa. GSD:hen sopivat osat on esitetty kuviossa 4. Kuvio 4. GSD Tietämyksen hallinta (Jain & Suman, 2018). 34 GSD:n tietämyksen hallinnan osa-alueet ovat Jainin ja Sumanin (2018) mukaan seuraavat: • Järjestelmä-osiossa (System school) käytetään tietotekniikkaa työskentelyssä tar- vittavan tiedon tallentamiseen sekä jakamiseen hajautetun projektitiimin jäse- nille. Tähän osioon kuuluvat myös hajautetun tiimin työskentelyssä käytetyt etä- työvälineet. (Jain & Suman, 2018) • Kartografisessa osiossa (Cartographic school) kartoitetaan organisaation tietoja sekä huolehditaan niiden luotettavasta tallentamisesta (Earl, 2001). • Teknillisessä osiossa (Engineering school) käsitellään liiketoimintaprosessien suunnittelua ja niiden parantamista (Earl, 2001). Erilaiset käytännöt, kuten daily scrumit, viikkopalaverit ja koodikatselmoinnit kuuluvat myös tähän osioon. • Organisatorinen osio (Organizational school) käsittelee yhteistyöverkostojen muodostumista ja tiedon jakamista (Earl, 2001). • Tila-osiossa (Spatial school) pyritään työskentelytilan suunnittelulla parantamaan tiedon vaihtoa (Earl, 2001). GSD:n tapauksessa tilat voitaneen käsittää myös vir- tuaalisina. • Strateginen osio (Strategic school) korostaa organisaation strategioita, jotka voi- vat auttaa tietämyksen jakamisessa (Earl, 2001). Anwar ja muut (2019) suosittelevat tekemänsä kirjallisuuskatsauksen perusteella kan- sainvälistä ohjelmistokehitystä tekeville organisaatioille seuraavia toimenpiteitä tietä- myksen hallinnan parantamiseksi: • Tarvittaessa organisaation tulisi tarjota sovelluskehittäjille riittävästi tukea tietä- myksen jakamisen helpottamiseksi. • Organisaatiossa tulisi valita niin sanottuja ”kulttuurilähettiläitä”, jotka tuntevat hyvin organisaatiossa edustettuja kulttuureja. He voivat auttaa tulkitsemaan eri- laisista taustoista tulevien henkilöiden käytöstä ja kommunikaatiota. Heidän avullaan konfliktinhallinta saattaa myös ratkaisevasti tehostua. • Kielieroista johtuvien ongelmien minimoimiseksi, organisaatio voi hyödyntää niin sanottuja ”kulttuuritietoisuusohjelmia”. Tämä voidaan tehdä esimerkiksi niin, 35 että organisaatio nimeää paremmin kieltä ja kulttuuria tuntevia henkilöitä autta- maan viestinnän oikeassa tulkinnassa. • Organisaation tulisi mahdollisuuksien mukaan hyödyntää henkilöitä, jotka tunte- vat useampia kulttuureita. Heitä tulisi käyttää välittävissä rooleissa eri kulttuureja edustavien henkilöiden välillä. 3.2.3 Laajuuden ja resurssien hallinta Laajuuden ja resurssien hallintaan kuuluvat päätökset siitä, mitä tehtäviä sisällytetään projektiin, aikataulun ja kustannusten arviointi sekä niiden seuranta. Siihen kuuluvat osat ovat laajuuden, kustannusten ja aikataulun hallinta. (Jain & Suman, 2018) PMBOKin mukaan projektin laajuuden hallinta vastaa siitä, että projekti sisältää kaiken tarvittavan, jotta se voidaan suorittaa menestyksekkäästi. Toisaalta projektin laajuuden hallintaan kuuluu myös sen varmistaminen, ettei projektiin oteta sen toimittamisen kan- nalta ylimääräisiä tehtäviä (Project Management Institute, 2013, s. 105). GSD:ssä maan- tieteelliset, organisatoriset ja sosiokulttuurilliset etäisyydet hankaloittavat yhteisen käsi- tyksen syntymistä projektiryhmälle siitä, mitä kaikkea projektiin kuuluu (Jain & Suman, 2018). Tämän takia eri etätiimien osallistaminen mukaan projektin laajuuden määritte- lyyn on tärkeää. Kustannusten hallinta sisältää muun muassa projektin kustannusten arvioinnin, budje- toinnin ja toteuman valvonnan (Project Management Institute, 2013, s. 193). Paikallisesti toteutettuihin projekteihin verrattuna, GSD-projekteihin tulee mukaan hajautetusta työskentelystä syntyvät lisäkulut. Näitä ovat muun muassa infrastruktuurin huoltami- seen, matkoihin ja koulutukseen liittyvät kustannukset (Jain & Suman, 2018). Lisäksi kan- sainvälinen työskentely saattaa vaatia myös panostusta kielellisten tai kulttuurillisten erojen minimointiin. Kansainvälisyyden ja hajautuksen tuomien kustannusten hillitse- mistä helpottavat prosessien noudattaminen, tehokkaasti toimivat tiimit, asiakkaan osal- listaminen ja hyvä tietämyksen hallinta. 36 Aikataulun hallinnassa määritellään projektin tehtävät ja niiden kestot, suunnitellaan projektin aikataulu sekä valvotaan sen toteutumista. GSD:ssä hajautettu työskentely ai- heuttaa helposti aikatauluun ja koordinointiin liittyviä ongelmia, jotka heijastuvat pro- jektin suoritukseen (Jain & Suman, 2018). Herbsleb ja Moitra (2001) esittävät, että ha- jautettu työskentely pidentää työskentelyyn vaadittavaa aikaa verrattuna työhön, joka tehdään keskitetysti vain yhdessä paikassa. Syinä tarvittavan työajan pidentymiseen ovat esimerkiksi viiveet kommunikaatiossa eri toimipisteiden välillä, koordinaatiovaikeudet ja väärinkäsityksistä aiheutuva ylimääräinen työ. Hajautetun työskentelyn aikataululle ai- heuttamia paineita voidaan pienentää hyvällä johtamisella sekä kommunikaatioteknolo- gian käytöllä. Projektin laajuuteen vaikuttavat myös projektin aikana siihen tulevat muutospyynnöt. Ohjelmistokehitys on monimutkainen prosessi, jossa kaikkia tulevan järjestelmän vaati- muksia ei useinkaan pystytä määrittämään tarkasti työn alussa. Tämän takia vaatimukset monesti muuttuvat ja tarkentuvat kehitystyön edetessä ja muutokset ovatkin Anwer ja muut (2019) mukaan käytännössä väistämättömiä. Muutoksia hallinnoidaan muutosten- hallinnan prosesseilla. 3.2.4 Suorituksen johtaminen GSD:ssä suoritus ja siihen liittyvä laatu koostuvat Jainin ja Sumanin (2018) mukaan pro- sesseista ja tuotteen laadusta. Projektissa tulisi selkeästi määrittää kriteerit ja odotukset hyvälle suoritukselle. Hajautetun projektiryhmän jäsenen tulisi tietää varmasti, mitä hä- neltä odotetaan. Yleisesti projektin katsotaan suoriutuneen hyvin, jos se pystyy täyttä- mään sille asetetut tehtävät sovitussa laajuudessa budjetin ja aikataulun puitteissa. Li- säksi projektin työn laadun tulisi olla hyvää ja sen pitäisi täyttää asiakkaan vaatimukset. Sangwan ja muut (2006, s. 138–139) esittävät, että laadunvarmistus globaalissa konteks- tissa eroaa keskitetymmässä ympäristössä toteutetusta projektista. Hajautetussa työs- kentelyssä puuttuu epämuodollinen ja säännöllinen vuorovaikutus tiimin jäsenten väliltä. 37 Tämä vuorovaikutus tuo parhaassa tapauksessa laatuun liittyvät uhat näkyviin jo hyvin varhaisessa vaiheessa, ennen kuin ne ehtivät muodostua edes varsinaisiksi ongelmiksi. GSD-projekteissa laatuun liittyvät ongelmat huomataan monesti vasta myöhäisemmässä vaiheessa, jolloin niiden korjaaminen maksaa enemmän aikaa ja resursseja. Jain ja Suman (2018) laskevat ohjelmistokehityksen seurantaan ja arviointiin liittyvät teh- tävät prosessien johtamiseen kuuluviksi. Heidän mukaansa GSD-projekteissa korostuu erityisesti se, että projektipäällikön tulee selvästi määrittää hajautetulle tiimille vaadit- tavat välitavoitteet, määräajat ja toimitettavat lopputuotteet. Projektin tilanteen hah- mottamisessa ja työn ohjaamisessa apua tuovat projektinhallinnan työvälineet, eri tii- mien käytössä olevien työvälineiden integroiminen toisiinsa sekä kommunikaatioväli- neet. Monilla organisaatioilla on käytössä standardiprosessit sovelluskehitysprojekteja varten (Sangwan ja muut, 2006, s. 140). Projektit, ja varsinkin GSD-projektit, eroavat yleensä toisistaan niin paljon, että prosesseja joudutaan mukauttamaan kyseessä olevan projektin tarpeisiin. Sopivien prosessien valinnan lisäksi on valittava myös tapa, jolla niitä valvotaan ja seurataan. Valvonnassa keskeistä olisi kyetä seuraamaan projektin ajanta- saista edistymistä. GSD-projekteissa ongelmat näkyvät helposti vasta liian myöhäisessä vaiheessa. Sangwan ja muut (2006, s. 140–141) esittävät seuraavan heuristiikan, joka saattaa antaa vihjeen siitä, että GSD-projektissa on ongelmia. • Äkillisesti lisääntynyt kommunikaatio. Ongelmatilanteessa ihmiset etsivät ratkai- sua ongelmaansa. Hajautetussa työskentelyssä apua ja ratkaisuja joudutaan etsi- mään kommunikaatiovälineiden avulla. Kommunikaatiovälineiden käytöstä saat- taa olla saatavilla statistiikkaa. Kommunikaation lisääntymiseen voi olla muitakin syitä, mutta se saattaa olla yksi merkki ongelmista. • Kehityssprintissä toimitettavan osion laajuuden epätavallinen pienentäminen. Ketterässä kehityksessä on normaalia säätää sprintin laajuutta, mutta jos kokenut kehitystiimi saa aikaan odotettua selvästi pienemmän tuotoksen, kannattaa asian juurisyy selvittää. 38 • Kehittäjien moraali. Tiimiläiset, jotka päivittäin ovat tekemisissä kehitystyön kanssa, saattavat osata ennakoida tulevia ongelmia jo paljon ennen kuin niitä muilla mittareilla on mahdollista havaita. Heidän mielialojaan kannattaa kuun- nella tarkasti. • Toistuvat muutokset vaatimuksissa tai suunnittelussa. Projektin alun jälkeen, kun työskentelyn tahti on jo vakiintunut, kannattaa tarkkailla muutoksia ja selvittää niiden syyt. Sangwan ja muut (2006, s. 142–143) mukaan ohjelmistossa voi olla erilaisia virhetyyp- pejä. Niitä voivat olla esimerkiksi koodausvirheet, virheelliset ohjelmiston piirteet, puut- tuvat ohjelmiston piirteet, väärin ymmärretyt ohjelmiston piirteet ja yleisesti järjestel- män toimintaan liittyvät ongelmat, kuten huono suorituskyky. Ohjelmistokehityksen ha- jautuneisuus ei vaikuta yleensä koodausvirheiden esiintymiseen, mutta esimerkiksi vää- rinymmärrykset ohjelmiston toimintaan liittyen tai esimerkiksi erilaiset oletukset mit- tayksiköihin tai muihin paikallisesti vaihteleviin standardeihin saattavat lisääntyä ohjel- mistokehityksen hajautumisen myötä. GSD-projekteissa näihin ongelmiin voi pyrkiä vai- kuttamaan muun muassa noudattamalla sovittuja standardeja ja järjestämällä erilaisia katselmointeja jo ohjelmiston kehitysvaiheessa. On tärkeää varmistaa, että kaikilla ha- jautetun projektiryhmän jäsenillä on yhteinen näkemys työlle ja ohjelmistolle asetetuista vaatimuksista. Ohjelmistotuotteen laatua mitataan monesti siitä löytyneiden virheiden määrällä. Itse haluaisin sisällyttää laadun määritelmään lisäksi sen, miten laadukkaasti ja standardeja noudattaen ohjelmisto on koodattu. Pitkällä aikavälillä laadukkaasti tehdyn ohjelmisto- komponentin ylläpito on selvästä helpompaa ja uskoakseni myös halvempaa kuin huo- nosti tehdyn. 39 3.3 Riskienhallinta ja toteutettavuus Kirjallisuudessa riskille löytyy useita erilaisia määritelmiä. PMBOK:ssa riski määritellään epävarmana tapahtumana, jolla voi olla positiivinen tai negatiivinen vaikutus johonkin projektin osa-alueeseen, esimerkiksi laajuuteen, aikatauluun, kustannuksiin tai laatuun (Project Management Institute, 2013, s. 310). Tao (2008) puolestaan määrittelee riskin projektin epäonnistumiseen liittyvänä tekijänä. Riski kuvaa todennäköisyyttä, jolla projektille tapahtuu negatiivisia asioita. Nämä negatiiviset tapahtumat voivat liittyä muun muassa siihen, ettei projekti pysy aikataulussa, sen kustannukset kasvavat tai sen ei muuten ole mahdollista saavuttaa tavoitteitaan esimerkiksi laadun tai laajuuden osalta. Huomion arvoista tässä on, että PMBOKissa esitetyn määritelmän mukaan riskillä voi olla positiivinen tai negatiivinen vaikutus projektiin. Tässä keskitytään kuitenkin vain riskien negatiivisiin vaikutuksiin. Sangwan ja muut (2006, s. 68) painottavat, että riskissä on nimenomaan kyse tapahtumaan liittyvästä epävarmuudesta. Jos on esimerkiksi varmaa, että tapahtuma toteutuu, kyse ei ole enää riskistä, vaan silloin puhutaan jo ongelmasta. Ebert ja muut (2016) esittelevät riskienhallinnan osa-alueina riskien tunnistamisen, ana- lysoinnin, arvioinnin, käsittelemisen ja seurannan. Riskienhallinta on hyvin tärkeää pro- jektin menestykselle. Jos projektin riskit tunnistetaan riittävän aikaisin ja niihin reagoi- daan suunnitellusti, projektin onnistumisen mahdollisuudet kasvavat (Sangwan ja muut, 2006, s. 77). Siksi projektin riskienhallinnan pitäisikin alkaa jo riittävän varhaisessa vai- heessa projektia käynnistettäessä. Riskit ja niihin suunnitellut vastatoimet kirjataan pro- jektin riskienhallintasuunnitelmaan, jota tulee tarkastella säännöllisesti koko projektin ajan. Taon (2008) mukaan ohjelmistokehitysprojekteihin liittyvät riskit juontavat juurensa yleensä joko projektissa käyttöön otettuihin uusiin tekniikoihin tai teknologioihin, järjes- telmävaatimuksiin, järjestelmän arkkitehtuuriin, järjestelmän suorituskykyyn tai organi- satorisiin seikkoihin. 40 Erilaisia lähestymistapoja riskienhallintaan on kirjallisuudessa useita. Avdoshin ja Pesots- kaya (2011) esittävät, että riskienhallintaprosessiin kuuluu kiinteästi seuraavat viisi pe- rustehtävää. 1. Riskien tunnistamien. Kartoitetaan tyypilliset ja havaittavissa olevat riskit. 2. Riskien arviointi. Riskeille määritellään todennäköisyys ja arvioidaan vaikutukset riskin toteutumiselle. 3. Toimenpiteiden suunnittelu. Riskit analysoidaan ja niiden varalle kirjataan val- miiksi toimintasuunnitelma. 4. Riskien seuranta. Tunnistettujen riskien tilanne käydään säännöllisesti läpi koko projektin ajan. Samalla myös pyritään tunnistamaan mahdolliset uudet riskit. 5. Havaintojen dokumentointi ja toiminnan kehittäminen. Pyritään keräämään opit projektin riskienhallinnasta jatkoa ja tulevia projekteja varten. Kun potentiaaliset riskit on tunnistettu, ne tulee arvioida. Arvioinnissa riskille pyritään määrittelemään todennäköisyys ja arvioimaan sen vaikutus toteutuessaan. Sen jälkeen tulee suunnitella jokaista riskiä varten toimenpiteet. Toimenpiteet voivat vaihdella me- todologiasta riippuen, mutta neljä pääasiallista toimenpidettä Avdoshinin ja Pesotskayan (2011) mukaan ovat seuraavat: 1. Riskin pienentäminen. Tehdään suunnitelma riskin toteutumisen varalle ja sen todennäköisyyden pienentämiseksi. 2. Riskin välttäminen. Pyritään poistamaan riski esimerkiksi niin, että rajataan pro- jektia siten, ettei riski enää kuulu projektin laajuuteen. 3. Riskin jakaminen. Pyritään esimerkiksi siirtämään riski toisen osapuolen vastuulle. 4. Riskin hyväksyminen. Ei tehdä riskille toistaiseksi mitään. Hyväksytään riski ja sen mahdollinen toteutuminen. 41 3.3.1 Riskienhallinnan viitekehyksiä Esittelen seuraavassa lyhyesti kaksi tunnettua riskienhallinnan viitekehystä. Boehm (1989) on esittänyt yhden tunnetuimmista ja vanhimmista ohjelmistoriskejä ku- vaavista malleista. Malli on esitelty kuviossa 5. Tässä mallissa riskienhallinta käsittää kaksi pääprosessia. Ylätason prosessit ovat riskien arviointi sekä riskien hallinta. Näillä kum- mallakin pääprosessilla on vielä kolme alaprosessia, jotka edelleen jakautuvat osapro- sesseiksi. Riskien arvioinnissa pyritään tunnistamaan potentiaaliset riskit. Sen jälkeen riskit analy- soidaan, jolloin niiden vaikutukset ja todennäköisyys niiden realisoitumiselle pyritään määrittämään. Sen lisäksi riskien arvioinnissa riskeille määritellään prioriteetti. Riskin prioriteetti lasketaan yleensä kertomalla sen todennäköisyys mahdollisella vaikutuksella. (Chadli ja muut, 2015) Toinen Boehmin (1989) riskienhallinnan pääprosesseista koostuu riskien hallinnan suun- nittelusta, ratkaisusta ja seurannasta. Hallinnan suunnittelussa päätetään, mitä riskille tehdään. Vaihtoehdot ovat riskin jakaminen, välttäminen, pienentäminen tai hyväksymi- nen. Ratkaisuvaiheessa suunnitellut toimenpiteet toteutetaan. Viimeisenä aliprosessina on riskien seuranta. Siinä riskejä seurataan ja toteutetaan tarvittaessa korjaavia toimen- piteitä. 42 Kuvio 5. Riskienhallinnan pääprosessit (Boehm, 1989). PMI:n PMBOK nimeää riskienhallinnan yhdeksi projektinhallinnan osaamisalueeksi (Pro- ject Management Institute, 2013, s. 61). PMI:n malli on esitetty kuviossa 6. Siihen kuu- luvat prosessit ovat riskien hallinnan suunnittelu, riskien tunnistaminen, kvalitatiivinen ja kvantitatiivinen riskianalyysi, vastatoimien suunnittelu sekä riskien valvonta ja seu- ranta. PMI:n mallissa riskien lopputulos voi olla myös positiivinen, joten negatiivisten vaikutusten ehkäisemisen lisäksi tavoitteena on lisätä riskien positiivisia vaikutuksia pro- jektille. 43 Kuvio 6. Riskienhallinta projektinhallinnassa (Project Management Institute, 2013, s. 312). Chadli ja muut (2015) mukaan yleinen tapa riskienhallinnassa, viitekehysten lisäksi, ovat erilaiset heuristiikat ja tarkistuslistat. Ne on monesti laadittu eri sidosryhmien kokemus- ten perusteella. Erilaiset viitekehykset, tarkistuslistat ynnä muut sellaiset muistuttavat siitä, mitä asioita riskienhallinnassa tulee ottaa huomioon. Ne ovat kuitenkin vain ohjeita, joita on muokattava kulloisiinkin tarpeisiin. 3.3.2 Riskienhallinta ja GSD GSD-projekteihin liittyvät etäisyydet tuovat kansainvälisten projektien riskeihin omat li- sänsä verrattuna pakallisesti toteutettuihin projekteihin (Jain & Suman, 2018). GSD-pro- jektit ovat usein melko laajoja kokonaisuuksia, joiden monimutkaisuutta kansainvälisyys lisää. Ei-kansainvälisiin projekteihin verrattuna GSD-projekteissa joudutaan työskentele- mään maantieteellisten etäisyyksien, kulttuurillisten ja organisatoristen erojen sekä eri aikavyöhykkeiden paineessa. GSD:ssä esimerkiksi viestintä, koordinointi ja yhteistyö ovat alttiimpia ongelmille. Kaikki tämä lisääntynyt monimutkaisuus näkyy myös GSD-projek- tien kasvaneina riskeinä. Sangwan ja muut (2006, s. 68) mukaan GSD:n riskit liittyvät eri- tyisesti projektin koordinointiin, kommunikointiin, tietämyksen jakamiseen ja riskien 44 tunnistamiseen sekä ongelmanratkaisuun. Riskinhallintaa on näiden asioiden osalta eri- tyisesti tehostettava GSD-projekteissa. 3.4 Kulttuurilliset seikat GSD-projekteissa tiimin jäsenet työskentelevät hajautettuna laajalle maantieteelliselle alueelle. Tämä tuo usein mukanaan työskentelyn eri kulttuureihin kuuluvien ihmisten kanssa. Tiimiläisten erilaiset taustat ja lähtökohdat voivat monessa tilanteessa olla voi- mavara, mutta erilaisia kulttuureita edustavien henkilöiden välisessä työskentelyssä saattaa myös syntyä hankausta, jolloin työn tekeminen vaikeutuu. 3.4.1 Kulttuurien väliset erot Ebertin ja De Neven (2001) mukaan kulttuurierot ovat yksi keskeinen GSD:n ongelma- kohta. Erilaiset yrityskulttuurit voivat johtaa muun muassa erilaisiin työtapoihin, normei- hin, arvoihin ja viestintään. Kulttuurieroja syntyy erilaisten valtioiden ja kansallisuuksien välille. Usein ei kuitenkaan tiedosteta, että myös kansallisten organisaatioiden tai erilais- ten ammattikuntien välille voi helposti syntyä kulttuurieroja (Smith, 2001). Esimerkiksi insinöörit ja juristit saattavat painottaa argumentoinnissaan erilaisia asioita ja arvottaa asioita eri tavoilla. Erilaiset kansalliset- ja yrityskulttuurit johtavat siihen, että myös pro- jektinhallinnassa pitää ottaa huomioon kulttuurierot eri maiden ja organisaatioiden vä- lillä (Niazi ja muut, 2016a). Niazi ja muut (2016b) tulivat tutkimuksessaan siihen tulokseen, että GSD:n yleisin pro- jektin johtamiseen liittyvä heikkous oli tiimien huono tietämys muiden tiimiläisten kult- tuureista. Tiimiläisten hajautuminen eri maihin ja eri kulttuureihin vaikeuttaa GSD-pro- jektin johtamista. Ilman riittävää ymmärrystä eri kulttuureista saattaa syntyä paljon vää- rinkäsityksiä. Huono vieraiden kulttuurien ymmärtäminen vaikeuttaa projektin työsken- telyä muun muassa heikentämällä kommunikaatiota ja vähentämällä luottamusta. 45 3.4.2 Kommunikaatio Ohjelmistokehityksessä projektitiimin ja muiden sidosryhmien välisellä yhteistyöllä ja kommunikaatiolla on suuri merkitys. Ohjelmistokehitys ei ole yleensä mahdollista ilman laajan joukon tietoja ja asiantuntemusta. Layzell ja muut (2000) mukaan kommunikaa- tion onnistuminen vaikuttaa suoraan hajautetusti toteutetun projektin lopputuloksen laatuun. Hajautetussa projektissa jatkuva viestintä on välttämätöntä. Liian vähäinen vies- tintä vaikeuttaa projektin johtamista. Monien ohjelmiston suunnittelussa tai toteutuk- sessa tehtyjen huonojen ratkaisujen tai jopa suoranaisten virheiden taustalta löytyy kommunikaation epäonnistumisesta aiheutunut väärinkäsitys. Hajautettua sovelluskehitystä tehtäessä on pakko käyttää kommunikaatiovälineitä, koska henkilökohtaiset tapaamiset eivät usein ole mahdollisia tai ne ovat säännöllisesti toteu- tettuina liian kalliita. Kommunikaatiovälineiden käyttäminen suodattaa osan viestinnän tasoista ja vähentää viestinnän määrää. Tämän takia Farias ja muut (2012) kehottavat edistämään ja lisäämään viestintää ottamalla käyttöön mahdollisimman hyviä viestintä- työkaluja. Tiimiläisiä tulisi kannustaa keskenään sekä muodolliseen että epämuodolli- seen kommunikaatioon. Lisäksi jos hajautetussa tiimissä on mukanaan eri äidinkieliä pu- huvia jäseniä, he kehottavat myös, väärinkäsitysten minimoimiseksi, käyttämään viestin- nässä selkeää yleiskieltä. Bano ja muut (2016) mukaan keskeiset hankaluudet maantieteellisesti hajautetun tiimin työskentelyssä liittyvät työskentelyyn eri aikavyöhykkeillä sekä henkilökohtaisen, kasvok- kain tapahtuvan, kommunikaation vähäisyyteen. Nämä seikat vaikeuttavat reaaliaikaista viestintää ja siten vaikeuttavat sekä hidastavat tiedon siirtoa. He kartoittivat tutkimuk- sessaan, mitä keinoja on käytetty maantieteellisestä hajautuksesta aiheutuneiden ongel- mien kiertämiseen. Käytettyjä keinoja olivat muun muassa määrällisesti riittävä viestintä sopivia viestintävälineitä, etenkin neuvottelupuheluita, käyttäen ja kokousten laadukas valmistelu. Myös joustavaa työaikaa käytettiin, jotta eri aikavyöhykkeillä työskentelevien 46 henkilöiden olisi mahdollista osallistua yhteisiin kokouksiin ja viestiä keskenään reaaliai- kaisesti. Hajautetusti työskentelevän tiimin kesken on Bano ja muut (2016) mukaan vähemmän epävirallista kommunikaatiota kuin keskitetysti työskentelevällä tiimillä. Kommunikaati- oon vaikuttavat eri toimipisteiden välinen fyysinen etäisyys, aikaerot sekä se, ettei toisen toimipisteen työntekijöihin välttämättä ole vähäisemmän kanssakäymisen johdosta muodostunut henkilökohtaista sidettä. Tällöin on vaarana, että tiimiläiset jakautuvat eri leireihin ja kommunikaatio sekä tiedon jakaminen eri ryhmien välillä heikentyy entises- tään. Tämän takia organisaation henkeä tulisi nostaa. Olisi tärkeää luoda tunne ja tietoi- suus yhteisistä tavoitteista. Tässä auttavat liiketoimintaprosessien yhtenäistäminen sekä selkeästi määritellyt roolit ja vastuut. Teknisistä apuvälineistä voi myös tässä yhteydessä olla hyötyä. Esimerkiksi työvälineiden integraatiolla on Bano ja muut (2016) tekemän tut- kimuksen mukaan saavutettu hyviä tuloksia viestinnässä koettujen ongelmien vähentä- misessä. Kommunikaatiosuunnitelman tekeminen on tärkeää, jotta kyetään varmistamaan teho- kas viestintä hajautetussa tiimissä (Denhere ja muut, 2015). Viestintäsuunnitelmalla var- mistetaan, että riittävä informaatio toimitetaan oikeassa muodossa, oikeaan aikaan, oi- keille henkilöille. Asioita, joita viestintäsuunnitelmassa tulisi ottaa huomioon ovat aina- kin seuraavat: • Käytettävä kieli • Kuinka tiimiä tiedotetaan edistymisestä • Milloin voidaan järjestää henkilökohtaisia tapaamisia • Viestintäteknologian käyttöä varten tarvittava koulutus • Mitä viestintävälineitä käytetään • Milloin käytetään synkronista ja milloin asynkronista kommunikaatiota 47 4 Virtuaalitiimit Nykyinen kommunikaatioteknologia on mahdollistanut tiimien toimimisen huomatta- vasti laajemmalla keinovalikoimalla kuin aikaisemmin. Kommunikaatioteknologia mah- dollistaa tiimien toimimisen hajautetusti, ilman fyysistä vuorovaikutusta tiimiläisten kes- ken. Projektien ja tiimien hajauttaminen aiheuttaa kuitenkin vaikeuksia niiden johtami- seen. Sen takia monet organisaatiot ovat Caseyn ja Richardsonin (2006) mukaan muo- dostaneet strategian virtuaalitiimeistä. Virtuaalitiimin jäsenet ovat jakautuneet maantie- teellisesti, organisatorisesti tai ajallisesti. He työskentelevät projektissa koordinoiden toi- mintaansa tietoliikennetekniikkaa käyttäen. Virtuaalitiimin jäsenillä saattaa olla eri äidin- kielet, he voivat olla eri maiden kansalaisia ja kuulua eri organisaatioihin. Virtuaalitiimit ovat nykyään yleinen ja dynaaminen tapa tehdä tiimityötä ohjelmistokehityksessä. Vir- tuaalitiimit tarjoavat tiimille tietyissä tilanteissa mahdollisuuden työskennellä jousta- vammin ja taloudellisesti kannattavammin kuin perinteiset tiimit. Virtuaalitiimit eivät ole sidottuja tiettyyn maantieteelliseen alueeseen, ja niihin on usein mahdollista hankkia kattavampaa ja monipuolisempaa osaamista kuin perinteiseen tiimiin. Tiimi voi myös toi- mia virtuaalisesti, vaikka sen jäsenet työskentelisivätkin esimerkiksi samassa maassa ja samalla paikkakunnalla. (Casey & Richardson, 2006; Jawadi & Boukef-Charki, 2009; Jain & Suman, 2018) Vaikka monissa lähteissä suositellaan virtuaalitiimien käyttöä, Ebert ja De Neve (2001) esittävät tekemänsä tapaustutkimuksen perusteella eriävän näkemyksen ja suosittelevat keskitettyjen tiimien käyttöä. He suosittelevat lisäksi tiimin jäsenille täyttä allokaatiota, jolloin he työskentelevät vain yhdessä projektissa, eivätkä muut tehtävät häiritse heidän työtään. Näin saadaan tiimin resurssit paremmin käyttöön ja tiimin jäsenet tehokkaam- min kommunikoimaan keskenään. 48 4.1 Kommunikaatio Yksi suurimmista vaikeuksista virtuaalitiimien toiminnassa on kommunikaation toimi- vuus. Kommunikaatio voidaan jakaa synkroniseen ja asynkroniseen kommunikaatioon. Synkronisessa kommunikaatiossa sanomien välittäminen tapahtuu reaaliajassa. Asynk- roninen viestintä ei ole reaaliaikaista, eivätkä viestin lähettäjä tai vastaanottaja ole ajal- lisesti sidottuja toisiinsa. Niazi ja muut (2016a) tarkoittavat synkronisella kommunikaa- tiolla pääasiassa henkilökohtaista keskustelua. Sen määrä hajautetussa tiimissä voi olla hyvin vähäistä, elleivät jäsenet matkusta toistensa luokse. Synkronisena kommunikaa- tiona voi pitää myös televiestintäsovelluksien tai puhelimen avulla tapahtuvaa viestintää. Dubé ja Robey (2008) ehdottavat yhtenä ratkaisuna kommunikaation parantamiseen sitä, että virtuaalitiimit mahdollistaisivat jäsentensä fyysisen tapaamisen. Tämä voisi tapah- tua esimerkiksi projektin aloituskokouksessa. 4.2 Hajautetun tiimin rakenne GSD mahdollistaa työn jakamisen itsenäisesti toteutettaviin osiin, joita voidaan toteuttaa rinnakkain useammassa eri paikassa. Tätä varten Conchúir ja muut (2009b) esittävät kaksi pääasiallista tapaa hajauttaa tiimit työskentelemään eri toimipisteissä. Tavat ovat virtuaalitiimi ja löyhästi kytketyt tiimit. Eri tavat organisoida tiimityö on esitetty kuvioissa 7 ja 8. Kuvion 7 kaltaisesti organisoidussa virtuaalitiimissä työtehtävät jaetaan lähes ku- ten paikallisesti toimivassa tiimissä. Eri toimipisteessä työskentelevät henkilöt muodos- tavat kuitenkin omat alitiiminsä. Kuviossa 8 esitetyssä löyhästi kytketyssä tiimissä työt jaetaan selvästi rajatumpiin kokonaisuuksiin ja jokainen toimipiste muodostaa oman eril- lisen tiiminsä. 49 Kuvio 7. Virtuaalitiimi (Conchúir ja muut, 2009b). Kuvio 8. Löyhästi kytketty tiimi (Conchúir ja muut, 2009b). 50 4.3 Virtuaalitiimin johtaminen Virtuaalitiimin jäsenet tulevat erilaisista taustoista. Erilaiset taustat saattava aiheuttaa yhteentörmäyksiä tiimin sisällä. Jain ja Suman (2018) nimeävät ongelmia lisäävinä teki- jöinä muun muassa riittämättömän viestinnän, huonon motivaation, tietämättömyyden erilaisten kulttuurien eroista sekä yleisesti huonon johtamisen ja erityisesti huonon kon- fliktien hallinnan. Virtuaalitiimin johtamisen tärkeimmät osatekijät Jainin ja Sumanin (2018) mukaan on esitetty kuviossa 9. Kuvio 9. Virtuaalitiimin johtamisen tärkeimmät osatekijät (Jain & Suman, 2018). Projektitiimin hajauttaminen saattaa heikentää ryhmän yhteenkuuluvuuden tunnetta. Fyysisillä tapaamisilla on suuri merkitys tiimin yhteenkuuluvuudentunteen muodostumi- sessa sekä keskinäisen luottamuksen kasvussa. Hajautetuissa tiimeissä tilannetta voi pa- rantaa kierrättämällä projektin henkilöitä eri toimipisteiden välillä ja järjestämällä 51 mahdollisuuksien mukaan fyysisiä tapaamisia tiimin jäsenten välille. (Dubé & Robey, 2008; Niazi ja muut, 2016a) Tiimin kokoonpanoon vaikuttaviin tekijöihin on GSD-projekteissa kiinnitettävä eritystä huomiota. Tiimin jäsenten tulee olla niin teknisiltä kuin kielitaidoltaankin riittävällä ta- solla ja heidän roolinsa sekä vastuunsa projektissa tulee olla selkeästi määritelty. Myös ihmissuhde- ja vuorovaikutustaidot ovat tärkeitä tiimin jäsenille. Tiimin työskentelylle on eduksi, mitä useammalla jäsenellä on kokemusta kyseisestä asiakasyhteistyöstä. Koke- mus parantaa tuottavuutta, vähentämällä väärinkäsityksiä ja parantamalla luottamusta. Toimivassa ryhmässä myös jäsenten vaihtuvuuden pitää pysyä kohtuullisella tasolla. Suuri vaihtuvuus heikentää ryhmän toimintaa muun muassa sen takia, että poistuvat ryhmän jäsenet vievät väistämättä mukanaan työskentelyssä tarvittavaa hiljaista tietoa. (Jain & Suman, 2018) Tiimin jäsenten motivaatiolla on suuri merkitys tiimin työn laatuun. Beecham ja muut (2007) mukaan huono motivaatio saattaa näkyä tiimin jäsenillä muun muassa korkeam- pana vaihtuvuutena ja suurempana poissaolojen määränä. Korkea motivaatio näkyy mal- tillisempana vaihtuvuutena ja suurempana tuottavuutena. Jain ja Suman (2018) luette- levat motivaatiota kasvattavina tekijöinä esimerkiksi palkkiot, onnistuneet suoritukset, vapauden ilmaista mielipiteitään, oikeudenmukaisen johtamisen sekä säännöllisen ra- kentavan palautteen ja kunnioituksen. Tehtävien jakaminen tiimin jäsenille on yksi keskeinen asia projektin johtamisessa. Kun projektiryhmä työskentelee hajautetusti, tehtävien jakamiseen liittyy erityisiä vaatimuk- sia. Tehtäviä jaettaessa tulee ottaa huomioon useita seikkoja, kuten esimerkiksi eri toi- mipaikoissa tehdyn työn kustannusvaikutus, tehtävien väliset riippuvuussuhteet ja tuot- teen arkkitehtuuri, aikavyöhykkeiden vaikutus työn organisointiin ja kulttuuriin liittyvät erot. Huomioivia seikkoja ovat vielä muun muassa saatavilla oleva tieto-taito, asiantun- tijoiden kielitaito ja haluttujen asiantuntijoiden käytettävyys, etäisyys asiakkaaseen ja 52 markkinoihin, poliittiset tekijät, kuten esimerkiksi paikalliset lait ja säädökset sekä hen- kilökohtaiset kontaktit. (Lamersdorf ja muut, 2009) Yhtenä ratkaisevan tärkeänä osana virtuaalitiimin johtamisessa Jain ja Suman (2018) nä- kevät konfliktien hallinnan. Projektityöskentelyssä ja varsinkin virtuaalitiimin työssä, tör- mätään melkein väistämättä jonkinlaisiin konflikteihin. Konflikteja saattaa syntyä niin ha- jautetun tiimin sisällä kuin hajautetun tiimin ja jonkin sidosryhmän, esimerkiksi asiak- kaan välillä. Nämä konfliktitilanteet on syytä saada käsiteltyä nopeasti ja niin, etteivät ne jää enää rasittamaan tiimin tulevaa toimintaa. Konfliktien hallinnassa projektipäälliköllä tai virtuaalitiimin vetäjällä on ratkaiseva rooli. 4.4 Virtuaalisuuden aste ja etäisyys Virtuaalitiimejä on hyvin erilaisia. Ne voivat erota toisistaan esimerkiksi jäsenyyskritee- rien, tavoitteiden tai kulttuurillisten ominaispiirteiden osalta. Myös tiimin virtuaalisuu- della voi olla eri asteita. Zigurs (2003) esittää, että tiimi voi olla hajautettu monella eri tavalla. Yleisimmät virtuaalisuuden asteeseen vaikuttavat ulottuvuudet on esitetty kuvi- ossa 10. Ne ovat: • Maantieteellinen etäisyys • Ajallinen etäisyys • Kulttuurillinen etäisyys • Organisatorinen etäisyys 53 Kuvio 10. Virtuaalitiimin yleisimmät ulottuvuudet (Zigurs, 2003). Tiimin virtuaalisuuden aste on eri virtuaalisuuden ulottuvuuksien kokonaismäärä. Jokai- sen ulottuvuuden kasvu lisää tiimin virtuaalisuuden kokonaismäärää. Mitä enemmän tii- min virtuaalisuus kasvaa, sitä monimutkaisemmiksi muodostuvat myös tarpeet, joita tiimi tulee työskennellessään kohtaamaan (Zigurs, 2003). Tiivistäen voisi todeta, että ma- talamman virtuaalisuuden asteen tiimin jäsenten on helpompi tavata toisensa henkilö- kohtaisesti, työskennellä samaan aikaan ja ymmärtää toistensa kulttuuria. Maantieteellinen etäisyys tarkoittaa käytännössä tiimiläisten fyysistä etäisyyttä toisis- taan. Tässä etäisyydellä tarkoitetaan kuitenkin sitä, miten helppoa jäsenten on fyysisesti tavata toisiaan (Holmström ja muut, 2006). Lyhytkin fyysinen etäisyys voi tässä tarkoittaa suurta etäisyyttä, jos välissä on este, jota ei voida ylittää. Esimerkiksi toimipisteiden vä- lillä ei ole sopivia kulkuyhteyksiä tai esimerkiksi valtakunnan raja on suljettu. Toisaalta 54 myös pitkä matka voidaan katsoa lyhyeksi etäisyydeksi, jos se on vaivaton kulkea esimer- kiksi hyvien juna- tai lentoyhteyksien ansiosta. Maantieteellinen etäisyys johtaa siihen, että henkilökohtaiset tapaamiset vähenevät, joka puolestaan johtaa vähäisempään luon- nolliseen ja epäviralliseen kommunikaatioon (Bano ja muut, 2016). Kommunikaation vä- hentymiseen liittyvänä vaarana on, että se saattaa heikentää luottamusta ja yhteenkuu- luvuuden tunnetta (Daim ja muut, 2012). Maantieteellisestä etäisyydestä aiheutuneita ongelmia voi pyrkiä vähentämään lisäämällä viestintää erilaisten kommunikaatiovälinei- den avulla sekä järjestämällä tiimin jäsenille fyysisiä tapaamisia. Khan ja muut (2014) mukaan kulttuurinen etäisyys kuvaa sitä, miten paljon henkilöt eroavat toisistaan kielen, uskonnon, sosiaalisen tai taloudellisen aseman, poliittisten nä- kemysten tai muiden vastaavien tekijöiden perusteella. Kaikki edellä mainitut asiat vai- kuttavat tiimin jäsenten käytökseen ja asenteisiin sekä voivat hankaloittaa heidän keski- näistä yhteisymmärrystään ja heikentää luottamusta. Yhdeksi tiimiläisten aivan kes- keiseksi eroksi voi luonnollisesti muodostua kielitaito (Jain & Suman, 2018). Kulttuurilli- sen etäisyyden tuomia vaikeuksia voi lievittää esimerkiksi kielitaitoon ja erilaisiin kulttuu- reihin liittyvillä koulutuksilla. Ajallinen etäisyys tarkoittaa sitä yhteistä työaikaa, joka tiimiläisillä on käytössään, jos he työskentelevät eri aikavyöhykkeillä (Ågerfalk ja muut, 2008). Ajallinen etäisyys on osittain seurausta maantieteellisestä etäisyydestä ja työskentelystä eri aikavyöhykkeillä. Ajalli- nen etäisyys voi olla hajautetussa työskentelyssä myös positiivinen asia, sillä se mahdol- listaa ympärivuorokautisen työskentelyn ”follow-the-sun”–periaatteen mukaisesti. Ajal- lisesta etäisyydestä aiheutuu esimerkiksi viivettä kommunikaatioon. Ajallisen etäisyyden haitallisia vaikutuksia voi lievittää muun muassa käyttämällä asynkronista kommunikaa- tiota, säätämällä työaikoja ja järjestelmällä yhteiset palaverit niinä aikoina, jolloin kaikki voivat olla töissä yhtä aikaa. 55 Organisatorisella etäisyydellä tarkoitetaan tilannetta, jossa yhteistyötä tekevät henkilöt kuuluvat eri organisaatioihin. Tällöin heillä saattaa olla käytössä erilaisia menetelmiä sekä työtapoja ja he ovat mahdollisesti omaksuneet erilaiset organisaatiokulttuurit. Tämä voi tehdä organisaatioiden välisistä rajoista hankalia ylittää, jolloin esimerkiksi tii- mien muodostaminen eri organisaatioiden välille hankaloituu ja tiedon siirto organisaa- tioiden välillä heikkenee. Suuri organisatorinen etäisyys voi olla tietyissä tilanteissa tar- koituksellinenkin asia. Voidaan esimerkiksi haluta, ettei tietoa vapaasti välitetä oman or- ganisaation ulkopuolelle. Organisatorisen etäisyyden aiheuttamia negatiivisia vaikutuk- sia voidaan vaimentaa luomalla luottamusta eri osapuolten välille ja lisäämällä avoi- muutta. Kun eri osapuolilla on riittävän hyvä käsitys toisten organisaatioiden rakenteesta, saavutetaan selkeä kuva siitä, kehen voi toisessa organisaatiossa voi olla yhteydessä mi- hinkin asiaan liittyen. (Jaanu ja muut, 2012). 56 5 Johtopäätökset Tietotekniikan kehitys ja halpeneminen sekä tietoliikenneyhteyksien nopeutuminen ja luotettavuuden parantuminen ovat mahdollistaneet ohjelmistokehityksen hajautumisen ja samalla kansainvälistymisen. Tässä ohjelmistokehitys on seurannut yleisesti vallalla ol- lutta globalisaation trendiä. GSD on kasvanut ohjelmistoalan merkittäväksi suun- taukseksi kaikkialla maailmassa. Ohjelmistokehityksen kansainvälistymisellä on saavu- tettu merkittäviä hyötyjä. Havaittavissa on kuitenkin selvästi se, että liian monet kansain- välisesti toteutetut ohjelmistoprojektit jäävät tavoitteistaan. Tämä kertoo vahvasti siitä, ettei kaikkia kansainvälisen ohjelmistokehityksen vaateita osata ennakoida. Tässä työssä kävin läpi kansainvälistä sovelluskehitystä projektinhallinnan ja hajautettujen tiimien nä- kökulmasta sekä niihin liittyviä ongelmia ja myös ongelmiin varautumista. Työssä tunnis- tetut vaikeudet myötäilevät hyvin keskeisiä projektinhallinnan yleisiä osa-alueita. Kan- sainvälisyys ja muun muassa projektin osallistujien maantieteellinen, ajallinen, kulttuu- rillinen sekä organisatorinen etäisyys toisistaan tuovat vaikeuksiin vielä omat erityispiir- teensä sekä monimutkaistavat projektinhallintaa. Odotetusti hajautettujen tiimien kes- keiset hankaluudet liittyivät erilaisten kulttuurien kohtaamiseen, tiedonvälitykseen ja kommunikointiin. Tässä työssä esitettyjen uhkien tunnistaminen ja niihin vastaaminen on hyödyllistä ha- jautettujen projektien parissa työskenteleville. Ongelmatilanteisiin oikein varautumalla, saadaan projektien onnistumistodennäköisyyttä nostettua ja mahdollisia piilokustan- nuksia karsittua. Työssä nousi esiin kriittisiä tekijöitä projektin ja tiimin työskentelyn varmistamiseksi. Täl- laisia asioita ovat esimerkiksi huolenpito siitä, että koko projektiryhmä jakaa saman kä- sityksen siitä, mitä ollaan tekemässä. Myös roolituksen ja vastuunajon on oltava selkeitä. Projektiryhmän jäsenten välille on pyrittävä rakentamaan vahva luottamuksen side. Kan- sainvälinen konteksti tuo mukaan vielä erilaisiin kulttuureihin ja kommunikaatioon liitty- vät hankaluudet. Tiimin osalta on ensiarvoisen tärkeää varmistaa, että jäsenillä on yhtei- nen kieli ja että kaikki puhuvat sitä riittävän hyvin. Pelkkä kielen tekninen puhuminen ei 57 silti välttämättä riitä, vaan tiimin jäsenten välillä on oltava yhteinen käsitys kielen seman- tiikasta. Parhaan mahdollisen kommunikaation varmistamiseksi tulee kiinnittää huo- miota ryhmän käytössä olevien kommunikaatiotyökalujen ja –ohjelmistojen tarkoituk- senmukaisuuteen. Hajautetussa ohjelmistokehityksessä saavutettujen hyötyjen ja piilevien kustannusten vuoksi hajautetun ja keskitetyn työskentelyn kustannustehokkuuden vertailu on vaikeaa. On yksinkertaista verrata pelkästään hajauttamisella tai ulkoistamisella saatua halvem- paa työn tuntihintaa. On kuitenkin selviä viitteitä siitä, että hajauttaminen tuo mukanaan muun muassa tehottomuutta, kommunikaation heikentymistä sekä työn hidastumista. Tämä kaikki vaikeuttaa kokonaishyödyn laskemista ja saattaa jopa tehdä siitä mahdo- tonta. 5.1 Tutkimuksen luotettavuus Tutkimuksen luotettavuutta mietittäessä mieleen tulee ensimmäisenä se, miten toistet- tava se on. Eli millä todennäköisyydellä toinen henkilö päätyisi samalla metodilla, sa- masta aiheesta, vastaavaan lopputulemaan. Tämä työ on opinnäytetyö, joten se asettaa selvät rajat työhön käytetylle ajalle. Se asettaa myös jossain määrin rajat sille mihin ai- neistoihin on mahdollista päästä käsiksi. Aiheiston hakuun käytetyt hakuehdot ja käytössä olleet hakutietokannat saattavat tuoda vaihtelua hakuvaiheen tuloksena saatavaan aineistoon. Samasta aiheesta olisi saattanut hieman erilaisilla hakuehdoilla päätyä osittain erilaiseen aineistoon ja saada siten alku- vaiheessa käyttöönsä erilaisen lähdeaineiston. En kuitenkaan usko, että ero voisi olla merkittävä. 58 5.2 Jatkotutkimuksen aiheita Tässä työssä viitatuissa lähteissä on aihetta käsitelty yleisellä tasolla, ja niissä sivutut esi- merkit ovat pääsääntöisesti Euraasiasta ja Pohjois-Amerikasta. Mielestäni on kuitenkin viitteitä siitä, että hajautus ulottuu jatkossa myös yhä enemmän tämän alueen ulkopuo- lelle. Olisi kiinnostavaa tietää tuovatko esimerkiksi Afrikka tai Etelä-Amerikka jotain omia lisäpiirteitään projektityöskentelyyn tai hajautettujen tiimien toimintaan. Jainin ja Sumanin (2015) mukaan ohjelmiston toteutus ja testaus ovat helpoimpia ulkois- taa ja sen takia niitä hyödynnetään eniten GSD:ssä. Jatkotutkimuksen aiheena voisi olla myös se, miten muiden ohjelmistokehitysvaiheiden, kuten määrittelyn tai suunnittelun, osuutta GSD:ssä voisi lisätä. Monet organisaatiot osallistuvat globaaliin ohjelmistokehitykseen niin, ettei niillä ole etukäteen käsitystä oman projektijohtamisensa kyvystä selviytyä kansainvälisen toimin- nan vaatimuksista (Khan ja muut, 2011). Olisi hyödyllistä tietää, millä seikoilla voi varmis- taa, että organisaatio on valmis globaaliin ohjelmistokehitykseen. Voidaanko määritellä mittareita, joista asian näkisi objektiivisesti? 59 Lähteet Agile Alliance (2020). Agile 101. Noudettu 20.3.2020 osoitteesta https://www.agilealli- ance.org/agile101/ Alzoubi, Y.I., Gill, A. Q. & Al-Ani, A. (2016). Empirical studies of geographically distributed agile development communication challenges: A systematic review. Information & Management Volume 53, Issue 1, January 2016, Pages 22-37. https://doi.org/10.1016/j.im.2015.08.003 Anantatmula, V. & Thomas, M. (2010). Managing Global Projects: A Structured Approach for Better Performance. Project Management Journal. https://doi.org/10.1002/pmj.20168 Anwar, R., Rehman, M., Wang, K. S. & Hashmani, M. A. (2019). Systematic Literature Re- view of Knowledge Sharing Barriers and Facilitators in Global Software Develop- ment Organizations Using Concept Maps. Project Management Journal. https://doi.org/10.1109/ACCESS.2019.2895690 Anwer, S., Wen, L., Wang, Z. & Mahmood, S. (2019). Comparative Analysis of Require- ment Change Management Challenges Between in-House and Global Software Development: Findings of Literature and Industry Survey. IEEE Access, vol. 7, pp. 116585-116611. https://doi.org/10.1109/ACCESS.2019.2936664 Avdoshin, S. M. & Pesotskaya, E. Y. (2011). Software risk management. 2011 7th Central and Eastern European Software Engineering Conference (CEE-SECR), Moscow, 2011, pp. 1-6. https://doi.org/10.1109/CEE-SECR.2011.6188471 Bannerman, P. L., Hossain, E. & Jeffery, R. (2012). Scrum Practice Mitigation of Global Software Development Coordination Challenges: A Distinctive Advantage? 45th Hawaii International Conference on System Sciences, Maui, HI, 2012, pp. 5309- 5318. https://doi.org/10.1109/HICSS.2012.512 Bano, M., Zowghi, D. & Sarkissian, N. (2016). Empirical study of communication struc- tures and barriers in geographically distributed teams. IET Software, vol. 10, no. 5, pp. 147-153. https://doi.org/10.1049/iet-sen.2015.0112 https://www.agilealliance.org/agile101/ https://www.agilealliance.org/agile101/ https://doi.org/10.1016/j.im.2015.08.003 https://doi.org/10.1002/pmj.20168 https://doi.org/10.1109/ACCESS.2019.2895690 https://doi.org/10.1109/ACCESS.2019.2936664 https://doi.org/10.1109/CEE-SECR.2011.6188471 https://doi.org/10.1109/HICSS.2012.512 https://doi.org/10.1049/iet-sen.2015.0112 60 Beecham, S., Baddoo, N., Hall, T., Robinson H. & Sharp, H. (2007). Motivation in Software Engineering: A systematic literature review. Information and Software Technol- ogy 50(9–10), 860-878. https://doi.org/10.1016/j.infsof.2007.09.004 Binder, J. (2007). Global Project Management: Communication, Collaboration and Man- agement Across Borders. Gower Publishing Limited. ISBN: 9780566087066 Boehm, B. (1989). Software risk management. In: Ghezzi C., McDermid J.A. (eds) ESEC '89. ESEC 1989. Lecture Notes in Computer Science, vol 387. Springer, Berlin, Hei- delberg. https://doi.org/10.1007/3-540-51635-2_29 Casey, V. (2010). Virtual software team project management. J Braz Comput Soc 16, 83– 96. https://doi.org/10.1007/s13173-010-0013-3 Casey, V. & Richardson, I. (2006). Uncovering the reality within virtual software teams. GSD '06: Proceedings of the 2006 international workshop on Global software de- velopment for the practitioner. Pages 66–72. https://doi.org/10.1145/1138506.1138523 Chadli, S. Y., Idri, A., Fernández-Alemán, J. L. & Ros, J. N. (2015). Frameworks for risk management in GSD projects: A survey. 2015 10th International Conference on Intelligent Systems: Theories and Applications (SITA), Rabat, 2015, pp. 1-6. https://doi.org/10.1109/SITA.2015.7358381 Conchúir, E. Ó., Olsson, H. H., Ågerfalk, P. J. & Fitzgerald, B. (2009a). Benefits of Global Software Development: Exploring the Unexplored. Softw. Process Improve. Pract. 2009; 14: 201–212. https://doi.org/10.1002/spip.417 Conchúir, E. Ó., Ågerfalk, P. J., Olsson, H. H. & Fitzgerald, B. (2009b). Global software development: where are the benefits? Communications of the ACM. https://doi.org/10.1145/1536616.1536648 Cusumano, M. (2008). Managing software development in globally distributed teams. Communications of the ACM. https://doi.org/10.1145/1314215.1314218 Daim, T. U., Ha, A., Reutiman, S., Hughes, B., Pathak, U., Bynum, W. & Bhatla, A. (2012). Exploring the communication breakdown in global virtual teams. International Journal of Project Management Volume 30, Issue 2, February 2012, Pages 199- 212. https://doi.org/10.1016/j.ijproman.2011.06.004 https://doi.org/10.1016/j.infsof.2007.09.004 https://doi.org/10.1007/3-540-51635-2_29 https://doi.org/10.1007/s13173-010-0013-3 https://doi.org/10.1145/1138506.1138523 https://doi.org/10.1109/SITA.2015.7358381 https://doi.org/10.1002/spip.417 https://doi.org/10.1145/1536616.1536648 https://doi.org/10.1145/1314215.1314218 https://doi.org/10.1016/j.ijproman.2011.06.004 61 Denhere, N., Hörne, T. & van der Poll, J. A. (2015). Managing Globally Distributed Soft- ware Development Projects using Virtual Teams: A Middle East Case Study. SA- ICSIT '15: Proceedings of the 2015 Annual Research Conference on South African Institute of Computer Scientists and Information Technologists. https://doi.org/10.1145/2815782.2815786 Dingsøyr, T. &