“Näin Google tekee laskeutumissivut. Se on alan standardi.”
“Emme voi toimittaa tätä ennen elokuuta. Laskimme arviomme yhteen, ja tulokseksi saimme kuusi kuukautta.”
“Odota vain kaksi viikkoa tämän kiireellisen korjauksen kanssa. Emme voi rikkoa sprinttiä, tai emme enää ole ketteriä.”
Jokainen näistä on valhe, jonka tekninen tiimisi kertoo sinulle – ja itselleen. Nämä hyvin yleiset väärinkäsitykset juontuvat insinöörien keskuudessa yleisestä perustavanlaatuisesta virheestä: uskosta “parempaan”.
Parempi ei ole parempi kaikille
Tietokoneen sisällä vallitsee ykkösten ja nollien maailma. Aritmetiikkaan ja logiikkaportteihin ei liity epäilyksiä tai epävarmuutta, ja satunnaista kosmista sädettä lukuun ottamatta kone on täysin deterministinen: se kulkee aina samaa polkua pitkin, kun sille annetaan samat syötteet.
Jopa pelien tai simulaatioiden näennäinen satunnaisuus on todellisuudessa illuusio. Jos annat esimerkiksi pseudosatunnaisen siemenarvon Minecraftille, saat täsmälleen saman toiminnan jokaisella pelikerralla. On hyödyllistä muistaa, että jokainen IT-tiimisi jäsen valitsi ammatin, johon liittyy näin korkea varmuuden ja ennustettavuuden taso; heidän työtään on kirjaimellisesti mahdotonta tehdä ilman tiukkaa ensimmäisistä periaatteista lähtevää päättelyä.
Mutta laskennallisen maailman ulkopuolella kohtaamme arvaamattomia ihmisiä, ja kaikki ennusteet menevät uusiksi. Mikään myyntitiimi ei edes harkitsisi saman esityksen tai myyntipuheen käyttämistä jokaiselle potentiaaliselle asiakkaalle, ja jokainen asiakaspalvelupuhelu on erilainen ja yllättävä. Käsikirjoitukset ja koulutus auttavat henkilöstöäsi saavuttamaan johdonmukaisuuden, mutta lähestymistapaa on ratkaisevan tärkeää vaihdella tilanteen mukaan. Tämän havaitsivat monet organisaatiot yrittäessään ottaa holokratian tai lean-menetelmät käyttöön jäljitelläkseen Zapposin ja Toyotan menestystä – ja epäonnistuivat täydellisesti.
Tämä pätee ohjelmistojen rakentamiseen aivan yhtä lailla kuin operatiiviseen toimintaan, talouteen tai strategiaan: ei ole olemassa yhtä oikeaa tapaa suunnitella kirjautumisnäyttöä, laatia raporttia tai selvittää, mistä ominaisuuksista asiakkaat ovat valmiita maksamaan. Siksi insinöörit ovat kehittäneet huimaavan määrän ohjelmistokehitysmenetelmiä, kuten Scrumin, Kanbanin, ShapeUpin, Spotifyn mallin, SAfEn ja sadat muut – kaikki joissakin tapauksissa menestyksekkäitä ja toisissa katastrofaalisia.
Nyt voit nähdä, miksi me tekniikan parissa työskentelevät joudumme paremmuususkon ansaan. Kuka tahansa meistä pitäisi houkuttelevana ajatusta, että jossain on kivitaulu, johon ongelmiemme ratkaisu on hakattu, mutta varmuus on vaarallisen viettelevää, kun työskentelet joka päivä työkalujen ja koneiden kanssa, joiden toiminta perustuu täydelliseen johdonmukaisuuteen. Mutta miten pääset eroon binäärisen ajattelun tavasta?
Kysy ensin hellittämättä
Niin monille meistä teknologia on pelkkää mustaa magiaa. Insinöörit mutisevat outoja loitsuja Kubernetesista, tsättitavuista ja tyhjästä ilmestyvistä verkkosivustoista, sähköposteista ja luottokorttimaksuista. Kun velhot siis kertovat meille vakuuttavasti noudattavansa “parhaita käytäntöjä”, keitä me olemme epäilemään heitä?
Vastaus olet SINÄ! Ohjelmistokehittäjät tarvitsevat muiden tiiminjäsenten tavoin palautetta siitä, ovatko heidän suunnitelmansa ja toimituksensa yrityksen strategian mukaisella kurssilla. Sinun ei tarvitse käyttää nörttijargonia reaktioidesi ja ohjeidesi ilmaisemiseen; heidän tehtävänsä on oppia markkinoistasi ja tavoitteistasi riittävästi, jotta he voivat olla sinulle tehokkaasti vastuussa käyttäen yleiskieltä. Älä pelkää kysyä mitä tahansa ja kaikkia kysymyksiä siitä, mitä he priorisoivat, miksi he päätyivät tähän tai tuohon teknologiaan ja ennen kaikkea siitä, miten he odottavat muun liiketoiminnan hyötyvän.
Uskon kysymysten esittämiseen niin vahvasti, että painatin hienoja kultalehtisiä todistuksia, jotka myöntävät virallisen luvan kysyä insinööreiltä aivan mistä tahansa aiheesta, ja jaan niitä aina tilaisuuden tullen. Alla on esimerkki. Jos haluat sellaisen seinällesi, lähetä minulle sähköpostia, niin lähetän sinulle yhden (ilmaiseksi!)
Pelaa seuraavaksi miksi-peliä
Kun olet voittanut kysymysten esittämisen pelon ja oppinut lisää teknisen tiimisi lähestymistavasta, on aika pelata miksi-peliä. Säännöt ovat yksinkertaiset ja tutut jokaiselle viisivuotiaalle: kysy ensin, mitä kehittäjä tekee, ja kysy sitten toistuvasti “miksi”.
“Korvaan maksusivumme.”
“Miksi?”
"Koska se on tehoton.”
“Miksi se on tehoton?”
“Teemme tarpeettomia tarkistuksia, jotka hidastavat vastausaikojamme.”
“Miksi nopeudella on merkitystä?”
"Koska käyttäjät luovuttavat, kun maksaminen kestää liian kauan.”
Merkki lopettaa on se, kun päädytte rahaan. Kun kuulet: ”koska se lisää konversioita”, ”koska yhä useammat asiakkaat siirtyvät maksulliseen versioon” tai ”koska leikkaamme tutkimuskuluja”, olet voittanut. Jos et koskaan pääse siihen asti ja päätät sanomalla ”en tiedä” tai ”koska Jane sanoi niin,”, sinä (et insinööri) olet hävinnyt ’miksi’-pelin. Etsi tapoja yhdistää teknologiatiimisi paljon tiiviimmin liiketoiminnan tuloksiin, jotta kaikki ovat seuraavalla pelikerralla voittajia.
Muutaman miksi-kierroksen jälkeen alat nähdä kaavoja ja puutteita. Työskentelin esimerkiksi erään tiimin kanssa, joka keskittyi täysin konversioasteen kasvattamiseen mutta jätti kustannukset kokonaan huomiotta. Ei siis ollut yllätys, että he ylittivät budjetin reippaasti käyttämällä ylioptimoituja sosiaalisen median mainosstrategioita, jotka olivat aivan liian monimutkaisia yksinkertaiseen joulukampanjaan.
Heidän monimutkaiset algoritminsa olivat toki ”parempia” saamaan pienen hintaedun tietyillä avainsanoilla, mutta Facebook-lasku oli karu todellisuustarkistus sen saapuessa (mukaan lukien maksut joidenkin facebook.com mainospalvelimien kaatamisesta liian monien pyyntöjen vuoksi!). Kun huomaat tällaisia katvealueita, korjaa prioriteetit, peruuta tarpeettomat asiat ja vahvista viestiä siitä, että teknologian on oltava tiiviisti linjassa liiketoimintatavoitteidesi kanssa.
Varmista lopuksi vastuun toteutuminen
Nyt kun olet löytänyt ja karsinut ”paremmat” teknologiaratkaisut, jotka eivät oikeasti palvele sinua, tarjoa insinööreille yksinkertaisia tapoja osoittaa, että he toimivat edelleen linjassa tavoitteiden kanssa ja etenevät suunnitelman mukaisesti. Huomaa, etten sanonut mitään teknologian tiimin ”pitämisestä vastuussa” – sormella osoitteleva lähestymistapa saa minut aina haluamaan piiloutua lähimmän pöydän alle. Sen sijaan mahdollista kehittäjillesi se, että he ovat vastuussa sinulle. Esimerkiksi
- Järjestä viikoittainen esittely IT-parannuksista niin, että tiiminvetäjät kuvaavat liiketoimintahyödyt ja keräävät palautetta sinulta ja muilta.
- Ota käyttöön koontinäyttö, joka näyttää tärkeät mittarit, kuten järjestelmän käytettävyyden tai vastatut puhelut, ja pyydä kehittäjiä selittämään säännöllisesti, miten heidän toimensa parantavat tuloksia.
- Luo etenemispolku keskeisten projektien edistymisen seuraamiseen ja nopeaan palautumiseen, kun tärkeiden osa-alueiden aikataulu viivästyy.
Selkeä strategia säännöllistä palautetta varten ja keskittyminen todellisiin, konkreettisiin liiketoimintahyötyihin varmistavat, ettei IT-kulujasi tuhlata nokkeliin mutta hyödyttömiin ”parempiin” projekteihin. Ja jos sinä, kuten useimmat kanssani työskentelevät yritykset, käytät teknologiaan miljoonia ja tulokset ovat parhaimmillaankin hämäriä, eikö kannattaisi mitata tuottoa tuolle valtavalle investoinnille?
Tilaa The CTO Clubin uutiskirje saadaksesi lisää neuvoja yhteisöltämme.
