Ohjelmistokehitys on täynnä tuttuja viitekehyksiä—ketterä, vesiputousmalli, Scrum—jotka kaikki ovat varmoja valintoja ja auttavat tiimejä toimittamaan ajallaan ja vähäisemmillä yllätyksillä.
Joskus kuitenkin totumme niin mukavasti kulkemaan näitä tuttuja polkuja, että unohdamme todellisten läpimurtojen syntyvän usein silloin, kun joku kokeilee jotakin, joka näyttää paperilla järjettömältä. Se on toki riskialtista, mutta juuri siellä suuret voitot yleensä piilevät.
“AI on todella hyvä tekemään 70 % työstä nopeammin”, sanoo Alex Zajac, Amazonin SDE & AI sekä Hungry Minds -uutiskirjeen luoja. “Mutta viimeiset 30 % ovat vaikeimpia—ratkaisun vieminen tuotantoon, sen varmistaminen, ettei se ala tuottaa hallusinaatioita, sekä arvioinnin suojamekanismien määrittäminen.”
Toisin sanoen rohkea ohjelmistokehitys ei tarkoita vain uusien työkalujen käyttämistä—vaan myös sen vaikean ja epäkiitollisen työn tekemistä, jolla ne saadaan oikeasti toimimaan.
Useimmat yritykset pitäytyvät tutussa toimintamallissa, koska sitä pidetään “turvallisena”. Ketään ei syytetä sääntöjen rikkomisesta, jos idea ei toimi vakioprosessin puitteissa. McKinseyn vuonna 2023 tekemän kyselyn mukaan yritykset, jotka kannustavat harkittuun riskinottoon, päihittävät 1,7x todennäköisemmin alansa kilpailijat innovointimittareilla mitattuna.
Ja vaikka tiedämme, että rohkea ajattelu voi tuottaa tulosta, ympäristöjä, joissa kokeilua todella palkitaan, on yllättävän harvassa. Liian harvat organisaatiot kannustavat ohjelmistoprojekteissa nimenomaisesti riskinottoon.
Varhaiset omaksujat tai joskus suoranaiset pioneerit pääsevät usein määrittelemään säännöt ennen kuin kukaan muu edes tietää niiden olevan olemassa.
Kaikesta pelosta ja epäröinnistä huolimatta on olemassa tiimejä, jotka ottivat suuren riskin ja päätyivät johonkin loistavaan. Tässä on viisi strategiaa, jotka vaikuttivat aluksi epätavallisilta—tai ehkä liian kaoottisilta—onnistuakseen.
Strategia #1: Kaaostekniikka (Netflix)
Netflixin ”Chaos Monkey” rikkoo järjestelmiä tarkoituksellisesti tuotannossa testatakseen niiden vikasietoisuutta. Kuulostaa järjettömältä, eikö? Tämä lähestymistapa auttoi Netflixiä säilyttämään 99,99 prosentin käytettävyyden samalla, kun tilaajamäärä kasvoi 7 miljoonasta yli 230 miljoonaan.
”Ymmärsimme, ettei vakauteen toivominen ollut strategia”, sanoi Netflixin entinen insinööri Kolton Andrus. ”Kun aiheutimme vikoja säännöllisesti, tiimimme lakkasivat pelkäämästä käyttökatkoja ja rakensivat oletusarvoisesti vankempia järjestelmiä.”
Keskeinen oivallus oli vastoin intuitiota: hallittujen vikojen luominen esti todellisuudessa katastrofaalisia vikoja. Netflixin vikasiedon testaaminen paljasti heikkouksia, jotka olisivat muuten pysyneet piilossa suuren käyttökatkon syntymiseen asti.
Käytännön toimintaohje: Aloita ”pelipäivällä”, jonka aikana simuloit vikoja tuotannon ulkopuolisessa ympäristössä. Valitse yksi kriittinen palvelu ja aiheuta yksinkertaisia vikoja, kuten instanssien pysäyttäminen tai verkkoyhteyksien katkaiseminen. Dokumentoi, mikä rikkoutuu, ja korjaa nämä haavoittuvuudet ennen kuin ne aiheuttavat todellisia ongelmia.
Have an account? Log In
Strategia #2: Jatkuva käyttöönotto (Flickr)
Vuonna 2009, kun useimmat yritykset julkaisivat kuukausittain, Flickrin esitys ”10 käyttöönottoa päivässä” mullisti ajattelua. Tiimit pelkäsivät, että pienemmät ja tiheämmin julkaistavat muutokset aiheuttaisivat kaaosta, mutta Flickr havaitsi päinvastaista: tiheämmät julkaisut itse asiassa pienensivät riskiä huomattavasti.
Matematiikka on yksinkertaista mutta tehokasta: jos otat käyttöön 5–10 muutosta kerralla, ongelmien eristäminen on suoraviivaista. Jos otat kuukauden jälkeen käyttöön 500 muutosta, onnea neulan löytämiseen heinäsuovasta.
Pienempi käyttöönottokokonaisuus = pienempi vaikutusalue.
Vuoden 2023 DevOps-tilaraportin mukaan jatkuvaa käyttöönottoa hyödyntävät yritykset raportoivat 70 % vähemmän tuotantovirheitä ja palautuvat ongelmien ilmetessä 24 kertaa nopeammin. Käytännöstä on sittemmin tullut vakiintunut toimintatapa kaikenkokoisissa teknologiayrityksissä.
Käytännön toimintaohje: Ota käyttöön ”käyttöönottoikkuna”, jossa tiimit lisäävät käyttöönottojen tiheyttä vähitellen. Aloita siirtymällä kuukausittaisista viikoittaisiin käyttöönottoihin, jatka sitten kahdesti viikossa, kunnes automaatio ja luottamus mahdollistavat useita käyttöönottoja päivässä. Keskity vankan testikokonaisuuden rakentamiseen niin, että se suoritetaan automaattisesti ennen jokaista käyttöönottoa.
Strategia #3: Täysin etätyöhön perustuva malli (GitLab)
Ennen pandemiaa GitLabin täysin etätyöhön perustuva rakenne vaikutti radikaalilta. Se kuitenkin mahdollisti parhaan osaamisen palkkaamisen eri puolilta maailmaa ja pakotti ottamaan käyttöön erinomaiset dokumentointikäytännöt heti alusta alkaen.
GitLabin julkisesta käsikirjasta (joka on nykyään yli 15 000 sivun laajuinen) tuli heidän salainen aseensa, joka poisti monia hajautettuja tiimejä vaivaavan "En tiennyt tuota" -ongelman. Dokumentaatio ensin -lähestymistapa tarkoitti, että uudet työntekijät pystyivät perehtymään nopeammin ja päätöksenteko muuttui läpinäkyvämmäksi.
Dokumentaatio skaalautuu paremmin kuin hiljainen tieto. Ajattele isosti!
"Kun et voi kysyä tietoa suoraan keneltäkään, sinun on pakko dokumentoida kaikki selkeästi", GitLabin etätyöstä vastaava johtaja Darren Murph selittää. "Tämä luo organisaation resilienssiä, jota toimistokeskeiset yritykset saavuttavat harvoin."
Käytännön vinkki: Vaikka et työskentelisi täysin etänä, ota käyttöön "etätyö ensin" -dokumentointikäytäntö. Luo keskitetty tietopohja kaikille tärkeille päätöksille, prosesseille ja hiljaiselle tiedolle. Aseta säännöksi, että jos jotakin ei ole dokumentoitu, sitä ei ole olemassa. Tarkista dokumentaatio neljännesvuosittain, jotta se pysyy ajan tasalla.
Strategia #4: Runkopohjainen kehitys (Etsy)
Etsy luopui monimutkaisista haarautumisstrategioista ja siirtyi malliin, jossa kaikki tekevät muutoksia pääkoodipohjaan usein. Tämä lähestymistapa haastoi perinteisen ajatuksen siitä, että kehittäjät tarvitsevat eristettyjä ominaisuushaaroja työskennelläkseen tehokkaasti.
"Huomasimme, että pitkään elävät haarat loivat väärän turvallisuuden tunteen", kertoo entinen Etsy-insinööri Daniel Schauenberg. "Todellisuudessa ne vain lykkäsivät integroinnin ongelmia ja loivat suurempia ristiriitoja, kun haarat lopulta yhdistettiin."
Runkopohjainen kehitys auttoi Etsyä kasvamaan 50 kehittäjästä yli 2 000 kehittäjään ja samalla julkaisemaan yli 50 kertaa päivässä. Lähestymistapa pakotti tiimin rakentamaan paremmat automaattiset testit, koska päähaaran oli pysyttävä siistinä, ja se poisti liian yleisen "yhdistämishelvetin", jonka kanssa tiimit joutuvat tekemisiin ominaisuushaarojen yhteydessä.
Alex huomasi samanlaisen ilmiön puhuessaan tekoälystä ja paljon kontekstia vaativista koodipohjista. “Asiat, jotka ovat todella tiiviisti kytkeytyneitä omiin järjestelmiinne… vaativat paljon ihmisiä”, hän sanoi.
Nopeasti muuttuvissa ympäristöissä suoraan runkoversiossa työskentelevien tiimien on ymmärrettävä järjestelmäsuunnittelu ja kompromissit syvällisesti, koska pitkään elävien haarojen taakse on vähemmän mahdollisuuksia piiloutua. Kyse ei ole vain koodin lähettämisestä nopeammin, vaan siitä, että insinöörit ovat lähempänä todellista monimutkaisuutta.
Käytännön vinkki: Ota käyttöön ominaisuusliput keskeneräisen työn piilottamiseksi ja tee samalla muutoksia päähaaraan päivittäin. Aloita pienellä, luotetulla tiimillä, jotta voit rakentaa luottamusta lähestymistapaan. Aseta tiimille tavoitteeksi tehdä muutoksia päähaaraan vähintään kerran päivässä ja mittaa integrointiongelmien vähenemistä ajan mittaan.
Ominaisuuslippujen strategiasi on todella tärkeä sen kannalta, mitä näytät asiakkaillesi!
More Articles
Strategia #5: Avoin lähdekoodi oletusarvoisesti (Hashicorp)
Hashicorp rakensi miljardien dollarien liiketoiminnan julkaisemalla keskeiset infrastruktuurityökalunsa, kuten Terraformin, Vaultin ja Consulin, avoimena lähdekoodina. Perinteisten ohjelmistoliiketoimintamallien vastaisesti tämä strategia mahdollisti nopean käyttöönoton ja tuhansien kehittäjien osallistumisen ympäri maailmaa.
"Kun aloitimme, ihmiset pitivät meitä hulluina, kun annoimme parhaat koodimme ilmaiseksi", kertoo toinen perustaja Mitchell Hashimoto. "Huomasimme kuitenkin, että laaja käyttöönotto luo enemmän arvoa kuin mitä menetät mahdollisina lisenssituloina."
Yksittäisten kehittäjien kohdalla oikeiden tekoälyllä tehostettujen työkalujen valinta voi noudattaa samanlaista logiikkaa. Alex kertoi, että hän päätti hiljattain ostaa Cursor Pron, koska “se vain ymmärtää minua tai ymmärtää työskentelytyylini.” Aivan kuten HashiCorp luotti avoimen lähdekoodin yhteydessä luottamukseen ja yhteisön sopivuuteen, insinöörit suuntaavat nyt intuitiivisesti työnkulkujaan ymmärtäviin työkaluihin – vaikka se tarkoittaisi vähemmän valtavirtaisen vaihtoehdon valitsemista.
Heidän Terraform-työkalunsa sai yli 100 000 tähteä GitHubissa ja siitä tuli alan standardi – saavutus, johon olisi perinteisellä suljetun lähdekoodin lähestymistavalla kulunut vuosikymmeniä. Yritys ansaitsee tuloja yritysominaisuuksilla, tuella ja ylläpidetyillä palveluilla säilyttäen samalla valtavan kehittäjäyhteisön hyvän tahdon.
Toimintasuositus: Tunnista ohjelmistosi komponentit, jotka voisivat hyötyä yhteisön osallistumisesta. Aloita julkaisemalla avoimena lähdekoodina hyödyllinen kirjasto tai työkalu, joka ei kuulu ydin-immateriaalioikeuksiisi. Luo osallistumisprosessi, jonka avulla ulkopuolisten on helppo parantaa koodiasi, ja panosta hyvään dokumentaatioon käyttöönoton helpottamiseksi.
Yhdistävä tekijä
Näitä strategioita yhdistää muukin kuin rohkeus – kyse on harkitusta riskinotosta ja tiiviistä palautesilmukoista. Kukin tiimi rakensi mekanismeja, joiden avulla virheistä voitiin oppia nopeasti ja suuntaa korjata.
Alex mainitsi, kuinka tekoäly muuttaa sitä, mitä kehittäjänä oleminen tarkoittaa. ”Meitä ei korvata”, hän sanoo, ”mutta vastuun liukuva ikkuna siirtyy.”
Jotkut sanovat, että kehittäjistä on tulossa yhä enemmän tuoteinsinöörejä, kun taas toiset ennustavat yleisosaajien ja erikoisosaajien jakautumista eri suuntiin. Joka tapauksessa tämän päivän rohkeat kehitysstrategiat eivät menesty pelkästään innovatiivisten työkalujen ansiosta – ne menestyvät, kun tiimit ovat valmiita mukauttamaan työnkulkujaan, roolejaan ja ajatteluaan.
Kun arvioit kehitysstrategioitasi uudelleen, oikeiden kumppaneiden löytäminen voi vaikuttaa ratkaisevasti. Voit esimerkiksi harkita yhteistyötä joko räätälöityjä ohjelmistoja kehittävän yrityksen tai lähialueen ohjelmistokehitysyrityksen kanssa.
Tilaa The CTO Clubin uutiskirje, niin saat lisää ohjelmistokehitysvinkkejä, työkaluja ja parhaita käytäntöjä.
