Vanhentuneen järjestelmän päivitystä jarruttavat 4 ansaa – ja miten pääset niistä irti

By Artem Barmin

Ohjelmistomigraation tekniset haasteet on dokumentoitu hyvin, mutta älykkäitä teknologiasta vastaavia johtajia estävistä psykologisista esteistä tehdä oikea-aikaisia päätöksiä keskustellaan harvoin. Tässä artikkelissa tarkastellaan, miksi kokeneet teknologiajohtajat lykkäävät usein kriittisiä migraatioita, ja esitellään viitekehys päätöshalvauksen voittamiseen.

Heikko skaalautuvuus, kasvava tekninen velka ja vaatimustenmukaisuusriskit – nämä ovat merkkejä siitä, että vanha järjestelmäsi on korvattava. Vanhat järjestelmät voivat tuntua luotettavilta työjuhdilta – vakailta ja tutuilta – mutta pinnan alla ne voivat kaikessa hiljaisuudessa kerryttää teknistä velkaa, muodostaa pullonkauloja innovoinnille ja aiheuttaa merkittäviä vaatimustenmukaisuusriskejä.

Merkit ovat selviä ja riskit kasvavat, mutta huomaat silti siirtäväsi päätöstä neljännes toisensa jälkeen. Kuten Mohan Sitaram toteaa artikkelissa Menneiden verkkojen haamut, "vanhat järjestelmät voivat vaikuttaa harmittomilta, kunnes ne alkavat aiheuttaa kaaosta." Jos tämä tilanne kuulostaa tutulta, koet sitä, mitä kutsun "migraatioparalyysiksi" – etkä ole yksin. 

Tässä kirjoituksessa tarkastelemme migraation neljää suurinta estettä – perfektionismia, epäonnistumisen pelkoa, loputtomia viivästyksiä ja yhteisymmärryksen tavoittelua – sekä esitämme käytännöllisiä strategioita niiden voittamiseen. Jos olet lykännyt kriittistä migraatiota, tämä opas auttaa sinua murtamaan paikalleen jähmettymisen ja ryhtymään päättäväisiin toimiin ennen kuin kustannukset muuttuvat ylivoimaisiksi.

Migraatioparalyysin neljä ansaa

1. "Seuraavan neljänneksen" oireyhtymä

Me kaikki tunnistamme tämän: "Tartumme siihen lomakauden, seuraavan rahoituskierroksen tai suuren julkaisun jälkeen." Totuus on, ettei migraatiolle ole koskaan täydellistä ajankohtaa. Tuon myyttisen täydellisen hetken odottaminen aiheuttaa suurempia ongelmia kuin ne, joita yritämme välttää.

Työskentelin hiljattain CTO:n kanssa, joka oli suunnitellut maksunkäsittelyjärjestelmänsä siirtämistä kuuden peräkkäisen neljänneksen ajan. "Teemme sen heti Black Fridayn jälkeen" muuttui muotoon "Odotetaan ystävänpäivän alennusmyyntien jälkeiseen aikaan", ja sitten muotoon "Ehkä kesäkauden jälkeen." Samaan aikaan heidän "väliaikaisista" korjauksistaan tuli pysyvää arkkitehtuuria, ja heidän tekninen velkansa kasvoi nopeammin kuin luottokorttilasku joulun jälkeen.

Käännekohta koitti, kun he alkoivat seurata "viivästymisen kustannuksia" – ei ainoastaan euroissa vaan myös tiimin työmotivaation ja menetettyjen mahdollisuuksien osalta. Joka maanantai he tarkastelivat yksinkertaista koontinäyttöä, jossa esitettiin hätäkorjauksiin käytetyt tunnit, suorituskyvyn heikkenemistä kuvaavat mittarit ja uusiin ominaisuuksiin menetetty aika. Kun he näkivät, että tiimi käytti yli 20 % ajastaan pelkästään toiminnan ylläpitämiseen, myytti "täydellisestä ajankohdasta" viimein särkyi.

Näin tapahtuu, kun odotamme seuraavaa neljännestä:

  • Pienet ongelmat kasaantuvat järjestelmätason ongelmiksi
  • Pikakorjauksista tulee pysyvää arkkitehtuuria
  • Tekninen velka kerryttää eksponentiaalisesti kasvavaa korkoa
  • "Täydellistä ajankohtaa" on jatkuvasti vaikeampi löytää

