10 skaalautuvuuden edellytystä, jotka on tiedettävä ennen kasvattamista

Jos olet ollut ohjelmistokehitysalalla tarpeeksi kauan, olet todennäköisesti kokenut tämän painajaisen:

1. Asiakkaalle luvataan paljon ominaisuuksia epärealistisen lyhyessä ajassa (eikä kenelläkään ole rohkeutta kyseenalaistaa sitä).
2. Myöhemmin, kun määräaika lähestyy vaarallisen nopeasti, joku vaikutusvaltaisessa asemassa päättää lisätä ongelman ratkaisemiseksi projektiin enemmän tiimejä, jotta määräajassa pysytään.
3. Asiat alkavat hajota käsiin.

Kuulostaako tutulta?

Tässä artikkelissa kerron, mitä sinun pitää tehdä, jotta voit välttää tällaisen painajaismaisen tilanteen jatkossa (tai jos olet ollut tarpeeksi onnekas etkä ole kokenut sitä, jotta voit välttää sen kokonaan).

Tämän artikkelin näkemykseni perustuvat ohjelmistokehitystiimien skaalaamiseen, mutta voit soveltaa perusperiaatetta liiketoiminnan skaalaamiseen tai tiimin kasvattamiseen millä tahansa toimialalla. Tästä on hyötyä myös silloin, jos otat käyttöön jonkin valmiista skaalautumisen viitekehyksistä — Large Scale Scrum (LeSS), Scrum@Scale tai SAFe.

Tämä johtuu siitä, että keskityn useisiin tärkeisiin skaalautuvuuden näkökohtiin, joita näissä menetelmissä ei koskaan mainita — skaalautumisen perimmäiseen totuuteen, joka usein unohtuu tai jätetään huomiotta.

Skaalautumisen peruslaki

Skaalautumisen peruslaki on empiirinen havainto siitä, mitä projekteissa tapahtuu niiden kasvaessa:

Skaalautuminen voimistaa huonoja asioita ja tekee hyvistä asioista vaikeampia.

Minä muotoilin sanamuodon, mutta en ole ainoa enkä ensimmäinen, joka on tehnyt tämän havainnon.

Katsotaan muutamien skaalautuvuusesimerkkien avulla, mitä laki tarkoittaa käytännössä.

1. Esimerkki: viestintä ja skaalautuvuus

Ensimmäinen ja ilmeisin esimerkki on viestintä. On tunnettu tosiasia, että projektissa olevien ihmisten määrän kasvaessa myös viestintäkanavien määrä kasvaa. Jos viestintäkanavat eivät ole alun perin riittävän hyviä, skaalautuminen pahentaa ongelmaa.

Toisaalta, jos viestintäkanavat ovat alun perin hyviä, skaalautuminen aiheuttaa haasteita paitsi ihmisten kasvavan määrän myös heidän hajautumisensa vuoksi. Usein uusia tiimejä perustetaan eri sijainteihin, mikä pakottaa muuttamaan viestintäkanavia — esimerkiksi siirtymään kasvokkain pidettävistä kokouksista videoneuvotteluihin tai korvaamaan valkotaulun sähköisellä työkalulla.

2. Esimerkki: jatkuva integraatio, jatkuva toimitus ja skaalautuvuus

Näemme skaalautumisen peruslain myös jatkuvan integraation (CI) ja jatkuvan toimituksen (CD) putkissa. Kun tiimejä on vain yksi, asiat ovat melko suoraviivaisia.

Kun yhdestä tiimistä siirrytään kahteen, CI- ja CD-järjestelmät monimutkaistuvat — yleensä kun tiimejä on n, CI-putkien määrä on yleensä n+1 (yksi putki tiimiä kohden ja yksi integraatiota varten). Tämä vaikuttaa selvästi ympäristöjen käyttöönottoon ja tiimien väliseen koordinointiin.

3. Esimerkki: palautesilmukat ja skaalautuvuus

Viimeinen esimerkki koskee palautesilmukoita. Suuremmissa projekteissa palautesilmukat ovat pidempiä. Siksi järjestelmän iteratiivinen hiominen vaikeutuu huomattavasti, mikä lisää riskiä väärän tuotteen rakentamisesta.

