Monimutkaisia järjestelmiä rakennettaessa ja etenkin muutettaessa monet perinteisen johtajuuden opit eivät usein ole tarkoituksenmukaisia. Ohjelmointi ei ole yksinkertaista toimintaa vaan järjestelmät ovat monimutkaisia ja sisältävät paljon riippuvuuksia ja oletuksia. Kooditasolla tehdään päivittäin päätöksiä, jotka vaikuttavat ohjelmistoon ja sen kehitykseen vielä vuosienkin päästä, ja monesti ohjelmistoja ylläpidetään useita vuosia ja joskus jopa kymmeniä vuosia.

Lisäksi näitä rakentavat ihmiset ovat yleensä keskivertoa loogisempia, rehellisempiä, kokeilunhaluisempia ja älykkäämpiä mikä aiheuttaa joitain ylimääräisiä haasteita heidän kanssaan toimiessa. Esittelen muutamia johtamistyylien ongelmia, joihin olen itse törmännyt tai joiden olen seurannut olevan valloillaan ohjelmistokehityksen villissä maailmassa.

Tehtävien tarkka vastuuttaminen tietyille henkilöille

Viestintä ja koordinointi vievät sitä enemmän aikaa mitä enemmän ihmisiä on mukana, joten ohjelmiston kehitys on yleensä sitä tehokkaampaa mitä vähemmän ihmisiä sitä tekee (Brooks). On houkuttelevaa jakaa ohjelmisto pieniksi paloiksi ja vastuuttaa ne tarkasti tietyille henkilöille. Tämä näyttää toimivan todella hyvin, joskus jopa vuosien ajan, kunnes raja tulee vastaan. Järjestelmä muuttuu liian vaikeaksi rakentajilleen tai alkuperäiset henkilöt eivät enää ole mukana kehityksessä. Kukaan ei joko tiedä tai muista miksi asiat on tehty niin kuin ne ovat. Monesti mysteerit kerrostuvat toistensa päälle eli ensimmäinen outo ratkaisu johtuu jostain muusta oudosta ratkaisusta, mikä taas johtuu kolmannesta oudosta ratkaisusta ja niin edespäin. Pitkien selvitysten jälkeen usein huomataan, että juurisyy olisi ollut ratkaistavissa yksinkertaisesti. Kehitysalustat myös kehittyvät nopeaa vauhtia ja harva kykenee yksin tietämään kaiken tarpeellisen. Se että ihmiset tekevät asioita yksin johtaa usein myös oma-aloitteisuuden vähenemiseen. Vastuualueet siiloutuvat ja kukaan ei enää lähde ratkaisemaan ongelmia vastuutettujen tehtävien väliin jääville harmaille alueille.

Tämän ongelman välttämiseksi voi varmistaa, että kukaan ei ”omista” osaa projektista, työt kiertävät ja tieto leviää. On hyvä pitää mielessä, että menestyvissä tiimeissä kaikki ovat vastuussa kaikesta koko ajan (Larson & LaFasto).

Tarkat käskyt

Tämä on sukua tarkalle vastuuttamiselle, mutta eroaa siinä, että ihmisillä ei välttämättä ole tiettyjä omia vastuualueita vaan heille annetaan täsmällisiä ohjeita, milloin milläkin alueella tehdään mitäkin. Onnistuminen riippuu täysin johtajasta koska tarkka käskytys vaatii, että hän ymmärtää kaiken olennaisen projektista. Klassinen oire tästä taudista on karjaisu: ”kukaan ei ole käskenyt tehdä noin!”. Todennäköisesti tämä hävittää tiimiltä oma-aloitteellisuuden, ylpeyden ja innostuneisuuden. Kun ihmisiä kohdellaan kuin lapsia, he alkavat pian käyttäytyä kuin lapset. He eivät selvitä asioita muuten kuin omien tehtäviensä osalta, joka puolelle jää harmaita alueita, joista ei ole käsketty huolehtia ja tiimiläiset eivät ymmärrä kokonaisuuksia koska ”ovat vain töissä täällä”.

Se toimii hyvin vain silloin, jos ihmisten ei tarvitse selvittää asioita, pohtia riippuvuuksia, ymmärtää kokonaisuuksia tai toimia omillaan. Ei siis kovinkaan menestyksekästä järjestelmien kehittämisen kanssa.

Tarkkojen käskyjen sijaan tiimissä on hyvä jakaa tietoa korkeankin tason tavoitteista sekä pitää yllä ilmapiiriä jossa asioita selvitetään ja jokaista pidetään kyvykkäänä tekemään päätöksiä.

Vahva ja ylivertainen johtaja

Monimutkaisten asioiden kanssa on äärimmäisen vaikeaa olla kaikessa parempi kuin alaiset. Se onnistuu lähinnä niin ettei hyväksy tiimiin mukaan lahjakkaita ihmisiä. Ideoiden hylkääminen vain kokemusvuosien tai aseman perusteella johtaa siihen, että ne, joilla on paras tilannekuva varsinaisesta työstä eivät tule huomioiduksi päätöksenteossa. Ihmiset myös passivoituvat nopeasti, jos tuntevat olevansa vain sivuosassa ja käskyjen ehdottomuus johtaa usein siihen, ettei kustannuksia säästäviä kompromisseja ehdoteta.

