Asiantuntijaryhmä+Yhteisö

= Asiantuntijaryhmä Yhteisö =

Posteri

Abstrakti

=Asiantuntijayhteisöihin osallistumisen tukeminen=

Taustaa
Erilaiset kehittäjäyhteisöt ovat nousseet merkittävään osaan ohjelmistosuunnittelussa. Monet ohjelmistosovellukset perustuvat ns. Open Source -kehittämiselle, jossa erilaiset yhteisöt toimivat asian kehittäjinä. Ajankohtainen kysymys useissa yrityksissä onkin, miten Open Source -kulttuuria ja liittymistä kehittäjäyhteisöihin voisi tukea?

Open Source (suom. avoin lähdekoodi) tarkoittaa tietokoneohjelman lähdekoodia, joka näkyy ohjelman käyttäjälle ja on tämän vapaasti muokattavissa, kopioitavissa, jaettavissa ja korjailtavissa. Suomalaisittain yksi tunnetuimmista avoimen lähdekoodin ohjelmista on ollut käyttöjärjestelmä Linux. Avoimen lähdekoodin vastakohta suljettu lähdekoodi on tarkoin varjeltu liikesalaisuus, eikä se näy ohjelman loppukäyttäjälle. Open Source -kehittäminen tapahtuu kehittäjäyhteisössä, jossa ei olla kiinnostuneita henkilöiden koulutuksesta tai asemasta. Kehittäjäyhteisön jäsenet osallistuvat kehittämistyöhön osaamisensa ja taitojensa tuomissa rajoissa. Kehittäjäyhteisössä laitetaan liikkeelle keskeneräisiä versioita, jotta ratkaisuja testattaisiin, niistä annettaisiin palautetta ja niitä kehitettäisiin edelleen (Neus & Scherf, 2005)

Työnteko ja asiantuntijuus on usein mielletty toimimiseksi yksin, hankitun koulutuksen ja kokemuksen tukemana. Yksilön oma älykkyys on riittänyt työssä ilmenevien ongelmien ratkaisemiseen. 2000-luvun modernissa ja muuttuvassa työelämässä yksilö ei enää suoriudu työtehtävistään yksin. Tarvitaan kollektiivista älykkyyttä, parviälyä (Hakkarainen, 2003). Asiantuntijuus nähdään yhä enemmän yhteisöllisenä ilmiönä (Hyvönen, Impiö & Järvelä, 2010). Organisaation tiedon luominen voidaan nähdä myös spiraaliprosessina, joka alkaa yksilötasolta ja laajenee vuorovaikutusyhteisöjen kautta yli organisaation rajojen (Nonaka&Takeuchi,1995). Yhteisössä toimiessaan yksilö tulee tietoiseksi muiden yhteisön jäsenten asiantuntijuudesta ja voi täydentää kollektiivista asiantuntijuutta omalla panoksellaan.Yhteisöllisessä ongelmanratkaisuprosessissa on mahdollista syventää jaettua ymmärrystä tutkittavasta asiasta. Yhteisötyöskentelyssä yhteisön jäsenet tarjoavat toisilleen jatkuvasti tiedollisia tikapuita (scaffolding), joiden avulla yksilönkin on mahdollista päästä suorituksiin, jotka yksin toimien olisivat hänelle mahdottomia.(Hakkarainen, 2003).Tällaisissa yhteisöissä osanottajat voivat sekä kehittyä omalla osaamisalallaan (vertikaalinen oppiminen) sekä oppia suhteuttamaan omaa osaamistaan muiden verkoston jäsenten kanssa (horisontaalinen oppiminen). Kasvaakseen asiantuntijaksi ryhmän jäsenen pitäisi sisäistää yhteisön kulttuuri ja kasvaa tätä kautta yhteisön täysivaltaiseksi jäseneksi.Yhteisöllisessä ongelmanratkaisutyöskentelyssä haasteena on juuri yhteisöllisyys: asiantuntijan on opittava kuuntelemaan muita osallistujia (Hyvönen, Impiö & Järvelä, 2010).Yksilön on tehtävä ajatuksensa näkyväksi, jotta prosessi voisi edetä. Myös käytössä olevien yhteisötyökalujen käyttö saattaa aiheuttaa ongelmia yhteisöön kotoutumisessa.