Nämä ovat vain kolme esimerkkiä joistakin skaalautumisen aiheuttamista haasteista. Olen varma, että keksit niitä vielä monia lisää.

Oletetaan, että olet valmis hyväksymään asiaan liittyvät kompromissit. Seuraavaksi projektisi on täytettävä tietyt tärkeät ennakkoedellytykset, jotta sen skaalautuvuus voidaan osoittaa käytännössä.

10 skaalautumisen ennakkoedellytystä

Se, onko liiketoimintasi, projektisi tai tiimisi skaalautuva, riippuu useista alla luetelluista ennakkoedellytyksistä. Jos täytät nämä ennakkoedellytykset, skaalautuvuutesi on hyvä. Toisaalta jos jokin niistä ei täyty, epäonnistumisen riski kasvaa dramaattisesti.

1. Selkeät ja yhteiset tavoitteet

Tämän pitäisi olla itsestäänselvyys, mutta kokemukseni mukaan selkeiden ja yhteisten tavoitteiden puuttuminen on erittäin yleistä. Ilman niitä tiimit vetävät eri suuntiin, mikä vaikeuttaa hyödyllisen lopputuloksen toimittamista.

2. Asianmukaisten mittareiden käyttö

Mitä suurempi projekti on, sitä tärkeämpää on pystyä mittaamaan tehtyjen päätösten vaikutuksia. Paransiko esimerkiksi uuden tiimin lisääminen projektin kykyä saada toimitukset valmiiksi? Kuormitammeko tiimejä niin paljon, että laatu heikkenee? Työskentelevätkö tiimit hyvin yhdessä vai häiritsevätkö ne toistensa toimintaa?

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

3. Sopiva arkkitehtuuri

Jos järjestelmän ”muoto” ei vastaa tiimien rakennetta, uusien tiimien lisääminen vain pahentaa tilannetta. Tämä on Conwayn lain suora seuraus. Kyseessä on tunnettu empiirinen havainto, joka on todistettu käytännössä.

4. Johtamis- ja teknisen osaamisen saatavuus

Osaamisen puutteesta johtuvilla ongelmilla on projektin kasvaessa voimistuva kielteinen vaikutus.

5. Hyvät viestintäkanavat

Mitä enemmän ihmisiä on mukana, sitä enemmän viestintää tarvitaan. Onnistunut skaalaus edellyttää sujuvaa viestintää.

6. Hyvä priorisointi ja suunnittelu

Sopivan priorisoinnin ja suunnittelun puute on kokemukseni mukaan hyvin yleinen syy projektien epäonnistumiseen. Erityisesti silloin, kun mukana on useampi kuin yksi tiimi, priorisoinnissa ja suunnittelussa on varauduttava viivästysten ja synkronoinnin puutteen vaikutusten lieventämiseen.

7. Hyvä vaatimusten määrittely ja hallinta

Tämä liittyy läheisesti priorisointiin ja suunnitteluun. Lisäksi virheellisten, väärin ymmärrettyjen tai tarpeettomien vaatimusten vaikutus voimistuu tiimien määrän kasvaessa.

8. Laadukas työ

Mitä suurempi projekti on, sitä suurempi on heikon laadun kielteinen vaikutus. Joissakin poikkeavissa (ja yleisissä) tilanteissa joistakin virheistä voi tulla ominaisuuksia, koska niiden korjaamiseen tarvittavat palautesilmukat voivat olla niin pitkiä, että muut tiimit ovat ehtineet suunnitella kiertoratkaisunsa niiden vaikutusten kumoamiseksi.

9. Resurssien saatavuus

Useammat tiimit tarvitsevat enemmän työpöytiä, tietokoneita, työkaluja ja ympäristöjä.

10. Perusteellinen automaatio

Kaikki manuaalinen toiminta muodostaa pullonkaulan, jonka vaikutukset pahenevat ihmisten ja tiimien määrän kasvaessa. Tästä on hyvänä (ja hyvin yleisenä) esimerkkinä manuaalinen testaus, jolla varmistetaan, ettei tuotantoon julkaistaessa ole syntynyt regressioita. Kokemukseni mukaan se on yksi minkä tahansa projektin suurimmista pullonkauloista, mutta erityisesti silloin, kun projektissa on useampi kuin yksi tiimi.