Aseta itsellesi ehdottomat laukaisimet. Tämä CTO määritteli yksinkertaisen säännön: jos hätäkorjaukset ylittävät 20 % kehitysajasta kahtena peräkkäisenä kuukautena, migraatiosta tulee automaattisesti hallitustason keskustelunaihe. Täydellistä hetkeä ei enää odoteta – päätökset tehdään selkeän tiedon perusteella.

2. Täydellisyysharha

"Jos aiomme tehdä tämän, meidän on tehtävä se oikein." Kuulostaa järkevältä, eikö totta? Tämä on ammattimaisuudeksi naamioitunutta perfektionismia. Se on ääni, joka saa sinut lykkäämään toimia, kunnes sinulla on täydellinen suunnitelma, täydellinen tiimi ja täydelliset olosuhteet.

Mentoroin kerran kasvavan finanssiteknologiayrityksen CTO:ta, jolla oli yksityiskohtaisin koskaan näkemäni migraatiosuunnitelma. Se sisälsi kattavat arkkitehtuurikaaviot, perusteelliset riskinarvioinnit ja täydelliset varasuunnitelmat – kaiken mahdollisen. Ainoa ongelma oli, että suunnitelma oli lojunut Confluencessa 18 kuukautta, sitä oli päivitetty säännöllisesti, mutta se ei ollut koskaan päässyt käytäntöön.

Läpimurto syntyi odottamattoman kriisin seurauksena: kilpailija julkaisi ominaisuuden, jonka jäljittelemiseen olisi pitänyt kulua viikkoja, mutta heidän tiiminsä arvioi siihen kuluvan kuukausia vanhan järjestelmän rajoitteiden vuoksi. Silloin hän ymmärsi, että tänään toteutettu riittävän hyvä migraatio voittaa täydellisen migraation, joka ei koskaan ala.

He hylkäsivät valtavan suunnitelman ja aloittivat yhdellä yksinkertaisella kysymyksellä: "Minkä pienimmän osan voisimme siirtää niin, että sillä olisi todellista vaikutusta?" He tunnistivat ilmoituspalvelun – hallittavan komponentin, jolla oli selkeät rajat.

Oliko migraatiosuunnitelma täydellinen? Ei. Kohtasivatko he joitakin ongelmia? Kyllä. Mutta kolme kuukautta myöhemmin heidän ensimmäinen palvelunsa toimi modernissa infrastruktuurissa, ja mikä tärkeintä, he olivat saaneet vauhtia.

3. Uran säilyttämisen ansa

Ollaan rehellisiä: epäonnistuneet migraatiot ovat päättäneet uria. Tämä pelko saa monet CTO:t valitsemaan tutun paholaisen sen sijaan, jota he eivät tunne. Kukaan ei nimittäin saanut potkuja nykytilan ylläpitämisestä... ennen kuin sai.

Eräs kollegani oppi tämän kantapään kautta. Hän oli menestyvän verkkokauppa-alustan CTO, ja järjestelmä, jonka päällä alusta toimi, oli hänen henkilökohtaisesti vuosia aiemmin suunnittelemansa. "Se on vakaa", hän tapasi sanoa keskusteluissamme. "Miksi vaarantaa tasapaino?" Häntä arvostettiin yrityksessä, ja häntä kiitettiin siitä, että hän piti kaiken sujuvasti käynnissä.

Sitten tuli musta perjantai. Heidän tilaustenkäsittelyjärjestelmänsä, joka oli ollut vuosien ajan "vakaa", ei pystynyt käsittelemään uusia kuormitusmalleja. Katkos kesti kuusi tuntia – verkkokaupan ajassa ikuisuuden. Hallituksen ensimmäinen kysymys ei koskenut katkosta, vaan sitä, miksei heitä ollut varoitettu järjestelmän rajoituksista.

Ironista? Välttämällä epäonnistuneen migraation urariskin varmistamme usein juuri sen lopputuloksen, jonka yritämme estää. Järjestelmät eivät vanhene kuin hyvä viini.

4. Yhteisymmärryksen aiheuttama lamaantuminen

"Kaikkien on oltava mukana ennen kuin etenemme." Vaikka sidosryhmien sitoutuminen on tärkeää, yleisen yhteisymmärryksen odottaminen johtaa helposti toimettomuuteen. Eri tiimeillä on erilaiset prioriteetit, ja jollakulla on aina syy odottaa.

Muistan erään lääketieteellisiä ohjelmistoja valmistavan yrityksen teknologiajohtajan, joka oli päättänyt tehdä asiat "oikealla tavalla" – hankkimalla jokaisen osastonjohtajan hyväksynnän ennen migraation aloittamista. Talousosasto oli huolissaan kustannuksista, myynti tarvitsi takuut nollakatkoista, operatiivinen johto halusi odottaa sesonkihuipun jälkeiseen aikaan, ja lakiosasto oli huolissaan vaatimustenmukaisuudesta siirtymän aikana.

Kuuden kuukauden kokousten jälkeen he olivat edelleen lähtöruudussa. Käännekohta tuli, kun hän muutti lähestymistapaansa: yksimielisen hyväksynnän tavoittelun sijaan hän alkoi rakentaa halukkaiden liittoumaa. Hän tunnisti tiimit, joihin vanhan järjestelmän rajoitukset vaikuttivat eniten – tässä tapauksessa potilasajanvarausten ja laskutuksen osastot – ja teki niistä migraation puolestapuhujia.

Sen sijaan, että he olisivat yrittäneet käsitellä kaikkien huolenaiheita etukäteen, he toteuttivat pilottimigraation vain näiden kahden osaston kanssa. Tämä kohdennettu työ onnistui siinä, missä kuukaudet kokouksia eivät: se osoitti konkreettiset hyödyt, jotka vakuuttivat muut sidosryhmät liittymään mukaan.

Vapaudu: päätöksenteon viitekehys

Tässä ratkaiseva hetki koittaa. Nähtyäni lukemattomien teknologiajohtajien selviytyvän näistä haasteista olen kehittänyt viitekehyksen, joka raivaa psykologiset esteet tieltä ja ohjaa kohti toimintaa. Käydään jokainen vaihe läpi todellisten esimerkkien avulla siitä, miten menestyneet teknologiajohtajat ovat hyödyntäneet niitä.

kuvakaappaus Freshcodesta migraatiolamaantumisen voittamiseksi
Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

Vaihe 1: Tunnista ennakkokäsityksesi

Aloita tunnistamalla, mitkä edellä mainituista toimintamalleista vaikuttavat päätöksentekoosi. Kyse ei ole menestyneestä teknologiajohtajasta, joka kertoi minulle kerran: "Vaikeinta ei ollut teknisten haasteiden tunnistaminen – vaan sen myöntäminen, että pelkoni olivat suurin este." Hän oli viivästyttänyt kriittistä migraatiota toisessa yrityksessä koetun aiemman epäonnistumisen vuoksi. Vasta tunnistamalla tämän ennakkokäsityksen tietoisesti hän pystyi arvioimaan nykytilannetta objektiivisesti.

Aloita kysymällä itseltäsi seuraavat kysymykset:

  • Vältänkö tätä migraatiota aiempien kokemusteni vuoksi?
  • Olenko myynyt sidosryhmille nykyisen järjestelmämme vakauden liian myönteisesti?
  • Annanhan täydellisen olla riittävän hyvän vihollinen?

Kyse ei ole syyllisten etsimisestä – vaan henkisten esteiden raivaamisesta.

Migraation vaikeinta osaa ei ole tekninen haaste – vaan päättäminen aloittaa.

Vaihe 2: Muotoile kysymys uudelleen

"Pitäisikö meidän tehdä migraatio?" on väärä kysymys. Se ohjaa sinut kyllä/ei-ajatteluun, jossa panokset tuntuvat mahdottoman suurilta. Opin tämän opetuksen vähittäiskauppa-alustan teknologiajohtajalta, joka kamppaili päätöksensä kanssa, kunnes muutti kysymyksenasettelunsa täysin.

Sen sijaan, että he olisivat esittäneet ylivoimaiselta tuntuvan kysymyksen "Pitäisikö meidän tehdä migraatio?", he alkoivat esittää täsmällisempiä kysymyksiä, jotka edellyttivät konkreettisia vastauksia:

"Mikä on vielä yhden vuosineljänneksen odottamisen todellinen hinta?" 

He laskivat hosting-kustannusten lisäksi myös kiertotapojen parissa käytetyt kehittäjätunnit, ominaisuudet, joita he eivät pystyneet julkaisemaan, sekä markkinamahdollisuudet, jotka he menettivät. Kun he näkivät maksavansa 50 000 dollaria kuukaudessa vain nykytilan ylläpitämisestä, päätös kirkastui luonnostaan.

"Jos minut palkattaisiin tänään, mitä tekisin?"

Tämä ajatusharjoitus vapautti heidät aiempien päätösten painolastista. "Se oli vapauttavaa", he kertoivat minulle. "Kun tarkastelin teknologiakokonaisuuttamme niin kuin uusi työntekijä olisi sitä tarkastellut, etenemistapa oli ilmeinen. Kukaan ei valitsisi rakentaa sitä, mitä me parhaillaan ylläpidämme."

"Säilytänkö vakautta vai säilytänkö ongelmia?"

Tämä kysymys paljasti, että heidän ”vakaa” järjestelmänsä oli korttitalo, jonka ylläpitäminen vaati yhä sankarillisempia ponnisteluja. Heidän vakaudeksi kutsumansa asia oli vain tuttua kaaosta.

Vaihe 3: Kahden luettelon menetelmä

Eräs finanssiteknologiayrityksen teknologiajohtaja, jonka kanssa työskentelin, oli juuttunut analyysihalvaukseen, kunnes kokeilimme tätä yksinkertaista mutta tehokasta harjoitusta. Otimme valkotaulun ja jaoimme sen kahteen sarakkeeseen:

”Ongelmat, jotka pahenevat odottamalla:”

  • Heidän kokeneimmat kehittäjänsä turhautuivat ja vihjailivat lähtemisestä
  • Tekninen velka kasvoi kuukausi kuukaudelta
  • Tietoturvakorjausten asentamisesta tuli yhä monimutkaisempaa
  • Jokaisen uuden ominaisuuden toteuttaminen kesti pidempään kuin edellisen
  • Asiakasvalitukset järjestelmän hitaudesta lisääntyivät

”Ongelmat, jotka helpottuvat odottamalla:”

  • Siirtotyökalut saattavat kehittyä entisestään
  • Tiimi saattaa saada lisää kokemusta uusista teknologioista
  • Hankkeeseen voitaisiin varata lisää budjettia

Kun luetteloita tarkasteltiin rinnakkain, päätös selkiytyi yhtäkkiä. ”Odottamisen” sarake koostui enimmäkseen hypoteettisista hyödyistä, kun taas ”toimi nyt” -sarake oli täynnä konkreettisia ja pahenevia ongelmia.

Tee päätös: todellisuuteen perustuva lähestymistapa

70 prosentin sääntö

Et tarvitse 100-prosenttista varmuutta – tämän opin terveydenhuolto-ohjelmistoyrityksen teknologiajohtajalta, joka odotti liian pitkään ”täydellistä selkeyttä”. Kun viivästystä oli kestänyt kolme vuosineljännestä, kilpailija julkaisi vastaavan toiminnallisuuden puolet lyhyemmässä ajassa, koska se ymmärsi jotain ratkaisevaa: sinun ei tarvitse tietää kaikkea, vaan riittävästi.

Tältä ”riittävä” näyttää:

70 prosentin luottamus arvioosi

”Minulla oli monimutkainen laskentataulukko, jossa seurasin jokaista mahdollista riskiä”, hän kertoi minulle, ”mutta mentorini esitti yksinkertaisen kysymyksen: ’Jos sinun pitäisi tehdä tämä päätös juuri nyt tietämiesi asioiden perusteella, tuntuisiko sinusta, että olet todennäköisemmin oikeassa kuin väärässä?’ Silloin tajusin piilottelevani analyysin taakse.”

70 prosenttia keskeisistä sidosryhmistä mukana

Huomaa, ettei kyse ole kaikista – vaan liikkeelle pääsemiseen tarvittavasta kriittisestä massasta. Eräs vähittäiskaupan teknologiajohtaja kertoi strategiastaan: ”Kartoitin sidosryhmien huolet yksinkertaiseen matriisiin: suuri vaikutus/pieni vaikutus, kannattava/vastustava. Kun suuren vaikutuksen ja kannatuksen ryhmä oli samalla linjalla, se riitti aloittamiseen. Muut liittyivät mukaan nähdessään ensimmäiset onnistumiset.”

70 prosenttiin kriittisistä kysymyksistä on vastattu