Oppiminen tapahtuu yhä enemmän yhteisöissä ja tämä vaatii osaamisintensiivisissä organisaatioissa uudenlaista asiantuntijuuden hallintaa. Kun työtehtävä vaatii tietoja ja taitoja, joita työpaikan yhteisöissä ei voida hankkia ja kehittää, olisi tarvittava asiantuntijayhteisö löydyttävä työpaikan ulkopuolelta. Ulkopuolinen yhteisö voisi toimia työntekijöiden asiantuntijayhteisönä silloin, kun halutaan saada uutta tietoa yritykseen.

Tarkastelemme tässä työssä avoimen lähdekoodin kehittäjäyhteisöjä asiantuntijayhteisöinä, joissa yrityksen työntekijät toimivat yksityishenkilöinä ja yrityksen työntekijöinä.

Ongelma
Tässä työssä pohdimme, miten organisaatio voisi tukea työntekijänsä liittymistä kehittäjäyhteisöihin. Vaikka lähdekoodit ja kehittäjäyhteisöt ovat avoimia ja jokaisen tavoitettavissa, yrityksen työntekijä ponnistelee yksin annetun haasteen parissa. Samantyyppinen ongelma saattaa pyöriä kehittäjäyhteisön keskustelussa muutaman hiirenklikkauksen päässä. Useimmat työntekijät eivät etsi vastauksia näistä yhteisöistä, ellei yritys ole ns. avoimen lähdekoodin yritys. Yrityksen kannalta kehittäjäyhteisö innovatiivisuudestaan huolimatta hankalasti hahmotettava voimavara: yritys ei voi säädellä sen jäseniä, mielenkiinnon kohteita eikä tuotoksia (Dahlander & Magnusson, 2005). Kehittäjäyhteisön ja yrityksen yhteistoiminta vaatii ajattelutavan muutosta, jotta molempia tyydyttävä rinnakkaiselo toteutuisi. Organisaatiomuutoksia voidaan Seliukovan (2009) mukaan tarkastella kolmessa viitekehyksessä: organisaation tasolla, henkilökunnan osallistumisen tasolla sekä muutoksen hallinnan tasolla. Etsimme ratkaisuja yhteisöihin liittymiseen ja niissä toimimiseen yrityksen johdon näkökulmasta eli organisaation tasolla. Päästäksemme ratkaisuun pohdimme kuitenkin aluksi ongelmaa henkilökunnan osallistumisen tasolla: mitkä tekijät edesauttavat ja hidastavat työntekijää yhteisöön liittymisessä.

Mikä saa työntekijän liittymään yhteisöihin
Avoimia yhteisöjä tutkineet Maria Antikainen, Marko Mäkipää ja Mikko Ahonen toteavat (2010), ettei yhteisöihin hakeuduta rahallisen palkitsemisen toivossa, vaan yhteistyö muiden yhteisön jäsenten kanssa, oppiminen ja yhdessä viihtyminen ovat tärkeämpiä tekijöitä sitoutumisessa yhteisössä toimimiseen. Myös Ridings and Gefen (2004) ovat tutkineet syitä yhteisöihin liittymiseen. Heidän mukaansa pääasiallinen yhteisöihin liittymisen syy on tietojen vaihtaminen yhteisön muiden jäsenten kanssa. Muita tärkeitä syitä olivat ystävyyssuhteet ja yhteisön sosiaalinen tuki. Menestyminen yhteisössä lisää työntekijän mainetta alansa asiantuntijana. Henkel (2008) jakaa kehittäjäyhteisöissä toimivat henkilöt kahteen ryhmään: niihin, joiden työtehtävä liittyy avoimeen lähdekoodiin ja "harrastelijoihin". Ensiksi mainittua ryhmää motivoi se, että yhteisöstä saa apua työtehtävästä suoriutumiseen. Hän mainitsee myös, että yhteisössä toimiminen stimuloi luovuutta, tuo yhteyden ja vastavuoroisuuden tunnetta. Yhteisön etuna on vastavuoroisuus: työstä saa nopeasti palautetta toisilta jäseniltä (Bonaccorsi & Rossi, 2004). Palautteen saaminen kannustaa jatkamaan ja tukemaan myös muita ryhmän jäseniä. Monet liittyvät yhteisöön ideologisista syistä: tiedon tulisi olla vapaasti saatavissa (Henkel, 2008) Oppiminen ja tiedon saanti näyttävät olevan tärkeimmät syyt työntekijöiden liittymiseen yhteisöihin.

