(Aika markkinoida).
Jopa viikonloppuisin hän mietti mittareita: ”Entä jos mittaan aikaa? Mitä se antaa minulle?
Todellakin, mitä ajan tieto antaa? Oletetaan, että toimitus kestää 5 päivää. Mitä seuraavaksi? Onko se hyvä vai huono? Vaikka tämä on huono, sinun on jotenkin lyhennettävä tätä aikaa. Mutta miten?
Nämä ajatukset ahdistivat häntä, mutta ratkaisua ei löytynyt.
Ivan ymmärsi, että hän oli päässyt perille. Lukemattomat metriikkakaaviot, joita hän oli nähnyt aiemmin, olivat saaneet hänet jo kauan sitten vakuuttuneeksi siitä, että standardi lähestymistapa ei toimisi ja että jos hän yksinkertaisesti piirtäisi (), siitä ei ole hyötyä.
Kuinka olla?…
Mittari on kuin tavallinen puinen viivain. Sen avulla tehdyt mittaukset eivät kerro syytä, miksi mitattava esine on täsmälleen sen pituinen, jonka hän osoitti. Viivain vain näyttää kokonsa, eikä mitään muuta. Hän ei ole viisasten kivi, vaan yksinkertaisesti puinen lauta, jolla mitataan.
Suosikkikirjailijansa Harry Harrisonin "ruostumaton teräsrotta" sanoi aina: ajatuksen täytyy päästä aivojen pohjalle ja makaa siellä, joten kärsittyään useita päiviä turhaan Ivan päätti ryhtyä uuteen tehtävään...
Pari päivää myöhemmin lukiessaan artikkelia verkkokaupoista Ivan tajusi yhtäkkiä, että verkkokaupan saama rahamäärä riippuu siitä, kuinka sivuston kävijät käyttäytyvät. He, vierailijat/asiakkaat, antavat myymälälle rahansa ja ovat sen lähde. Kaupan saamien käteisen rahan määrään vaikuttavat muutokset asiakkaiden käyttäytymisessä, ei mikään muu.
Kävi ilmi, että mitatun arvon muuttamiseksi oli tarpeen vaikuttaa niihin, jotka muodostavat tämän arvon, ts. verkkokaupan rahamäärän muuttamiseen oli tarpeen vaikuttaa tämän kaupan asiakkaiden käyttäytymiseen ja toimitusajan muuttamiseksi DevOpsissa oli tarpeen vaikuttaa tällä kertaa "luoviin" tiimeihin, ts. käyttää DevOpsia työssään.
Ivan ymmärsi, että DevOps-mittauksia ei pitäisi esittää kaavioilla ollenkaan. Heidän tulee edustaa itseään hakutyökalu "erinomaiset" tiimit, jotka määrittävät lopullisen toimitusajan.
Mikään mittari ei koskaan näytä syytä, miksi tällä tai tuolta tiimiltä kesti kauan toimittaa jakelu, Ivan ajatteli, koska todellisuudessa niitä voi olla miljoona ja pieni kärry, eivätkä ne välttämättä ole teknisiä, vaan organisatorisia. Nuo. Eniten mitä voit odottaa mittareista saavasi, on näyttää joukkueet ja niiden tulokset, ja sitten sinun on silti seurattava näitä tiimejä jaloillaan ja selvitettävä, mikä niissä on vialla.
Toisaalta Ivanin yrityksellä oli standardi, joka vaati kaikkia joukkueita testaamaan kokoonpanoja useilla penkeillä. Joukkue ei voinut siirtyä seuraavalle katsomolle ennen kuin edellinen oli valmis. Kävi ilmi, että jos kuvittelemme DevOps-prosessin katsomoiden läpi kulkemisena, mittarit voisivat näyttää joukkueiden näillä katsomoilla viettämän ajan. Joukkueen kannan ja ajan tunteessa heidän kanssaan oli mahdollista keskustella tarkemmin syistä.
Ivan otti epäröimättä puhelimeen ja valitsi DevOpsin läpikotaisin perehtyneen henkilön numeron:
— Denis, kerro minulle, onko mahdollista jotenkin ymmärtää, että joukkue on ohittanut tämän tai tuon seison?
- Varmasti. Jenkinsimme hylkää lipun, jos rakennelma on onnistuneesti levitetty (läpäissyt testin) penkillä.
- Hienoa. Mikä on lippu?
- Tämä on tavallinen tekstitiedosto, kuten "stand_OK" tai "stand_FAIL", joka kertoo, että kokoonpano läpäisi tai epäonnistui testissä. No ymmärrätkö, eikö?
- Kyllä luulisin. Onko se kirjoitettu samaan kansioon arkistossa, jossa kokoonpano sijaitsee?
- Joo
— Mitä tapahtuu, jos kokoonpano ei läpäise testipenkkiä? Pitääkö minun tehdä uusi rakennus?
- Joo
- No, okei, kiitos. Ja toinen kysymys: ymmärränkö oikein, että voin käyttää lipun luomispäivämäärää telineen päivämääränä?
- Ehdottomasti!
- Super!
Inspiroituneena Ivan katkaisi puhelimen ja tajusi, että kaikki oli loksahtanut paikoilleen. Kun tiedettiin rakennustiedoston ja lippujen luomispäivämäärä, pystyi laskemaan sekuntiin asti, kuinka paljon aikaa joukkueet viettävät kullakin osastolla ja ymmärtää, missä he viettävät eniten aikaa.
"Ymmärtääksemme, missä eniten aikaa kuluu, määritämme joukkueet, menemme heidän luokseen ja perehdymme ongelmaan." Ivan hymyili.
Huomiseksi hän asetti itselleen tehtävän hahmotella piirrettävän järjestelmän arkkitehtuuri.
Jatkuu ...
Lähde: will.com