Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset
(nettipäiväkirja 25.07.2014) Olen parin viime vuoden mittaan usein valittanut sitä, kuinka monen firman valittu metodologia on dokumentoitu. Metodologialla on monta nimeä: parhaat käytännöt, (kokonais)arkkitehtuuri, "policy" eli käytäntö, Meidän Tapamme Tehdä Asioita (tm), metodologia, projektiohjeet ja niin edelleen, vain muutamia mahdollisia mainitakseni.
Ja mikä se ongelma on? No, jotenkin vaikuttaa siltä, että riippumatta siitä, onko metodologia itse kehitetty ja dokumentoitu vai onko se kopioitu jostain muualta, sen määrittelyssä on unohdettu yksi tärkeä asia: ihmisiä on saatanan vaikeaa saada ymmärtämään yhtään mitään. Metodologia on oltava sisäistettävissä ja saatavissa käytäntöön. Jos otat jonkin firman satunnaisen prosessiohjeen, sinulla on edessäsi itse asiassa oppitekstiksi tarkoitettu läpyskä. Ajattelepa nyt, millä kaikella karkilla ja hauskuudella koulun oppikirjoissa yritetään houkutella oppimaan, ja kuinka hyviä tulokset ovat. Mitä mahdollisuutta saada aikaan mitään on tekstillä, joka koostuu sellaisista lauseista kuin "jokainen prosessi on määriteltävä siten, että määrittelyssä tulevat esiin roolit, vaiheet ja vastuunjako"? (Tämä on sentään vielä aika selkeä vaatimus!)
Tyypilliset metodologiadokumentit ovat:
Niinpä parasta ohjeistusta ovat yleensä hyvin tarkat käytännön ohjeet, vaikka ne pureutuvatkin väärään asiaan eivätkä kata "koko" toimintatapojen joukkoa. Esimerkiksi Joel Spolskyn 12 kohdan lista softaprojekteille: http://joelonsoftware.com/articles/fog0000000043.html
kala: Jotenkin arvasi, että nuo esimerkkilauseet olivat ITIListä (jota olen ajatellut paljon tänään ja ylipäänsä kahden viimeisen viikon aikana). Inhoan juuri tuota, että se on niin yleistettyä, ettei mistään voi olla edes esimerkkejä. Ei edes ITIL-kursseilla! Hassua kuitenkin, että suhtauduin ITILiin nimenomaan paljon vihamielisemmin, ennen kuin keskustelin siitä sun kanssa ircissä. Sanoit siitä jotain hyvää, joka muutti mun käsitystä, mutta en valitettavasti edes muista, mitä se oli.
Entinen esimieheni taas puolustaa ITILiä yhteisenä kielenä. Sen mielestä ilmeisesti on hyödyllistä, että ITIL määrittelee tiettyjä sanoja/ilmauksia/jne (siis että mitä tarkoitetaan palvelupyynnöllä tai service deskillä). Tämä on sen verran konkreettinen asia, että voin sen käsittää - ja ehkäpä siitä todella on hyötyä vaikka silloin, jos täytyy kommunikoida toisen organisaation kanssa jostain aiheeseen liittyvästä. En silti ole aivan vakuuttunut - olisiko liian tehotonta luoda uudet määrittelyt joka kerta, kun puhuu uuden toimijan kanssa? Tai voiko oikeastaan tuollainen yleinen määrittely olla koskaan riittävä, onko missään organisaatiossa palvelupyyntö kuitenkaan ihan sama asia? Ja mitä iloa on sitten siitä, että voi kertoa, että "meillä palvelupyyntö on kuten ITILissä, paitsi että x, y ja z"?
Lisäksi mietin tänään prosesseja. Miten asiantuntijatyyppisillä ihmisillä on usein inherentti inho koko sanaa kohtaan. Vaikka oikeastaan todennäköisesti nekin (tietämättään) noudattaa jotain prosessia (joka toivottavasti on järkevä). Ja jos sen toimintatavan vain kuvaisi ja kutsuisi sitä toimintatavaksi, niin sitten se olisikin hyväksyttävää. Tai sitten inhotaan prosessikaavioita - vaikka niistähän on (jos ne eivät ole sellaisia kuten yllä kuvaat) hyötyä silloin, kun uusille tai ulkopuolisille pitää kertoa ytimekkäästi, miten asioita tehdään. Meillä töissä "prosesseja pitäisi kehittää". Pelottavaa kyllä ymmärrän mitä sillä oikeasti tarkoitetaan ja olen samaa mieltä. Ongelma vain on, etten tiedä, miten välttää liiallinen epäluuloisuus kaikkea yleistävämpää kuvausta kohtaan ja toisaalta olla menemättä liian pitkälle joutavanpäiväiseen (ITIL-)jargoniin. Kuitenkin asioiden selvittämisestä olisi selvästi hyötyä (minulle, ryhmälle ja organisaatiolle).
atehwa: Oikeastaan poimin esimerkit juuri ITIListä siksi, että se on julkisesti saatavilla ja oltiin satuttu puhumaan siitä, niin että se oli mielen päällä. ITIL-ohjeethan ei ole niitä huonoimmin kirjoitettuja, mutta silti ne edustavat luettelemiani ongelmia.
Yhteiset käsitteet, siis asioiden nimet, auttavat ihmisten ajattelua paljon enemmän kuin luulisi. On kuitenkin vaikeaa mitata, mikä on jonkin käsitteen käytön nettoarvo. Esimerkiksi, jos voin joko käyttää yleistä käsitettä "prosessi" tai sitten erikseen "toimintatapa" ja "palvelun ylläpito" (näitä molempia kutsutaan prosesseiksi meidän firmassamme), niin onko hyödyksi vai haitaksi, että ihmiset mieltävät - yhteisen nimen myötä - nämä jollain tavalla samaksi asiaksi? Miten mitata eroa, joka syntyy siitä, mitkä asiat ihmiset niputtavat yhteen?
Asiantuntijoilla on muutamia syitä inhota management-kieltä (tai konsulttikieltä). Ensimmäinen syy on se, että sitä käyttävät epämiellyttävät ihmiset, ja asiantuntijat haluavat erottautua tästä laumasta samaan tapaan, kuin duunarijengi ei halua käyttää akateemikkojen homosanoja tai sivistyneeksi identifioituva ihminen ei halua kertoa kaksimielisiä vitsejä. Toinen syy on, että jostain syystä johdon puolella käsitteiden kehittäminen näyttää usein olevan itsetarkoituksellista eikä ole houkuttelevaa ottaa käyttöön käsitteitä, joiden käytöstä on kuitenkin parin vuoden kuluttua jo luovuttu. Kolmas syy on se, että monet näistä käsitteistä (kuten "dynaamisuus") ovat oikeasti niin huonosti määriteltyjä, etteivät ne tarkoita lähes mitään. Ja kuinka moni jaksaa jokaisesta management-käsitteestä miettiä erikseen, onko tämä nyt käyttökelpoinen käsite vai jotain höpöhöpöä?
Normaalikin kieli on epämääräistä (eikä tarkkaa). Tätä epämääräisyyttä ei vain pidä lisätä loputtomiin yrittämällä niputtaa abstraktioiden kautta yhteen "kaikki" asiat, eikä glorifioida keksimällä asioille koko ajan uusia, hienolta kuulostavia nimiä. "Toimintatapa" on parempi kuin "prosessi", koska sitä on käytetty pidempään, se koostuu kahdesta arkikielen sanasta (toimia + tapa) ja sen merkitys seuraa johdonmukaisesti siitä, miten sana on rakennettu. "Prosessi"-sanan epämääräisyyden avulla ihmiset pystyvät liittämään koko ajan uusia asioita käsitteen alle, jolloin tulee epäselvemmäksi, mitä se tarkoittaa, ja mitä joku tarkoittaa puhuessaan prosesseista.
Sitten vielä sellaiset lauseet kuin "prosesseja pitäisi kehittää" tai "sisäistä kommunikaatiota/tiedonkulkua parantaa": nämä tarkoittavat itse asiassa ihan suhteellisen selkeitä asioita, nimittäin "asiat tehdään typerästi" ja "ihmisillä on tunne, etteivät saa tietoja joita olisivat tarvinneet". Ongelmakuvauksina nämä ovat kuitenkin yleisluontoisia, eikä niistä ole enempää hyötyä kuin esimerkkitapauksista, joista ne on yleistetty. Ei siis ruveta yleisiin prosessitalkoisiin, vaan muutetaan esimerkiksi tietokantojen perustamistapaa siten, että jokainen voi tehdä sen omatoimisesti tai ainakin ottaa suoraan yhteyttä tietokannan ylläpitäjään. Eikä yleisiin kommunikaatiotalkoisiin, vaan opetellaan miettimään sähköpostien Cc-kenttiä ennen lähetystä ja työstetään dokumentit kaikkien saatavilla olevissa palveluissa eikä omalla koneella.
Kyllä ihmiset sitten itse oppivat näistä esimerkeistä yleistämään, ja jos eivät opikaan, niin tulos on kuitenkin parempi kuin se, että ohjeistetaan "virtaviivaistamaan prosesseja". Johdon tehtävä on miettiä, mikä kaikki mättää, mutta siinä metodologiadokumenteista ei ole juuri muuta hyötyä kuin se, että ne ovat jonkinlaisia muistilistoja siitä, mikä kaikki voi mättää. Ja mitä yleisemmällä tasolla ne ovat, sitä vaikeampaa sitä muistilistaa on käyttää.
kala: Ymmärsinkö oikein, että sinusta sanojen määritteleminen on hyödyllistä, mutta sen hyödyllisyyden määrää (suhteessa haittaan/vaivaan) on vaikea arvioida ja siksi määrittelyn kanssa pitää olla varovainen?
Ensimmäisen inhon syyn ymmärrän. Muakin tässä (ihan irrationaalisesti) vähän ahdistaa, että kuulostan epäkielen ja joutavanpäiväisen konsultoinnin puolustelijalta :-) Toisaalta mulle on kyllä lähes yhdentekevää, puhutaanko prosesseista vai toimintatavoista (olkoonkin, että ensimmäisestä saa helpommin huumoria aikaiseksi), kunhan asiat toimivat ja ihmiset pysyvät kartalla. Toisekin syyn tajuan, mutta eikö ITILin pointti myös ollut se, että se ei muuttuisi? Tai ehkä se on ITILin pointti, mutta johto sitten vaihtaa parin vuoden päästä ITIListä johonkin toiseen systeemiin? Kolmannesta syystä pitää sanoa, että kaipa tuollaisen pohtiminen on johdon/esimiesten työtä, mutta toki varmaan aika harvoin kovin hedelmällistä sellaista.
Yleiset prosessitalkoot onkin hölmö juttu. Tästä on mun mielestä hyvä esimerkki, että eilen kerroin tietyistä prosesseistamme eräille konsulteille; sanoin, että ei meillä ole tästä tietystä tilanteesta prosessikaaviota tai -kuvausta, mutta kaikki tietävät, miten tulee toimia, eikä asian kanssa ole mitään ongelmia. Jäi silti sellainen käsitys, että tämä olisi jotenkin huono juttu. Ihmeellistä.
Eilisessä kommentissani mulla oli tietysti selkeästi mielessä ne tietyt asiat/tilanteet, joiden toimintapaa taas pitää selventää ja määritellä, koska niissä on ongelmia.
Olin muuten tähän asti kuvitellut, että nämä nimenomaiset (kolme) asiaa, joista silloin puhuin vain 'prosesseina' ovat ne, josta ITILissä puhutaan, kun puhutaan 'prosesseista', mutta eihän se varmaan niin ole. En vain ollut pysähtynyt kyseenalaistamaan. Eiköhän ITILissä ole prosesseja pitkälti yli kolme...
Joka tapauksessa olisi kiinnostavaa löytää oikea tasapaino yleistämisen ja tarkkuuden välille. Jotta ihmiset jaksaisivat lukea, mutta voisivat ymmärtää.
atehwa: Aika pitkälle auttaa se, että pitää mielessä ne ohjeen (metodologian) käyttötapaukset, eli missä tilanteessa ihminen tarvitsee sitä ohjetta ja miten ohje silloin parhaiten palvelisi ihmistä. Siksi suositan tilannesidonnaisia muistilistoja.
Mitä sanojen määrittelyyn tulee: tarkoitin, että sanojen määrittely ja määritelmien vertailu ja sovittaminen yhteen on aina hyödyllistä, mutta jokainen sana ei ole hyödyllinen sana. Niinpä, jos vaikka "osallistaminen" on hyödytön (tai haitallinen) sana, sen määritteleminen on kyllä hyvästä, mutta sana kannattaisi kuitenkin korvata muilla ja niinpä määrittely enintään rajoittaa sanan aiheuttamaa haittaa. Mutta on vaikeaa ylipäänsä mitata/arvioida, onko sanan olemassaolosta hyötyä vai haittaa.
Ja mitä tulee käsitteiden vaihtumiseen: jälkemmäinen vaihtoehto, eli kyse on siitä, ettei ITIL juuri muutu, mutta johto ottaa rinnalle toisen metodologian parissa vuodessa.
atehwa: Asiasta kukkaruukkuun: onko olemassa jokin nimi asialle, joka on muuten niin kuin projekti, paitsi ettei sillä ole suunniteltua loppua? Siis ikään kuin "pysyvä projekti". "Kustannuspaikka" olisi muuten lähes käypä, paitsi että projektilla ei ole välttämättä omaa kustannusrakennetta eikä siten "pysyvälläkään projektilla". "Organisaatiolla" ja "liiketoimintayksiköllä" on omat, väärään suuntaan vievät sivumerkityksensä, ja "prosessi" taas tarkoittaa niin paljon muutakin, että sen käyttö on harhaanjohtavaa.