Varo ennenaikaista skaalausta

Skaalautuvuus on startup-yritysten ja sarjayrittäjien keskeisiä huolenaiheita – ja heillä on meille opittavaa ennenaikaisesta skaalauksesta.

Jos ryhdyt skaalaamaan ennen kuin olet todella täyttänyt liiketoiminnan, tiimin tai organisaation onnistuneen skaalauksen edellytykset, saat tulokseksi sen, mitä startup-yhteisö kutsuu ”ennenaikaiseksi skaalaukseksi”.

Sarjayrittäjä Jim Pitkow määrittelee ennenaikaisen skaalauksen yksinkertaisesti näin:

Ennenaikainen skaalaus: kasvu kysynnän ennakoinnin perusteella kysyntälähtöisen kasvun sijaan.

Skaalaaminen viekin aikaa, ja todellista skaalautuvuutta ohjaa aito skaalauksen tarve, joka perustuu kysyntään, ei keinotekoisesti asetettuun tavoitteeseen vain kasvaa suuremmaksi ja tehdä asioita nopeammin.

Startup-yhteisö tarjoaa meille muutaman opetuksen, jotka voimme ottaa mukaan tiimeihimme ja projekteihimme pohtiessamme, onko aika skaalata. Tässä muutamia tilastotietoja raportista Startup Genome -raportin lisäraportti ennenaikaisesta skaalauksesta:

• Asianmukaisesti skaalautuvilta startup-yrityksiltä kuluu 76 % enemmän aikaa tiimikokonsa kasvattamiseen kuin ennenaikaisesti skaalaavilta startup-yrityksiltä.
• 74 % nopeasti kasvavista internet-startup-yrityksistä epäonnistuu ennenaikaisen skaalauksen vuoksi.
• Asianmukaisesti skaalautuvat startup-yritykset kasvavat noin 20 kertaa nopeammin kuin ennenaikaisesti skaalaavat startup-yritykset.

Jos yrittäjyydestä kertovat lisätilastot kiinnostavat, tutustu tutkimukseemme Yhdysvaltojen yrittäjähenkisimmistä osavaltioista.

Oletko todella valmis skaalaamaan?

Jos projektiasi johdetaan hyvin ja se täyttää edellä mainitut edellytykset, seuraava kysymyksesi pitäisi olla:

”Kuinka moni tiimi voi osallistua tuottavasti?”

Vastaamme tähän seuraavassa osiossa.

Mikä on skaalautuvuuden raja? Brooksin ja Amdahlin lait

On hyvin tunnettu tosiasia, että ihmisten lisääminen ohjelmistoprojektiin ei välttämättä lisää tuottavuutta.

Itse asiassa useimmissa tapauksissa uusien ihmisten lisääminen aiheuttaa tuottavuuden huomattavan laskun.

Fred Brooks teki tämän havainnon Myyttinen henkilökuukausi -teoksessaan, ja se tunnetaan nykyään Brooksin lakina:

”Henkilöstön lisääminen myöhässä olevaan ohjelmistoprojektiin myöhästyttää sitä entisestään […] Projektin kuukausien määrä riippuu sen peräkkäisistä rajoitteista. Miesten enimmäismäärä riippuu toisistaan riippumattomien alitehtävien määrästä. Näiden kahden suureen perusteella voidaan laatia aikatauluja, joissa on vähemmän miehiä ja enemmän kuukausia[…]. Toimivia aikatauluja ei kuitenkaan voi saada käyttämällä enemmän miehiä ja vähemmän kuukausia.”

Edellä olevan lainauksen jälkimmäinen puolisko on mielestäni kiinnostavin. Se on nimittäin pohjimmiltaan Amdahlin lain selkokielinen versio – kyseessä on kaava, joka antaa samanaikaisen järjestelmän suurimman teoreettisen nopeutuksen:

Amdahlin laki

Nopeutus = 1 / (s + p / n )

Missä:

s = sarjamuotoisten tehtävien prosenttiosuus

p = rinnakkaisten tehtävien prosenttiosuus

s + p = 1

n = prosessorien määrä (meidän tapauksessamme tiimien määrä)

Useita tiimejä sisältävä projekti on itse asiassa eräänlainen samanaikainen järjestelmä, jossa jokainen tiimi toimii käsittely-yksikkönä. Käytännössä Amdahlin laki tarkoittaa, että samanaikaisesti tehtävän työn enimmäismäärää rajoittaa tehtävän sarjamuotoisen työn määrä.

Yksinkertaisesti sanottuna tämä tarkoittaa, että tietyssä järjestyksessä tehtävät asiat rajoittavat sitä, kuinka paljon tehtäviä tiimit voivat työstää samanaikaisesti.

Mitä sarjamuotoinen työ tarkoittaa ohjelmistokehityksen yhteydessä?

Saatat pohtia, millainen työ vaikuttaa ohjelmistotiimeihin sarjamuotoisena työnä.

Tässä on muutama esimerkki (olen varma, että keksit monia muitakin):

• Kaikki integrointi- ja käyttöönottoputkiin liittyvä työ
• Eri tiimien jakamassa koodissa tehtyjen ohjelmistomuutosten yhdistäminen
• Kaikenlainen synkronointi – esimerkiksi tilanne, jossa tiimi on riippuvainen toisen tiimin toimituksista ennen työnsä jatkamista
• Resurssien käyttöönoton odottaminen

Amdahlin lain soveltaminen tiimien skaalaamiseen

Alla oleva kaavio näyttää Amdahlin lain vaikutukset, kun tiimien määrää kasvatetaan tuottavuuden näkökulmasta.

Voimme nähdä, että tuottavuus kasvaa alilineaarisesti tiimien määrän kasvaessa – tiettyyn huippuun asti, minkä jälkeen se alkaa jälleen laskea.

Kuva Amdahlin laista: toimitusten läpimeno kasvaa tiimien määrän kasvaessa, mutta vain tiettyyn pisteeseen asti – eikä tämä yleensä ole sitä, mitä johtajat toivovat.

Jos muistat tästä artikkelista vain yhden asian, muista tämä:

Tiimien määrän lisääminen voi kasvattaa läpimenoa, mutta vain tiettyyn pisteeseen asti.

Mikä siis on tietyn projektin ihanteellinen tiimien määrä?

Valitettavasti ei ole olemassa yhtälöitä, joiden avulla tietyn projektin ihanteellinen tiimien määrä voitaisiin laskea etukäteen. Ainoa tapa on käyttää projektin mittareita esimerkiksi tuottavuuden ja laadun mittaamiseen sekä seurata, mitä tapahtuu, kun tiimejä lisätään tai vähennetään. Suosittelen aloittamaan pienestä, yhdellä 3–6 hengen tiimillä, ja kasvattamaan määrää vain silloin ja siinä tapauksessa, kun se on tarpeen.

Jossain vaiheessa saatat huomata, että olet jo saavuttanut tiimien enimmäismäärän, mutta projektisi ei silti pysty täyttämään sitoumuksiaan. Silloin priorisointi- ja viestintätaitosi tulevat tarpeeseen, sillä saatat joutua käymään vaikeita keskusteluja asiakkaidesi kanssa.

Tiimirakenteeseen liittyviä huomioita: ominaisuus- vai komponenttitiimit?

Kun projektiin lisätään uusi tiimi, miten sen pitäisi työskennellä? Aloita esittämällä itsellesi nämä kaksi kysymystä:

1. Vastaavatko he asiakkaille näkyvien ominaisuuksien kehittämisestä alusta loppuun vai saavuttavatko he tavoitteensa muuttamalla jotakin järjestelmässä?
2. Vastaavatko he tietyn komponentin parissa työskentelystä siten, että se tarjoaa osan käyttäjille näkyvästä toiminnallisuudesta?

Jos vastasit kohtaan 1 kyllä, tiimi on ominaisuustiimi.

Jos vastasit kohtaan 2 kyllä, tiimi on komponenttitiimi.

Vinkkejä oikean tiimirakenteen valintaan