Tiimeissä, joissa on kevyempi hierarkia, käydään avoimia keskusteluja, kyseenalaistetaan asioita ja oivalletaan hyviä ratkaisuja.

Tarkka suunnitelma ja sen ehdoton seuraaminen

Tämä esiintyy ongelmana monissa sovellustason ohjelmistoprojekteissa. On mahdollista, että tiedetään ja ymmärretään ennalta kaikki vaatimukset ja markkinatilannekaan ei tule muuttumaan. Useimmiten kuitenkin jossain vaiheessa opitaan uutta käytetystä teknologiasta, tiimistä, asiakkaiden tarpeista ja loppukäyttäjien toiminnasta. Myös erilaisia väärinymmärryksiä saadaan korjattua ja markkinat sekä yhteiskunta tuppaavat muutenkin tarjoilemaan yllätyksiä. Suunnittelu on tärkeää, mutta suunnitelmat eivät.

Valmius muutoksiin on useimmiten järkevämpi vaihtoehto. Tämä saavutetaan painottamalla koodin, vaatimusten, suunnitelmien, dokumentaation ja infran muutettavuutta. Koodin kanssa monesti eksytään rakentamaan liian monimutkaisia asioita muutoksiin ”valmistautuessa”. Tämä johtaa usein kuitenkin paljon vaikeammin muutettaviin koodipohjiin. Yksinkertaisuus on hyvä nyrkkisääntö niin koodissa kuin useimmissa muissakin asioissa. Esimerkiksi tuntikausia kaunisteltu dokumentti voi olla kauniin näköinen, mutta vaikea muuttaa.

Arkkitehti suunnittelee ja koodaajat koodaavat

Kaunis ajatus, mutta valitettavasti monimutkaiset järjestelmät eivät yleensä mahdu kenenkään päähän ja niiden mukana tulee yllättäviä rajoitteita aivan alimmilta tasoilta asti. Liittyy myös tarkan suunnitelman ongelmiin siltä osin, että harvoin ymmärretään mitä kaikkea vaaditaan. Lopulta suunnitellun mallin mukainen toteutus voi tulla maksamaan järkyttävän määrän ja kukaan tekijöistä ei tiedä miksi tarkalleen asiat tehtiin hämmentävän vaikeasti.

Järjestelmiä varten on hyvä olla kantava näkemys, joka määrää viime kädessä mihin suunnataan, mutta tämän näkemyksen vartijoilla olisi tärkeää olla kädet savessa vähintäänkin osan ajasta.

Manipulointi

Älykkäät ihmiset huomaavat nopeasti, että heitä yritetään ohjailla ja he saattavat alkaa epäilemään normaaliakin käytöstä manipulointina, jolloin luottamus heikkenee. Keskimääräistä rehellisemmät ihmiset eivät pidä siitä, että heille sanotaan asioita mutta motiivina on jotain täysin muuta.

Avoimuus ja yhteisen tavoitteen luominen ohjaavat huomattavasti manipulointia paremmin.

Mahdottomat tavoitteet

Myyjät ja johtajat tunnetusti inspiroituvat äärimmäisen vaikeista tavoitteista. Keskivertoa loogisemmin ajattelevat kehittäjät taas pitävät mahdottomuuksia mahdottomuuksina, pyrkivät todellakin onnistumaan tavoitteissaan ja ottavat tavoitteissaan epäonnistumisen vakavasti. Ennen pitkää he alkavat ajattelemaan suurieleisiä tavoitteita vain tyhjänä puheena. Jos tavoitteisiin ei olla missään vaiheessa päästy ja seuraava tavoitekin kuulostaa järjettömältä niin eihän se herätä juurikaan luottamusta.

Ohjelmistokehityksessä tavoitteet toimivat parhaiten, kun ne ovat haastavia mutta saavutettavissa.

Tiedon pimittäminen

Monimutkaisten järjestelmien kanssa on vaikea sanoa mikä on olennainen tieto kenellekin. Pienikin yksityiskohta voi aiheuttaa suuria muutoksia ja voi hyvinkin olla, että vain joku pienten yksityiskohtien kanssa toimiva kykenisi huomaamaan riskin. Yksi usein kysytyistä kysymyksistä kehittäessä on että pitääkö jonkin toiminnon muuttua jos toinen samantapainen toiminto muuttuu. Tällaisten asioiden ratkaisemiseksi tarvitaan paljon tietoa järjestelmästä, mutta useimmiten koodaaja ei tiedä paljoakaan ja tekee vain jonkin päätöksen johonkin suuntaan. Olen nähnyt, miten puolen tunnin työllä onnistuttiin nimeämään muutama oleellinen asia hämmentävästi, minkä jälkeen nämä nimet levisivät ympäri järjestelmää. Ja mistä kärsittiin useita vuosia, työaikaa jatkuvasti menettäen, kunnes lopuksi käytettiin useita henkilötyöviikkoja niiden muuttamiseen. Tämän asian toinen puoli on tekijän vastuu ottaa selvää mistä asiassa on kyse.

