Mikä kannattaa suunnitella, kannattaa ylisuunnitella



Tänä tehokkuuden ihannoinnin aikakautena yleisenä totuutena pidetään, ettei mitään tehtävää pidä hieroa liian pitkään. Pitää olla selkeä näkemys siitä, milloin homma on valmis, ja silmät avoinna niin että havaitaan kun tila on saavutettu.

Ajatusmallissa on kaksi vikaa. Toinen on yksinkertainen ja selkeä, toinen vähän filosofisempi ja hankalahko.

Ensimmäinen on tietysti se, että osaava tekijä tietää kaikessa tekemisessä olevan aina läsnä virhemarginaalin. Tämä pätee myös valmiusasteeseen. Jos virhettä ei huomioida ja lopetetaan tehtävä 100,0% valmiusasteeseen, saattaa pienelläkin toleranssilla tosiasia olla, että ollaan vielä epsilonin päässä todellisesta valmiudesta. Tärkeissä tehtävissä pienikin puute voi osoittautua epämiellyttäväksi, kalliiksi tai ammatillista ylpeyttä rapauttavaksi.

Valmius ei tietenkään ole lineaarinen suure niin kuin jokin rakennuksen kuormituskestävyys (ei ole sekään, mutta siitä lisää alempana). Vaikka olisi mittaustuloksia valmiusarvion virhemarginaalista, ei millään ylivalmiiksi tekemisellä voida varmistaa todellista valmiutta. Ainoastaan pahojen kämmien todennäköisyyttä voidaan reilusti laskea.

Toinen tehokkuusajattelun ongelma liittyy osaamisen perusteisiin.

Asiantuntijatehtävissä pääsääntöisesti ei tehdä isompia kokonaisuuksia, jotka ovat vanhan toistoa. Helpossa projektissa kaikki projektin pienet osat voivat olla entuudestaan tuttuja, mutta kokonaisuutena projekti on ainutkertainen. Hankalammassa projektissa tyypillisesti on yksi tai kaksi kokonaan uutta yksityiskohtaakin (jos niitä on enemmän, projekti epäonnistuu).

Tämä on sekä se, miksi asiantuntijat tekevät töitä (uuden oppiminen on asiantuntijatyypin mielestä miellyttävää), että toimenkuvan epävarmuuden ja sitä kautta epävarmuuden hallintaan käytettävien vaatimusten suurin aiheuttaja.

Tärkein epävarmuuden hallinnan väline on tietysti se asiantuntemus. Koska ei kuitenkaan toisteta aina samaa työsuoritetta, tarvitaan laaja-alaista ymmärrystä ei pelkästään siitä, mitä tehdään, vaan myös siitä, mitä ei tehdä, ainakin siltä osalta, kun ollaan tekemisen rajan välittömässä läheisyydessä.

Yleensä on koko joukko ratkaisuja, joita ei annettuun ongelmaan kannata käyttää. Mistä tieto kannattamattomuudesta tulee? Se tulee siitä, että on kokeillut ja todennut, ettei kannattanut.

Konsulttibisneksessä asiakasprojekteissa ei kannata kauheasti aikaa käyttää näihin kokeiluihin, ellei asiakas täydessä ymmärryksessä osta juuri tällaista kokeilua. Meillä onneksemme on asiakkaita, jotka ovat sen verran valveutuneita asiantuntemuksen olemuksesta, että ovat joskus ostaneetkin.

Jos näitä kokeiluja ei voi tehdä laskutettavana työnä, ne on tehtävä sitten jollakin muulla momentilla. Usein IT-nörtit tekevätkin vapaa-ajan projekteinaan todella omituisia asioita. Pohjimmiltaan niissä on kyse juuri tästä tuntemattomalla alueella tekemisestä. Eräs IT-alan yritys, jonka jätän tässä nimeämättä, voimakkaasti rohkaisi työntekijöitään osallistumasta mihinkään vapaasoftaprojekteihin. Minusta tämä oli pahinta oman jalkansa sahaamista, mitä olen alalla ikinä nähnyt.

Mutta miten se ylisuunnittelu tähän liittyy?

Oikean ja väärän rajan luotaaminen väärää kokeilemalla tulee halvimmaksi suunnitteluvaiheessa tehtynä.

Turhaan koodatun koodin pois heittäminen tuntuu ikävältä. Turhaan piirretyn arkkitehtuuridiagrammin hävittäminen ei ole yhtä emotionaalisesti latautunutta. Joidenkin ohjelmoijien on todella hankala hävittää kirjoittamaansa koodia, ja lopputuloksen näkee kun lukee suuria järjestelmiä.

Joitakin asioita pitää suunnitella, vaikka ne ovat tyhmiä. Vain tällä tavalla voi oikeasti ymmärtää miksi ne ovat tyhmiä.

Kesällä harjoittelin tätä tekemällä ohjelmointikielen kielioppia, jossa tavoitteena oli tehdä C:stä derivoituva kielioppi modernille oliokielelle. Kieliopin rakentamisen monet konfliktit ja niiden ratkaisuyritykset kertoivat emotionaalisella tasolla, miksi Scala on tehnyt selkeän pesäeron Javaan ulkoisessa syntaksissa, vaikka sisuskaluissa onkin paljon samaa. Pääasiallinen eroavaisuushan on tyyppien siirto loppuun, kun Javassa ne ovat alussa. Tyyppien alussaolo deklaraatioissa ymmärrettiin kieliopin ongelmaksi jo 70-luvulla, mutta yllättävän sitkeästi siitä on pidetty kiinni. Mitä monimutkaisemmiksi kieliopit menevät, sitä voimakkaammin tämän vääryyden tuntee, kun tekee mitään syntaksia tiedostavaa työtä, oli se sitten kääntäjä tai editorilaajennus.

En myöskään tietäisi, miksi ristikkopalkkirakenteita ei yleensä tehdä puusta, jos en olisi suunnitellut sellaista. Rakennusnosturissa rakenteena on teräksinen ristikkopalkki. Lyhyissä silloissakin käytettiin aikanaan paljon teräksistä ristikkopalkkia, erityisesti rautatiellä.

No, ajattelin että puurakenteisen talon vaakasuorat kantavat rakenteet ovat turhan materiaalia tuhlailevia, kun tyypillisesti käytetään joko umpinaisia liimapuupalkkeja tai laudoista ja vanerista liimattuja I-palkkeja. Suunnittelin nopeasti ristikkopalkkirakenteen, jonka lisäetuna olisi, ettei sitä tarvitse tehdä talon mittaisesta tavarasta vaan lyhyempikin riittää. Sain puuosatkin laskettua ja olin jo liitoksen kimpussa, kun huomasin että puolet vino-osista on vedossa, ja vetoa siirtävän liitoksen tekeminen puuhun niin että liitos olisi lähellekään niin luja kuin itse osa on lievästi ilmaistuna mahdotonta.

Nyt ymmärrän, miksi niin ei tehdä. Aikaisemmin tiesin vain, että niin ei tehdä. Tämä on se, mitä onnistuneesta ylisuunnittelutapahtumasta tulee ulos.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *