Yhteistyö on keskeinen osa nykyaikaisia ohjelmistokehitysprosesseja. Tämä yhteistyö ei rajoitu vain kehitystiimiin, vaan sen pitäisi ulottua myös tuotteen käyttöön, tukipalveluihin ja operaatioihin. Tässä yhteydessä käsitellään erilaisia tapoja, joilla yhteistyö voi parantaa ohjelmistokehitystä ja kuinka laajempi yhteistyö voi tukea DevOps-kulttuurin omaksumista.

Yksi yleisimmistä tavoista parantaa yhteistyötä ohjelmistokehityksessä on vertaisarviointi (peer review) ja jälkikatselmus (debrief). Vaikka nämä kaksi käsitettä muistuttavat toisiaan, niiden aikarakenne eroaa. Vertaisarviointi tapahtuu ennen työtehtävää, jolloin tiimi voi tarkastella ideoita ja suunnitelmia ennen niiden toteutusta. Jälkikatselmus taas tapahtuu tehtävän suorittamisen jälkeen, jolloin arvioidaan testituloksia ja pyritään löytämään kehitysalueita. Tämä on yleinen käytäntö ketterissä kehitystiimeissä, mutta siirtyminen DevOps-kulttuuriin voi tuoda mukaan laajemman joukon ihmisiä. Esimerkiksi operaatio-, analytiikka- ja tukitiimien osallistaminen vertaisarviointiin ja jälkikatselmukseen tuo tuoreita näkökulmia ja voi parantaa ohjelmiston toimintaa tuotantoympäristössä.

Tällaisessa laajemmassa yhteistyössä ei kuitenkaan ole kyse vain kehitystiimien arvioinnista. Operaatio- ja tukitiimien pyytäminen arvioimaan kehitystiimin työtä ja antamaan palautetta voi auttaa löytämään alueita, jotka eivät ole saaneet tarpeeksi huomiota, tai alueita, joihin olisi hyvä kiinnittää enemmän huomiota. Tämän tyyppinen yhteistyö ei ole raskasta, jos se pidetään lyhyenä ja rajattuna. On tärkeää asettaa selkeä odotus siitä, että arvioinnit ja jälkikatselmukset ovat aikarajoitettuja ja että ryhmä itse päättää sopivan ajan keston.

Toinen tehokas yhteistyömuoto on parittelu (pairing), jossa kaksi henkilöä työskentelee yhdessä samassa tehtävässä samalla ajalla ja paikalla, jatkuvasti vaihtaen ideoita ja ajatuksia. Tällöin toinen henkilö voi hallita laitteiston käyttöä, mutta molemmat osallistuvat aktiivisesti tehtävän ratkaisemiseen. Parittelu edistää luovuutta, koska se pakottaa osapuolet selittämään ajatuksiaan ja reagoimaan kumppanin ehdotuksiin. Se myös parantaa tuottavuutta, sillä yhteistyössä työskentelevät henkilöt voivat keskittyä paremmin tehtävään, eikä toisia helposti keskeytetä.

Vaikka parittelu on yleinen käytäntö ketterissä tiimeissä, sen laajentaminen myös muiden osastojen, kuten tukipalvelujen ja operaatioiden, kanssa voi tuoda merkittäviä etuja. Kuvitellaanpa tilanne, jossa kehittäjä työskentelee tarinan parissa, joka muuttaa tuotteen työprosessia, ja päättää parittaa henkilön tukitiimistä testaamaan lokitusvirheitä. Tällöin voidaan yhdistää kehittäjän tekninen osaaminen ja tukitiimin käytännön kokemus, mikä parantaa tuotteen laadunvalvontaa ja käyttöä.

Kolmas hyödyllinen käytäntö on työkierto (job rotation), jossa kehitystiimin jäsenet osallistuvat tukitoimintaan rajoitetun ajan. Tämä auttaa kehittäjiä saamaan ensimmäisen käden kokemusta siitä, kuinka heidän kehittämänsä tuote toimii todellisessa ympäristössä ja millaisia ongelmia käyttäjät kohtaavat. Esimerkiksi yritys kuten Automattic, joka kehittää WordPressiä, pyörittää vuosittaista "All Hands Support" -ohjelmaa, jossa kehitystiimin jäsenet rotatoivat tukitiimiin ja kokevat itse asiakaspalvelun haasteet. Samalla Etsy on ottanut käyttöön tukirotaatio-ohjelman, joka edistää tiimien välistä viestintää ja empatiaa. Näiden käytäntöjen kautta yritykset voivat paremmin ymmärtää asiakkaidensa kokemuksia ja kehittää tuotteita, jotka vastaavat paremmin käyttäjien tarpeisiin.