Kysymykset, joihin et nyt pysty vastaamaan, selkiytyvät, kun etenet. Eräs tiimi jakoi kysymykset kolmeen ryhmään:

  • On vastattava ennen aloittamista
  • Voidaan vastata työn edetessä
  • Olisi hyvä tietää, mutta eivät estä etenemistä

100 prosentin saavuttaminen on usein kalliimpaa kuin 30 prosentin epävarmuuden käsitteleminen toteutuksen aikana. Tehtäväsi ei ole poistaa kaikkia riskejä, vaan tehdä niistä hallittavia.

Peruttavuustesti

Eräs peliyrityksen teknologiajohtaja opetti minulle tämän lähestymistavan. Esitä jokaisen merkittävän päätöspisteen kohdalla kolme kysymystä:

Voidaanko tämä päätös perua tarvittaessa?

He loivat ”poistumisreitit” – selkeästi dokumentoidut polut takaisin aiempaan tilaan jokaisessa siirron vaiheessa. ”Mahdollisuus palata takaisin teki meistä rohkeampia etenemään”, hän selitti.

Mikä on varasuunnitelmamme? 

He pitivät vanhan järjestelmänsä vain luku -tilassa kaksi kertaa niin pitkään kuin olivat katsoneet tarpeelliseksi. Kallista? Kyllä, mutta se mahdollisti yöunet.

Mikä on väärässä olemisen todellinen hinta?

Ei katastrofaalinen, kaiken rikkova tilanne, jonka ahdistuksesi kuvittelee, vaan realistinen pahin mahdollinen tapaus. Yleensä se on paljon hallittavampi kuin pelkäät.

Ensimmäiset 30 päivää

More Articles

Viikko 1: Päätöksentekorupeama

  • Maanantai: Kerää keskeiset mittarit
  • Tiistai: Sidosryhmien haastattelut
  • Keskiviikko: Riskien arviointi
  • Torstai: Alustavan suunnitelman luonnostelu
  • Perjantai: Päätöspiste

Viikot 2–3: Vauhdin rakentaminen

  • Ilmoita päätöksestä selkeästi
  • Perusta siirron komentokeskus
  • Aloita pienillä, konkreettisilla toimilla
  • Juhlista varhaisia onnistumisia

Viikko 4: Toteutuksen käynnistäminen

  • Käynnistä pilottiprojekti
  • Luo palautesilmukat
  • Määritä edistymisen mittarit
  • Aikatauluta säännölliset tarkistuspisteet

Yhteenveto

Siirron vaikein osa ei ole tekninen haaste – vaan päätös aloittaa. Siirtoon liittyvät psykologiset esteet ovat usein teknisiä esteitä suurempia. Epäonnistumisen pelko, perfektionismi, yhteisymmärryksen tavoittelu ja houkutus siirtää asia "ensi vuosineljännekselle" voivat lamaannuttaa kokeneimmatkin teknologiajohtajat.

Olemme kuitenkin myös nähneet, miten menestyvät CTO:t murtavat nämä esteet. He tekevät sen eivätkä poistamalla kaikkia riskejä tai saavuttamalla täydellistä yhteisymmärrystä, vaan:

  • Muuttamalla epämääräiset pelot mitattaviksi mittareiksi
  • Pilkkomalla näennäisen monoliittiset päätökset pienemmiksi, peruttavissa oleviksi vaiheiksi
  • Rakentamalla koalitioita sen sijaan, että he odottaisivat yksimielistä hyväksyntää
  • Hyödyntämällä 70 prosentin sääntöä edetäkseen "riittävän" eikä "kaiken" kanssa

Ehkä kaikkein tärkeintä on, että olemme oppineet siirtopäätösten syntyvän harvoin yksittäisinä, dramaattisina hetkinä. Ne ovat järjestelmällisten viitekehysten, selkeiden laukaisimien ja rehellisen itsearvioinnin tulosta.

Menestyneimmät näkemäni siirrot eivät olleet niitä, joissa oli täydelliset suunnitelmat – vaan niitä, joissa johtajat ymmärsivät ja hallitsivat psykologiaansa yhtä huolellisesti kuin järjestelmiään.

Tilaa The CTO Clubin uutiskirje, niin saat lisää näkemyksiä ohjelmistojen siirrosta.

Artem Barmin
The perfect blend of technology, psychology, and creativity is where true innovation happens—that's where I love to operate and mentor others.
Follow the author:

You may also like