Ohjelmistokehitys on hyvin haastavaa. Ensinnäkin on ymmärrettävä haasteet tai ongelmat, joita ollaan ratkaisemassa. Sitten on mietittävä ratkaisu. Ratkaisusta riippuen softakehittäjän täytyy mahdollisesti miettiä asianmukaista teknologiaa tarpeen ratkaisemiseen. Joissain tapauksissa tuo tulee annettuna muualta. Tai voi jopa olla että osa teknologiasta tulee annettuna ja osa täytyy päättää itse. Prosessin aikana on oltava selkeä käsitys järjestelmästä, jonka parissa työskentelet ja olisi pystyttävä ajattelemaan pitkällä aikavälillä.

Miksi meidän on keskityttävä?
Yksinkertainen vastaus on se, että kun suuntaamme huomiomme vain yhteen tehtävään ja sen saamiseen valmiiksi, teemme päätöksiä, omaksumme ja käsittelemme tietoa nopeammin. Keskittyminen on ensimmäinen askel flow-tilaan. Flow-tilan ollessa päällä pystymme tuottamaan laadukasta materiaalia vauhdikkaasti riippumatta siitä millä alalla työskentelemme. Tilaan on vaikea päästä, ja jos häiritsemme sitä, tarvitsemme paljon aikaa päästäksemme takaisin. Siksi meidän on keskityttävä intensiivisesti työhömme, jotta voisimme suoriutua paremmin.

Selkeät tavoitteet
Keskity tässä selkeisiin, ei tavoitteisiin.

Olen nähnyt monia kehittäjiä, jotka ajattelevat, että sprintin suunnittelu ja tehtävien määrittely ovat jossain mielessä ajanhukkaa. Jokaisen tehtävän yksityiskohtiin on mentävä ja on ymmärrettävä mitä valmis tehtävä ihan yksityiskohtaisella tasolla tarkoittaa. Ja mitä se vaatii, että tehtävän voi saada valmiiksi. Jättiläismäiset kilpailutusdokumentit ovat näiden antiteesi. Yleisesti noissa kuvataan tarvittavat toiminnallisuudet ylätasolla, mutta yksityiskohdat jäävät uupumaan. Ja yksityiskohdat on ne mistä saadaan hyöty, mutta myös ne jotka maksavat. Ohjelmistokehittäjän tarvitsemiin selkeisiin tavoitteisiin tarvitaan se, että kukin tehtävä on joko riittävän yksityiskohtaisesti kuvattu tai että ohjelmistokehittäjällä on tiedossa mistä yksityiskohdat on selvitettävissä. Oma suosikkini näistä on ehkä enemmän jälkimmäinen, niin rikkinäisen puhelimen mahdollisuus jää pienemmäksi.

Softakonsultit ja ohjelmistokehittäjät joutuvat monesti työskentelemään ympäristössä, jossa ei ole kunnollisia tuotespesifikaatioita. Päädymme myös usein paikkoihin, joissa teemme monimutkaisia asioita ja kokonaisuuksia. Minkään laajamittaisen kokonaisuuden tekeminen kerralla valmiiksi ei useimmiten ole mahdollista tai järkevää. Kukin työtehtävä pitäisi saada pilkottua niin pieneksi kokonaisuudeksi että pystyt työstämään sen valmiiksi yhden tai kahden päivän aikana. Mieluummin jopa nopeammin. Jos työstämäsi ominaisuus on monimutkainen, jaa se osiin. Mutta miten ikinä teetkään työtäsi, muista se että suurin osa meistä on huonoja multitaskaajia. Meidän pitäisi tehdä vain yhtä asiaa kerrallaan.

Ketterissä menetelmissä on paljon hyviä aihioita softakehittäjiä tukemaan, mutta ne eivät kuitenkaan ratkaise kaikkia ongelmia. WIP-limitit ja vastaavat ovat projektinjohtajille hyviä työkaluja tukemaan tiimejä työkuorman jakamisessa. SCRUM-menetelmänä lupaa läpinäkyvyyden ja oikein käytettynä pitää softakehittäjien työpöydät tyhjänä suorista yhteydenotoista kesken ohjelmointityön. Näiden avulla softakehittäjät voivat keskittyä olennaiseen, eli saattamaan työtehtävät yksi kerrallaan valmiiksi. Lisää RND:n käyttämistä menetelmistä lisää tulevissa blogeissa.

Yksilötasolla kannattaa miettiä hiljaisia hetkiä työpäivään, jolloin asiakkaat, työkaverit tai vastaavat eivät pysty sinua tavoittamaan. Yritysten pikaviestimet laulavat jatkuvasti, mutta hyvin harvoin, jos koskaan, niissä on sisältöä joka ei voisi odottaa muutamaa tuntia.