**Mikä estää työntekijän liittymistä yhteisöihin**
Työntekijän kannalta työn ja yhteisön yhdistäminen näyttää olevan pulmallista. Kaikki työntekijät eivät edes kerro yhteisössä toimimisestaan työpaikalla (Henkel, 2008)**.** Työntekijän kannalta saattaa olla helpompi kirjautua yhteisöön omalta kotikoneeltaan nimimerkin suojista.Työn ja yhteisön välille syntyy häilyvä rajapinta, jonka rajoja on vaikea asettaa.Kuka asettaa rajat ja mitä ne ovat? Mitä tapahtuu, jos yrityksen kannalta haitallista aineistoa pääsee yhteisöön? Monesti vain yhteisössä toimiva työntekijä tietää, mitä tietyn asian paljastaminen yhteisössä merkitsee**.** Toisaalta työnantaja saattaa vaatia keskustelua jokaisesta yhteisöön vietävästä asiasta (Henkel, 2008). Vastakkainasettelua saattaa aiheuttaa myös kahden "toimeksiantajan" olemassaolo. Kummalle työntekijä on uskollisempi? Työntekijät voivat ymmärtää open source -yhteisön avoimuuden ja läpinäkyvyyden myös johdon yrityksenä saavuttaa täysi kontrolli. He voivat kokea olevansa vastuussa vielä keskeneräisistä tuotoksistaan ja pelätä että tuotosten jakaminen paljastaa heidän virheensä. (Neus & Schref, 2005)

Yhteisössä toimitaan joko vapaaehtoisesti oman mielenkiinnon innoittamana tai yrityksen työntekijänä työtehtävän takia. Kahden osallistujayryhmän intressit ovat erilaiset.Yksilön ja yrityksen intressejä tutkineet Bonaccorsi ja Rossi toteavat (2004), että yrityksen syyt toimia yhteisössä ovat taloudelliset ja tekniset, yksilön sosiaaliset.Siksi yhteisössä toimivan yrityksen työntekijän suhde yhteisöön on hiukan erilainen kuin hänellä olisi toimiessaan yhteisössä vapaa-ajallaan. Yrityksellä on mahdollisuus vaikuttaa imagoonsa yhteisössä niin, ettei sitä (ja sen työntekijöitä) pidettäisi pelkästään hyötymistarkoituksessa liikkuvana loisena (Dahlander & Magnusson, 2005).Pelkkien voittojen havitteleminen yhteisön tuloksia kaappaamalla vie yrityksen maineen yhteisössä ja vaikeuttaa sen työntekijöiden uskottavuutta huomattavasti. Parhaimmillaan yrityksen suhdetta yhteisöön kuvaillaan symbioottiseksi.Tällöin yrityksen pyrkimyksenä on kehittää sekä itseään että yhteisöä.Päätöksiä tehdessä yritys katselee asioita myös yhteisön kannalta (Dahlander & Magnusson, 2005).

Miten yrityksessä päästään kohti open source -kehittämistä
Organisaatiomuutokset eivät koskaan ole helppoja. Jotta yrityksen työntekijät voisivat työskennellä tehokkaasti kehittäjäyhteisöissä toimintakulttuurin, käsitysten ja toimintatapojen täytyisi muuttua open source -kehittämistä tukeviksi. Koska asiantuntijayhteisöihin osallistumisen edistäminen voidaan nähdä organisaation ja sen toimintatapojen muutoksena, on tätä muutosta toimeenpantaessa hyvä huomioida tunnetut organisaationmuutoksen kriittiset menestystekijät. Näitä ovat esimerkiksi(Hall et al.,2002): Henkilötason tekijät: Organisaationaaliset tekijät: Toteutustekijät
 * Johtajat (muutoksenjohtajat, muutosagentit ja mielipidejohtajat)
 * Johdonsitoutuminen
 * Henkilöstön mukaan saaminen
 * Tehokas viestintä
 * Riittävät resurssit
 * Infrastruktuuri
 * Eksplisiittiset tavoitteet
 * Räätälöinti yrityksen tarpeisiin
 * Edistymisenarviointi

