Kun kaikki menee pieleen – kolme vinkkiä parempiin ohjelmistokehitysprojekteihin
Palautepingistä
Eräässä tuotannonsuunnittelun projektissa olimme päätyneet asiakkaan kanssa pattitilanteeseen. Tehtyihin korjauksiin tuli toistuvasti palautetta, että kehityskokonaisuus ei toimi kuten pitäisi. Saimme ehtymättömältä tuntuvia dokumentaatioita kuvakaappauksineen, mutta emme selkeästikään nähneet, mitä asiakas näki. Vasta kun pääsimme asiakkaan kanssa rauhassa käymään kohta kohdalta läpi heidän havaintojaan ongelmasta, ymmärsimme, miten asiakas asiaa katsoi. Piilossa olleet ongelmat alkoivat avautua ja ratketa yksitellen, oli kuin tulppa olisi auennut. Älä siis koskaan aliarvioi inhimillisen kohtaamisen merkitystä. Vaikka asiakas tietäisi selkeästi, mitä haluaa ja kehittäjät käyttäisivät kaiken ammattitaitonsa ongelmien ratkomiseen, toinen saattaa puhua aidasta ja toinen siitä kuuluisasta seipäästä. Kun istutaan yhdessä alas, pystytään keskittymään kokonaiskuvaan ja turhautumisen sävyttämästä palautepingiksestä päästään ongelmaskenaarioiden ytimeen.
Palvelimet kaatuu
Taannoin yhden asiakkaamme sivut kaatuivat järjestään kerran viikossa, ja palvelinta käynnisteltiin aina kiivaasti uudestaan. Koska tilanne saatiin aina nopeasti palautettua ennalleen, eikä selvää syytä kuitenkaan löytynyt, tilanteesta tuli kaikille uusi normaali, jonka selvittämistä ei priorisoitu. Ongelma kuitenkin ponnahti esiin aina yhtä määrätietoisesti, kunnes yhtenä iltana kotona suihkussa oivalsin, että sivut kaatuvat aina uutiskirjeen lähetyksen tienoilla. Uutiskirjeen, joka sisälsi linkkejä saiteille. Linkkejä, joihin oli kuhunkin sisällytetty yksilöllinen seurantakoodi Google Analyticsiä varten. Tuo yksilöllinen koodi aiheutti sitten sen, että jokainen uutiskirjeen kautta tullut kävijä ohitti sivuston välimuistin ja kuormitti suoraan sovelluspalvelinta. Sehän ei tuollaista kuormaa kestänyt vaan meni nurin joka kerta, käytännössä uutiskirje aiheutti sivustolle ddos-hyökkäyksen. Oppini? Järjestelmällinen tutkiminen ja selvittäminen on ehdottoman tärkeää, mutta sen lisäksi tarvitaan oivalluksia, jotka taas vaativat aikaa, tilaa ja rauhaa.
Tästä tuleekin mieleeni yksi toinen tapaus, jossa ohjelma ei toiminut, painin sen kanssa pitkään. Seuraavana päivänä jatkoin asian selvittämistä, kunnes asiakas kertoi, että heillä on ollut omissa systeemeissään vika – tila oli palvelimelta loppunut. Jos en olisi hätiköinyt, vaan järjestelmällisesti testannut asiaa, olisin todennäköisesti pystynyt laskemaan yksi plus yksi ja nähnyt yhteyden.
Kolme vinkkiämme pähkinänkuoressa
Toimitpa ohjelmistokehityksen parissa sitten toimittajan tai ostajan roolissa, näiden mielessäpitämisestä on sinulle varmasti hyötyä.
Järjestelmällinen lintu madon nappaa
Lähde täysin järjestelmällisesti selvittämään ongelmaa niin, että varmistetaan myös ne asiat jotka "tiedetään varmaksi". Älä ongelmatapauksessa oleta mitään, vaan varmista aivan kaikki, niin lopulta löytyy se kohta, jossa oletus ei pitänytkään paikkaansa.
Me ollaan ihmisiä kaikki
Inhimillinen kohtaaminen purkaa ongelmien jatkumisesta aiheutuneet turhaumat ja päästään rauhassa keskittymään asian selvittämiseen.
Löydä sisäinen meditaattorisi
Omassa päässään pitää pystyä rauhoittumaan, se voi säästää sinulta päivän työn. Kiihtymys toimii järjestelmällisyyden ja oivallusten esteenä. Niin pientä asiaa ei olekaan, että hätäileminen ja prosessin ohittaminen kannattaa. Aikataulupaineistakin kannattaa olla rehellinen asiakkaalle. Jos tekee vain pikaparannuksia, sen yleensä löytää edestään. Siinä kohtaa voi säästää, mutta tuleva kehittäminen voi olla vaikeaa. Myös tämä kannattaa kertoa asiakkaalle.