Siin on kiire lugu. Ärianalüütikuna töötasin kirjastuses Oxfordis. Tegime intervjuusid, koostasime protsessiskeeme jne – mis pole eriti huvitav. Samal ajal ja paralleelselt tõid nad kohale konsultante Ühendkuningriigis Birminghamis asuvast väikesest ettevõttest. Kaks või kolm inimest.
Hoone, kus me töötasime, oli pikk ja õhuke, tühja ülemise korrusega. Nendel meestel oli kaasas tohutu 7 jalga kõrgune pruuni paberirull. Nad lasid selle rulli tühjale maale. Siis nad läksid ja rääkisid inimestega ning küsisid, mis süsteeme nad kasutavad, milliseid blankette täitsid ja nii edasi.
Seejärel kleepisid nad sõna otseses mõttes kogu asja sellele paberilehele. Nad võtsid oma ekraanidelt või täidetavatest vormidest välja väljatrükke, kleepisid need kinni ja sidusid musta teibiga kokku, et saaksite näha seoseid.
Kui nad mõne nädala pärast lõpetasid, tõid nad kõik seltskonnas olevad inimesed üles ja ütlesid: “Siin läheme!” Kõik olid lummatud: “Oh issand, ma täitsin selle ära ja siis see läks sinna ja siis ei juhtunud sellega midagi?” Või “See osa on täpselt sama, mis see osa, aga tehtud kahe erineva inimese poolt?” Ja nii edasi ja nii edasi.
See oli parim kingitus, mida konsultandid ettevõttele teha said. Kas see oli väärt 20 000 dollarit (või mis iganes see maksis), lihtsalt kleepida mõned paberitükid suurele pruunile paberilehele? Jah, muidugi. 100%.
Visualiseerimise jõud on hämmastav ja ma olen seda aastate jooksul korduvalt näinud. Rääkisin hiljuti idufirmaga, mis tegeleb mõjuvõimu suurendamisega DevOps Protsesside kaardistamine ja armatuurlauad. Nad küsisid minult, mida ma nende tegemistest arvan, eriti kuna olin pisut skeptiline (nii nad ütlesid mulle).
Niisiis, ma rääkisin neile ülaltoodud loo. Minu kogemuse kohaselt on tarkvara arendusprotsesse väga raske kindlustada, hoolimata kõigist pingutustest metoodikate ja struktuuride määratlemisel. Põhjustesse saame süveneda napsu võttes, kuid tagajärjeks on jätkuv nägemise puudumine. Nagu öeldakse, kui sa ei oska mõõta, siis ei saa ka hakkama. Tarkvaraarendust on kurikuulsalt raske mõõta.
Mida ma ütlen lahenduse tarnijatele, kes üritavad DevOpsi ruumis protsessi nähtavuse koodi murda? Küsimus ei ole vajaduses ega ka fantaasiates, mida on võimalik saavutada tarkvarapaketiga (või kleebised tahvlil või pruuni paberirulliga), vaid selles, kuidas saavutada edu, kui ajalooliselt on paljud püüdnud saada maailma parima tahtega, kindla ajahetkega.
Väljakutse on kahekordne. Esiteks, keegi organisatsioonis (peale tehnoloogia) ei hooli tarkvara toimimisest piisavalt, et sellistele tööriistadele eelarvet eraldada. Millegipärast arvab ettevõte endiselt, et tarkvara töötab ise – poleks ju nii raske kirjutada, kui sul oleks head inimesed, eks? Kõik eeldavad, et ainult targad inimesed panevad asju juhtuma.
Kuid igaüks, kes on mis tahes mahus tarkvara loonud, teab, millisesse keerulisse segadusse võime sattuda ilma õigete juhtimisseadmeteta. Kummalise hea uudisena on see, et oleme kokkuhoiuperioodil, kus IT-juhtidel palutakse IT-kulusid põhjendada – vana kõnekäänd laieneb järgmisele: “Kui te ei saa skaleerida, ei saa te midagi. rohkem raha”, mis paneb kindlasti rõhku mõistusele.
Niisiis, jah, tõhususe nõudlust saab täita säästmiseks kulutavate algatuste abil, mis omakorda õhutavad huvi tarkvaraprotsessi tööriistade vastu, mis on liigitatud Väärtusvoo juhtimineVõi tarkvaraarenduse analüüs vms. Vaadates mitut pakkujat, kes soovivad keerulist probleemi sarnasel viisil lahendada, võrdlen sageli mitut teed ühest mäest üles – ja see ruum ei erine.
Et seda analoogiat veidi täpsustada, näen, et paljud müüjad, kes on erinevates arenguetappides, võtavad selle mäe üles erinevaid marsruute. See viib meid teise väljakutseni, milleks on see, et ükski organisatsioon pole veel suutnud leida korratavat teed tippu.
Kõik tunnevad end mõne aja pärast kurnatuna ja hakkavad hoogu maha võtma. VSM-i aruandes on meil juhid ja väljakutsujad, turgu valitsevad ja uustulnukad, igaüks tegeleb probleemiga omal moel. Idufirmad satuvad sellesse ruumi sageli mõne isikliku üllatuse või “pruuni rulli” hetke kaudu, kui soovite.
Nad jõuavad kohale, suunduvad mäest üles, jooksevad ja jooksevad, hakkavad kiirust aeglustama… ja aja jooksul muutuvad nad lihtsalt kellegi teise platvormi funktsiooniks. Mäletan maailmameistrit Hispaania mäejooksjat Killian JornetTema vägiteod – kuigi me kõik soovime olla selle sportlase sarnased, on ta erand, mitte reegel.
Mida sa sellega teed? Üks vastus on muidugi see, et ärge liiga palju hoolige. Müüja võib tunnistada, et see on alati taktikaline tööriist, mida kasutatakse siis, kui asjad ei lähe hästi. Müüja jaoks viib see turule jõudmise konkreetse marsruudini – gabariidi lüliti, lennukit teenindava mehaanika tööriist, mitte kokpiti keskosa.
Teine võimalus on vaadelda seda, mis on võimalik, pigem vertikaalselt kui horisontaalselt – kui kavatsete olla kokpitis, tehke ühte asja hästi, selle asemel et vaadata kogu lennuki juhtimist. Nii saab täpsemalt määratleda publikut ja seeläbi huvigruppidele pakutavat väärtust.
Mis viib meid kolmanda võimaluseni. Kaaluge kasutusjuhtumeid, kus tööriist võib pakkuda väärtust. Väiksemale rühmale oleks väga hea, kui probleemi ulatust tunneks, antud juhul; Tarkvaraarendus on keeruline ja kipub ilma õigete kontrollide ja tasakaaludeta sassi minema. Kuid on suur eeldus, et teised – eelarve koostamise eest vastutavad kuni juhatuse tasemeni – jõuavad samale järeldusele ilma tohutu pruuni paberirullita, mis oma mõtlemist suunaks.
Kui väljakutse seisneb selles, et enamus ei taha probleemi lahendada, ükskõik kui ilmne see vähemusele ka ei oleks, siis millised on stsenaariumid, mille puhul enamus seda oluliseks peab? Kas on veel üks vajadus, mille puhul enamus on nõus oma rahakotist loobuma? Ja arendusprotsessi ja kuluefektiivsuse asemel alustame sealt?
DevOpsi avalduse juurde tagasi pöördudes… Phoenixi projektsamal alusel Eli GoldrattJa projektijuhtimise parimate tavade uuendustega on alati olnud eesmärgiks ärilised väljakutsed – klientide toomine kodulehele, müügi suurendamine, tarneahelate parandamine jms. Paljud tööriistad ja meetodid põhinevad aga enesevaatlusel ja keskenduvad vahendite, mitte eesmärgi parandamisele.
Me kõik teame, kui raske on tarkvara luua, kuid vaadake esimest punkti: kedagi väljaspool IT-d ei huvita nii palju. Kui me ei saa vajalike paranduste tegemiseks raha, on see üks asi. See on täiesti tõsi, et probleem on olemas. Kuid eeldada, et inimesed võluväel “mõistvad”, et asi vajab lahendamist, on hoopis teine asi.
Niisiis, kui inimesed ei ole selle lahendamisest huvitatud, siis milline stsenaarium paneks nad seda soovima? Sageli oleme selles kaubanduses sunnitud ootama olukordi, kus probleem muutub kriisiks – kohe pärast turvarikkumist, vastavusauditi lähenemist või tarkvarapaketi eluea lõppu.
Selle asemel meeldib mulle kasutada disainmõtlemispõhist lähenemist, mis määratleb ja seab prioriteediks äritulemused – ja see kehtib lõppkasutajate ettevõtete kui lahenduste pakkujate kohta. Milliseid konkreetseid ärinõudeid saab ettevõtete jaoks tarkvaraprotsesside täiustamise kaudu muuta ja millises ulatuses? Milline näeb müüjate jaoks välja koondpilt kogu kliendibaasi?
Kuid pange tähele, et kuigi need stsenaariumid võivad olla sündmused, mille taha tasub raha investeerida, ei ole need lõppmäng – seda võib kirjeldada kui ettevõtte visiooni, missiooni ja strateegiat. Töö ise on mägi – teie enda töö või organisatsioonide töö, mille heaks te teenite. Kui suundute ülespoole, küsige esmalt endalt, kuidas see tippkohtumine välja näeb? Mida sa saavutad, kui sinna jõuad?
Kui vastust ei saa ärilistes terminites kirjeldada, on teie kohalejõudmine palju väiksem. Ausalt öeldes korraldage oma tarkvaraprotsesside täiustamise avakoosolek ainult selge pildiga oma ettevõtte kolmest peamisest eelseisvast eesmärgist ja sellest, kuidas protsessi, tööriistade või muu täiustamine neid otseselt saavutab.
Kui soovite müüjana lihtsalt suurendada oma investori kapitali ja teha kiiret väljumist, väidan, et see on vale tipp. Praegusel digitaalse ümberkujundamise aegadel on ebatõhususe kõige suurem põhjus võib-olla mittevastavus tehnoloogia tarnimise ja ärieesmärkide vahel. Olge valmis alustama teekonda kaardiga tippkohtumiseni, kui soovite üldse kuhugi jõuda.