Lisäksi työkierto voi olla erinomainen tapa kehittää yhteistyötä eri tiimien välillä. Tällöin ei vain kehitystiimi pääse ymmärtämään tukitiimin arkea, vaan myös tukihenkilöstö voi saada syvemmän käsityksen kehityksestä ja sen prosesseista. Tämä vuorovaikutus ei ainoastaan paranna tiimien välistä yhteistyötä, vaan voi myös tukea tuotekehitystä ja asiakastyytyväisyyttä.

Yhteistyö ei siis ole vain työskentelyä saman tiimin jäsenten kesken, vaan se on myös mahdollisuus luoda syvempää ymmärrystä organisaation eri osastojen ja tiimien välillä. Tämä lähestymistapa tukee jatkuvaa parantamista ja voi tehdä kehitysprosesseista entistä tehokkaampia ja käyttäjäystävällisempiä.

Miten kehitystiimit voivat parantaa yhteistyötä muiden osastojen kanssa?

Etsy-ohjelma on jaettu kolmeen osaan: kotitehtäviin, läsnäolokurssiin ja käytännön toteutukseen. Samalla tavoin kuin kehitystiimin jäsenen siirtäminen tukitoimiin, muiden ihmisten kutsuminen kehitystyöhön luo empatiaa ja tiimien välistä yhteistyötä. Se on käytännön tapa laajentaa rajaa eri alojen välillä.

Yhteistyö kehitystyön ulkopuolella

Eri käytäntöjen lisäksi on olemassa muita tapoja edistää yhteistyötä tiimien välillä. Yksi lähestymistapa on luoda käytäntöjä, jotka kannustavat tiimien yhteistyöhön. Yksi tapa saavuttaa tämä on käyttää koodausdojoja. Dojo, ohjelmistokehityksessä, viittaa ympäristöön, jossa osallistujat voivat yhdessä oppia ja harjoitella kehitystaitojaan. Dojo voi olla samasta tiimistä, samalta alalta tai laajemmalta yleisöltä. Itse olen kokenut koodausdojoja osana kehitystiimiä, jossa kehittäjät ja testaajat työskentelivät yhdessä kirjoittaakseen tuotantokoodia ja siihen liittyviä automaattisia testejä. Olen myös vetänyt koodausdojoja ryhmälle testaajia eri kehitystiimeistä, jossa tavoitteena oli sopia uusien testiautomaatiojärjestelmien käyttöönoton standardeista.

Dojojen järjestäminen on erinomainen tapa keskittyneelle yhteistyölle. Dojon aikana koko ryhmä kokoontuu tiettyyn ajankohtaan, yleensä 90-120 minuutiksi. Yksi tietokone yhdistetään projektoriin, ja käytössä on myös valkotaulu ongelmanratkaisua varten. Tietokonetta käyttää pari henkilöä, ja muut osallistujat tekevät sanallisia ehdotuksia. Tietokoneella työskentelevät henkilöt vaihdetaan istunnon aikana, jotta kaikilla on mahdollisuus kokeilla toimimista käytännössä. On myös sensei, joka toimii opettajana tai fasilitaattorina. Hänen roolinsa voi olla dojon aiheen asettaminen, ajan seuraaminen istunnon aikana ja kysymysten esittäminen, jos ryhmä tuntuu menevän sivuraiteille. Sensein tulisi kuitenkin välttää vastausten antamista; ratkaisut pitäisi löytyä osallistujilta itseltään.

Omat kokemukseni tämän roolin hoitamisen aikana ovat opettaneet, kuinka tärkeää on antaa ryhmän työskennellä yhdessä ilman yhden auktoriteetin hallintaa. Vaikka tämä voi olla haastavaa, erityisesti jos itse tuntee halua puuttua asiaan, se auttaa ryhmää tekemään omia ratkaisuja. On ollut kiinnostavaa nähdä, miten osallistujat lähestyivät ongelmaa, ja tämä kokemus auttoi minua ymmärtämään paremmin ryhmän jäsenten persoonallisuuksia ja sosiaalisia dynamiikkoja.