Tiimissä olisi hyvä olla ilmapiiri, jossa tietoa levitetään ja jossa jokaista kannustetaan, jopa velvoitetaan, ottamaan selvää siitä mitä on tekemässä. Mitä-kysymyksen lisäksi muita hyviä kysymyksiä ovat ketkä, miten, miksi, missä ja mihin.

Insentiivit ja paine

Bonukset kaikille, jos saadaan kuukauden tavoitellut tehtävät valmiiksi kolmessa viikossa! Muuten rangaistuksena huutoa, masentava palautepalaveri ja tuntikirjausten sekä raporttitaulukoitten täyttäminen ainakin kahteen kertaan. Mikä voisi mennä vikaan? Ylläpidettävyys. Ohjelmistokehityksessä on paljon eri tapoja tehdä heikkoja ratkaisuja, joiden vaikutusta ei yksinään huomaa edes muutaman kuukauden kuluttua, mutta kun vastaavia kertyy useampia niin ennen pitkää muutokset muuttuvat moninkertaisesti vaikeammiksi. Paine ja insentiivit voivat myös heikentää innovointia ja muiden työntekijöiden tai saman organisaation eri osien selviytymistä. Lisäksi ohjelmoijat rakentavat ja kiertävät järjestelmiä työkseen, eli mittareiden kiertäminen on heille normaalia helpompaa ja useimmiten jopa hauskaa. Pieni paine on usein hyvästä, mutta on helppo sortua ansaan, jossa lisätään painetta ja koetaan että se nopeuttaa asioita lyhyellä aikavälillä vaikka se aiheuttaakin myöhemmin kammottavia ongelmia. Monimutkaisten järjestelmien kehittäjät ovat hyviä saavuttamaan tavoitteita. Jos tavoitteena on ainoastaan maksimoida lyhyen aikavälin kehitysnopeus, niin pitkän aikavälin kehitysnopeus kärsii.

Ihmiset ovat erilaisia, mutta oman kokemukseni mukaan painetta ja insentiivejä tulisi käyttää harkiten.

Asioiden antaminen mennä omalla painollaan

Monimutkainen järjestelmä syntyy jo lähtökohtaiseksi tarpeettoman monimutkaiseksi, sillä on helpompi heittää asioita vain jotenkin entisten päälle sen sijaan että pysytään tilanteen tasalla kokonaiskuvasta ja järjestellään jokainen uusi palanen omalle paikalleen. On tärkeää, että monimutkaisuutta hallitaan koko ajan koska pienet päätökset vaikuttavat merkittävästi vielä vuosienkin kuluttua. Monesti annetaan järjestelmän suunnittelu ja toteutus tehtäväksi lahjakkaalle ja innostuneelle kaverille ja annetaan hänen vielä hoitaa se yksin. Jos muita on mukana niin he ihastelevat teknistä lahjakkuutta ja ajattelevat etteivät mene sotkemaan asioita sillä tämä yksilöhän on nero. Asiat etenevät mukavasti kuukauden, vuoden ja ehkäpä toisenkin mutta sitten hämmästellään miten pienetkin muutokset alkavat olla mahdottomia eikä kukaan ymmärrä järjestelmää.

Älä anna kenenkään tehdä järjestelmiä yksin ja muista vanha viisaus: tarpeeksi suuri joukko silmämunia tekee kaikista bugeista näkyviä. (Raymond)

Yhteenveto

Ohjelmistoprojektien monimutkaisuuden, pitkäikäisyyden ja mukana olevien ihmisten luonteenpiirteiden takia perinteinen ja jopa maalaisjärjen mukainen johtaminen ei toimi halutulla tavalla. Esimerkiksi komponentti voi olla tehty suunnitelman mukaisesti, nopeasti ja hyvin toimivaksi, joten sen voidaan ajatella olevan menestys. Mutta sen ylläpitoon saatetaan käyttää seuraavan vuoden aikana mittava määrä aikaa ja siitä voi seurata paljon muita ongelmia, mitkä olisi voitu säästää levittämällä tietoa ja pitämällä asiat yksinkertaisina.

Useimmat ongelmat helpottavat, jos tiimissä vallitsee avoimuus, järkevät tavoitteet, tiiminä toimiminen, valmius muutoksiin ja kulttuuri, jossa ei rangaista siitä, että ihmiset tekevät hyviä asioita vaikka ne olisivat heidän vastuualueidensa ulkopuolella.

Lähteet:

Heikki Naski on käyttänyt erilaisia etenemistapoja sekä itseohjautuvissa että tarkemmin vahdituissa ohjelmistokehitys- ja palvelinylläpitotiimeissä ja seurannut tiiviisti ohjelmistoalaa mm. Sytykkeen riveissä. Hän työskentelee Edita Publishingilla ohjelmistokehittäjänä.

Johtaminen

, , ,