Julkaistu alunperin 8.4.2015 CxO mentorit Oy:n blogina.
Tapasin kerran henkilön kulttuurialalta. Minun oli hyvin vaikeaa saada hänet ymmärtämään, mitä tein työkseni. Ongelma johtui siitä, että hänen ajatusmaailmassaan kaikki ICT-alan ihmiset ovat ohjelmoijia. Hän ei ymmärtänyt, että minun työtäni ovat ihmiset eivätkä tietokoneet.
Kuinka hyvin organisaation johto ymmärtää erilaisuutta ICT-ammattilaisten välillä? Uskoakseni huonosti, sillä alan sisälläkin toisenlaisten asiantuntijoiden ymmärtäminen on vaikeaa. Tämä johtuu ihmisten erilaisista ajatusmaailmoista. Se häristä puhuu, joka härillä kyntää!
Kerran isoa konesalihanketta auditoidessani havaitsin, että siihen osallistui toistakymmentä erilaista asiantuntijaa. Näillä ei ollut edes keskenään käsitystä siitä, mitä muut tekivät. Muut näkivät, että siellä olivat ne tietoliikennetyypit. Nämä näkivät toisissaan IP-suunnittelijan, runkoverkkoasiantuntijan, konesaliverkon asiantuntijan, palomuurien asiantuntijan ja vielä sen kaverin, joka veti fyysistä piuhaa seinään ja lattian alle.
Ovatko sitten DBA:t, keskenään samaa porukkaa? Vain sovellusasiantuntijat saattoivat tietää, miten tietokannan scheman rakenne on tehty. Varsinaiset tietokantahoitajat eivät schemasta välittäneet, vaikka näin olisi voinut luulla. Heidän hommiansa olivat tietokannan hallintajärjestelmän asetukset ja tietokannan tiedostot. Tosin levylle asti he eivät tiedostoja hoitaneet, sillä levytallennus oli tietysti tallennusverkkoasiantuntijoiden hommaa.
Ihan yhtä hajanainen tilanne on ohjelmointipuolellakin. Käyttöliittymäihmiset eli UX -suunnittelijat ja -devaajat eivät juuri transaktioiden eheydestä huolehdi. Minäkin olin ennen UX -asiantuntija. Silloin UX oli HP:n oma UNIX-versio. Ohjelmoinnin kohde, käytetty kieli, ohjelmointiympäristö ja jopa kehitysparadigmakin vaikuttavat hyvin paljon maailmankuvaan, sovellusalueesta puhumattakaan. Kavereilla on ihan eli lelut, vaikka muista leikki näyttää samalta.
Otetaan vielä mukaan testaus: eri tasoilla ihmiset tekevät eri asioita. Osa tekee työnsä käsin ja toiset rakentavat laajoja testausalustoja. Kerran asiakkaan testausihmiset ja laatupäällikkö menivät testauksen suunnittelutekniikkakurssille ja hämmästyivät, kun siellä käytiin läpi matemaattisia malleja. Siellä ei kerrottu kuinka käyttötapauksista johdetaan testitapauksia hyväksymistestaajien käyttöön.
Ohjelmoijien ja laitteistoihmisten välissä on usein joukko arkkitehteja. On järjestelmäarkkitehti, sovellusarkkitehti ja yritysarkkitehti (engl. enterprise architect). Ensimmäinen miettii jonkin yleiskäyttöisen palvelun tai järjestelmän asioita, esimerkiksi julkaisujärjestelmää. Toinen miettii jonkin tietyn sovelluksen elämää käyttäjältä koneeseen asti ja kolmas miettii koko organisaation tietojenkäsittelytarpeita. Nämäkin ihmiset puhuvat eri asioista, osittain samoilla termeillä.
Laajassa tietojärjestelmähankkeessa pääsee tapaamaan useita edellä mainituista asiantuntijoista. Hanketta johtaa parhaimmillaan ammattimaiset projektipäälliköt ja hankkeen omistavat liiketoimintajohtajat. Näistä kummankaan ammattiryhmän kulttuuriin ei kuulu tietotekniikkaihmisten ajatusmaailmoiden tunteminen. Kuitenkin heidän pitää ymmärtää, mitä ihmiset heille kertovat ja kuinka tärkeästä asiasta kulloinkin on kyse. Asiantuntijoilla on nimittäin kyky nähdä omien asioidensa merkitys projektiin tärkeimpänä onnistumisen edellytyksenä. Mikähän näistä näkemyksistä on milloinkin se kaikkein kriittisin?
Projektit onnistuvat tai epäonnistuvat oikea-aikaisen ja oikein tulkitun viestinnän ja ohjauksen ansiosta. Siksi isoissa hankkeissa on aina tarvetta tekniselle johtajalle. Tekninen johtaja ymmärtää eri alojen kulttuureja ja ajatusmaailmoja. Hän ymmärtää eri asiantuntijoiden motivaatioiden lähteitä ja osata viestiä kunkin omalla kielellä. Onnistumisen perusedellytyksenä on laaja perehtyneisyys ICT-alaan ja monipuolinen kokemus eri toimialoilta. Tällaista repertuaaria ei hankita parissa vuodessa. Ehkäpä meille keski-ikäisillekin on vielä jotain käyttöä!