Sopivan tiimirakenteen ja tiimiorganisaation valitseminen on erittäin tärkeää, mutta se ei ole helppoa. Tällä hetkellä ominaisuustiimit vaikuttavat olevan useimmissa tilanteissa ensisijainen vaihtoehto. Tämä valinta perustuu kuitenkin usein tottumukseen tai rutiiniin datan sijaan.

Todellisuudessa “se riippuu”. Tarkemmin sanottuna se riippuu järjestelmän arkkitehtuurista. Ohjelmistoprojekteissa noudatetaan usein niin sanottua Conwayn lakia—Mel Conwayn empiiristä havaintoa:

“Organisaatiot, jotka suunnittelevat järjestelmiä… joutuvat tuottamaan suunnitelmia, jotka ovat kopioita näiden organisaatioiden viestintärakenteista”

Toisin sanoen tiimirakenteen “muodon” on vastattava järjestelmän “muotoa”, tai projekti kohtaa vakavia ongelmia.

Siksi suosittelen aina, että esihenkilöt ottavat kokeneet arkkitehdit ja tekniset vetäjät mukaan tiimirakennetta koskeviin päätöksiin—muuten esihenkilöt käytännössä suunnittelevat järjestelmää tiedostamatta sitä itse (ja ilman tarvittavaa osaamista). Tämä puolestaan voi kasvattaa merkittävästi projektin epäonnistumisen riskiä.

Skaalautuvuuden kaksi paradoksia

Toimiessani konsulttina useissa suurissa projekteissa olen tullut siihen tulokseen, että useimmissa tapauksissa projektien skaalaamista tehdään vääristä syistä.

Olen keksinyt kaksi paradoksia, jotka tiivistävät käytännössä tekemäni havainnot:

Skaalaamisen ensimmäinen paradoksi

Useimpia projekteja kasvatetaan, koska ne eivät täytä skaalaamisen edellytyksiä

Skaalaamisen toinen paradoksi

Skaalaamisen edellytykset täyttävillä projekteilla on vähäisempi tarve skaalautua

Ensimmäinen paradoksi tarkoittaa, että useimmissa tilanteissa projektit etenevät hitaasti yksinkertaisesti siksi, että niitä ei johdeta hyvin.

Toinen paradoksi tarkoittaa, että hyvin johdetuilla projekteilla on vähemmän tarvetta skaalautua yksinkertaisesti siksi, että niitä johdetaan hyvin.

Itse asiassa tuottavimmissa projekteissa, joita olen nähnyt, oli vain yksi tai kaksi pientä tiimiä, ja ne täyttivät kaikki skaalaamisen edellytykset. Kaikista suurista projekteista, joissa olen ollut mukana, en ole nähnyt yhtäkään, jossa kaikki skaalaamisen edellytykset olisivat täyttyneet. Itse asiassa kaikilla niillä oli runsaasti vaikeuksia täyttää edes yhtä edellytyksistä.

Jos olet mukana projektissa, jossa esiintyy ongelmia ja viivästyksiä, paras suositus, jonka voin antaa, on supistaa sotkua ennen kuin harkitset projektin kasvattamista.

Keskeiset opit tiimien oikeaoppiseen skaalaamiseen

Ohjelmistotiimien skaalaaminen ei ole helppoa, ja se on tehtävä erittäin huolellisesti. Ennen kuin lopetat, tässä vielä muutama ajatus tehokkaimman tavan löytämisestä ohjelmistokehitystiimin skaalaamiseen:

1. Jos keskityt täyttämään skaalautuvuuden edellytykset, saatat huomata, että voit pitää tiimin pienenä ja välttää kaikki suurempaan kokoon liittyvät ongelmat.
2. Jos projektisi on puolestaan jo suuri ja vaikeuksissa, keskity ensin sotkun pienentämiseen.

Tässä ovat ensimmäiset vaiheet, jotka suosittelen ottamaan tämän artikkelin lukemisen jälkeen:

1. Selvitä, mitä käytännössä tapahtuu
2. Ota käyttöön mittareita, joiden avulla voit arvioida nykytilannetta sekä tehtyjen päätösten laatua.