Dojojen järjestämisessä on myös tärkeää pitää mielessä, että osallistujat voivat olla eri taitotasoilla. Jos dojoon osallistuu henkilöitä, joiden taidot vaihtelevat, tulee heitä rohkaista osallistumaan. Tämä voi koskea esimerkiksi suunnittelijoita, projektipäälliköitä tai muita sidosryhmiä, jotka saattavat kokea dojon muodon pelottavaksi. Positiivinen ja rohkaiseva ilmapiiri on tärkeä, sillä negatiivinen palaute voi helposti vieraannuttaa osallistujia ja tehdä heistä epämukavia.

Alkavien kokemusten ja osaamisen jakaminen

Toinen tapa laajentaa yhteistyötä tiimien välillä on tuoda ulkopuolisia näkökulmia organisaatioon. Yksi tapa tehdä tämä on lähettää työntekijöitä alan esityksiin tai konferensseihin, jotka käsittelevät heidän normaalista erikoisosaamisalueestaan poikkeavia aiheita. Toinen vaihtoehto on kutsua asiantuntijoita ulkopuolelta vieraileviksi puhujiksi yritykseen. Jos olet yhteydessä omaan ammattikuntaasi, paikallisesti tai kansainvälisesti, saatat tietää organisaatioita, jotka ovat onnistuneesti toteuttaneet DevOpsin osia. Nämä organisaatiot ovat usein valmiita jakamaan kokemuksiaan, onnistumisiaan ja oppimisiaan. Vaikka tämä ei aina olisi jokapäiväistä käytäntöä, se voi avata uusia näkökulmia ja tarjota arvokkaita oivalluksia.

Esimerkiksi oman organisaationi sisäisissä konferensseissa, joihin kutsuimme ulkomaisia puhujia, kaikkien osallistujien oli mahdollista jakaa saman oppimiskokemuksen. Tämä vahvisti keskusteluja ja mahdollisti sen, että nämä keskustelut siirtyivät päivittäiseen työhön. Ulkopuoliset puhujat voivat siis tarjota paitsi uutta tietoa, myös syventää tiimien yhteistyökykyä ja ymmärrystä alasta.

Konwayn laki ja yhteistyön rajat

Yhteistyön laajentamisella on kuitenkin suoria vaikutuksia myös ohjelmiston kehittämiseen. Conwayn laki, joka sanoo, että "organisaatio, joka suunnittelee järjestelmän, tuottaa järjestelmän rakenteen, joka on kopio organisaation viestintärakenteesta", tuo esiin sen, kuinka tärkeää on, että organisaation viestintä ja yhteistyö ovat toimivia eri osastojen välillä. Jos kehitystiimi ei ole riittävästi yhteydessä muihin tiimeihin, kuten asiakaspalveluun, analytiikkaan tai tukitoimintoihin, se voi johtaa siihen, että tuotettu ohjelmisto on teknisesti toimiva mutta ei vastaa asiakkaiden tarpeita.

Esimerkiksi jos kehitystiimi ei ole yhteydessä asiakaspalveluun eikä analytiikkatiimiin, he eivät ehkä tiedä, kuinka hyvin julkaistut ominaisuudet otetaan vastaan loppukäyttäjien keskuudessa. Vaikka heidän ohjelmointityönsä on teknisesti huipputasoa, he saattavat epäonnistua tuottamaan arvoa asiakkaille, koska he eivät ole kuulleet palautetta asiakkailta tai ymmärtäneet, millaisia ongelmia asiakkaat kokevat. Siksi on tärkeää, että kehitystiimi rakentaa suhteita myös asiakaspalvelun ja muiden asiakasrajapinnan tiimien kanssa, sillä se tuo arvokasta tietoa, joka voi parantaa ohjelmiston suoriutumista ja asiakastyytyväisyyttä.

Miten yritykset suhtautuvat generatiiviseen tekoälyyn ja sen haasteisiin?
Miten käsitellä ei-euklidista graafidataa syväoppimisessa?
Miten hallita aivovamman jälkeisiä käyttäytymis- ja kognitiivisia häiriöitä?