Hyvin harvat haasteet, joita muutosprosesseissa kohdataan johtuvat teknologiasta, työkaluista tai prosesseista. Ne johtuvat useimmiten niistä rajoitteista ja raja-aidoista, jotka löytyvät ihmisten ajatuksista. Työntekijöiden täytyisi ymmärtää Open Source -kehittämisen tavat ja saada kokemus toimintatavan hyödyistä ennen kuin on järkevää pyytää heitä kokeilemaan uutta tapaa toimia ja muuttamaan käytöstään. Jotta organisaation toimintatavat voisivat muuttua Open Source-kehittämisen suutaan, vallalla pitäisi olla ajattelutapa, että eivät pelkästään valitut asiantuntijat vaan myös tavalliset ammattilaiset ja jopa loppukäyttäjät voivat antaa merkittävän panoksen ohjelmistotyöhön (Neus & Schref, 2005).

Neus ja Schref (2005) ovat listanneet käyttökelpoisia periaatteita, joiden avulla yrityksessä voitaisiin siirtyä perinteisestä toimintatavasta kohti yhteisöllisen tekemisen toimintatapaa. Heidän mukaansa on tärkeää:
 * pitää asia yksinkertaisena ja välttää turhia metodologioita ja ammattisanastoa
 * löytää ihmisiä jotka ymmärtävät muutoksen ja innostuvat siitä
 * että työntekijöiden ei tarvitse pyytää lupaa levittäessään muutossanomaa
 * antaa ihmisille kokemuksia uuden toimintatavan hyödyistä, heidän pitää saada vastaus kysymykseen "mitä tämä voi tarjota minulle?"
 * aloittaa pienestä, esitellä onnistuminen ja sitten kasvattaa toimintaa

Ratkaisut
Jotta työntekijät liittyisivät asiantuntijayhteisöihin on vahvistettava liittymistä edistäviä tekijöitä ja yritettävä vähentää sen esteitä. Myös tapa, jolla muutosta yrityksessä hallitaan on tärkeä tekijä.


 * 1) Kokeillaan yhteisöllistä toimintatapaa yhdessä, jotta sen hyödyt olisivat kaikille selvät
 * 2) Heitetään omia työtehtäviä kehittäjäyhteisön tehtäväksi ja kerrotaan prosessista ja sen hyödyistä kaikille
 * 3) Muutama innostunut muutosagentti valtuutetaan mentoroimaan, jotta kaikki innostuvat pääsevät heti toimintaan mukaan
 * 4) Työntekijät valtuutetaan toimimaan yrityksen nimissä ja työaikana avoimesti kehittäjäyhteisöissä
 * 5) Sponsoroidaan avoimen lähdekoodin yhteisöä
 * 6) Perustetaan oma kehittäjäyhteisö, johon kaikki työntekijät voivat rekisteröityä ja kutsua omia kontaktejaan vapaasti mukaan. Yhteisön laajenemista edistetään esim. kilpailulla. Yhteisön kehittyessä muodostuu yrityksen kanssa symbioosisssa elävä kehittäjäyhteisö.

**Lähteet**
Antikainen, M., Mäkipää,M., & Ahonen, M.(2010). Motivating and supporting collaboration in open innovation. //European Journal of Innovation Management, 13 (1), 100 - 119//.

Bonaccorsi, A.,& Rossi, C.(2004). Altruistic individuals, selfish firms? The structure of motivation in Open Source software.//First Monda//y //9(1)//.

Dahlander, L. & Magnusson, M. (2005): Relationships between open source software companies and communities: observations from Nordic firms. //Research Policy// 34, 481-493.

Hakkarainen, K.(2003).Kollektiivinen älykkyys.//Psykologia 6,// 384-401.

Hall, T., Rainer, A., & Baddoo, N. (2002). Implementing Software Process Improvement: An Empirical Study. Software Process Improvement and Pract.ice, 7, 3–15.

Henkel, J.(2008). Champions of revealing. The role of open source developers in commercial firms. //Industrial and Corporate Change,Volume 18 (3), 435–471//

Hyvönen, P., Impiö, N., & Järvelä, S. (2010). How complex is a complex environment? The perspectives of experts in working life. Paper presented at AERA 2010 Conference. USA, Denver Neus, A., Scherf, P. (2005) Cultural change with the introduction of open-source collaboration methods. //IBM Systems Journal//, 44 (2), 215.

Nonaka, I & Takeuchi H. (1995). The knowledge creating company. New York: Oxford University Press.

Ridings, C. and Gefen, D. (2004).Virtual community attraction: why people hang out online. //Journal of Computer-Mediated-Communication, 10 (1), Article 4.//

Selioukova, Y. (2009). Critical success factors in software process improvements: Case of Finnish software companies. Accepted for presentation at the //International Conference on Software Engineering Theory and Practice (SETP)//, Orlando, FL, July 13-16, 2009.