keskiviikko 27. kesäkuuta 2012

Fred Brooks - The Mythical Man-Month


The Mythical Man-Monthia suositeltiin minulle jo paljon aiemmin, mutta nyt Kindlen ansiosta sai lopulta tämänkin luettavaksi. Kyseessä on tietotyön ja it-projektien johtamisen klassikkoteos, jostain ajalta ennen lerppuasemia. Käsittämättömän hyvin säilyttänyt kyllä teränsä, vaikka maailma ympärillä onkin aivan toisen näköinen ja kirjassa esitellyt aikanaan varmasti merkittävät projektit alkavat olla jo niin retroa, että niistä ei nykypäivän ihminen pelkällä yleissivistyksellä ole kuullut yhtään mitään.Itse sisältö on silti yhä totaalista rautaa. Jotain oleellista on Fred Brooks haastavan tieto- ja projektityön olemuksesta löytänyt. Mukana on sekä fiksua ajattelua yleisesti, että varsin konkreettisia täkyjä ja nyrkkisääntöjä, jotka kannattaa pitää mielessä.

Ehkä yksi selvimmin esiintuotu ongelma it-projekteissa on aikataulujen venyminen. Sitä vain ilmeisesti tapahtuu aina, it-projektien luonteesta johtuen. Lisäksi venymiseen tupataan reagoimaan luonnollisella ja yleensä täysin väärällä tavalla: lisäämällä työvoimaa. Työvoiman lisääminen on käytännössä aina huono idea, koska useimmiten se hidastaa projektin valmistumista vain lisää. Monimutkaisen tietotyön saa monimutkaisemmaksi vain lisäämällä liikkuvia osia ja tarvittavan kommunikaation ja perehdytyksen määrää, mitä ihmisten lisääminen tietenkin aiheuttaa. Jos projektin tarkoituksena on maalata aita tai siirtää soraa kottikärryillä paikasta toiseen, niin lisätyövoima on paljon suoremmin oikeasti lisää työvoimaa. IT-projektissa lisätyövoima taas vaatii itsessään todella paljon työtä, ennen kuin se voi alkaa toimia projektia edistävästi. Sitä ennen se ainoastaan hidastaa ja estää alkuperäistä tiimiä tekemästä varsinaisia töitä, kun heidän pitää perehdyttää ja pohtia monimutkaisempaa ryhmädynamiikkaa ja uusia tapoja viestiä asioista.

IT-projektit ovat pitkiä ja venyvät, mutta se on vain hyväksyttävä. Tästä Brooksilla on todella lohdullinen ja hieno sitaatti: Paperitiikeri voittaa aina oikean tiikerin, paitsi milloin kysytään konkretiaa. Siinä vaiheessa kun oma projekti on valmis, on tekniikka kehittynyt ja kilpailijoilla on kehitteillä ainakin seitsemän kertaa parempi ja kehittyneempi tuote. Toisaalta jos asiakas haluaa tehdä taulukkolaskentaa nyt, eikä yhdeksän kuukauden kuluttua, niin silloin olemassaoleva tuote on loputtomasti paljon parempi vaihtoehto, kuin yksikään suuri lupaus.

Yksi varmasti käyttökelpoinen idea kirjassa on järjestää ohjelmointitiimi kirurgisen tiimiin mallin mukaan. Yhtään suurempi tiimi vain kompastuu jalkoihinsa, jos kaikki puuhaavat mitä sattuu kukin omalla tahollaan, ilman kristallinkirkasta päämäärää. Tämän vuoksi Brooks ehdottaa, että kullekin projektille luodaan selvä työnjako avustaviin tehtäviin ja varsinaiseen toteuttamiseen. Yksi toimii kirurgina/pääohjelmoijana, muut komppaavat ja tekevät hänen työstään mahdollisimman helppoa ja tehokasta.

Lisäksi yksi tapa järjestää projekti, on määritellä sille erikseen tuottaja ja arkkitehti. Arkkitehdin tehtävänä on suunnitella koko projektin päämäärä: millainen ohjelma, mitä ominaisuuksia otetaan mukaan, mitä jätetään ulos. Hän voi antaa vinkkejä käytännön toteuttamistavoista, mutta sitä puolta varten on sitten olemassa käytännön tiimi. Arkkitehti kertoo mitä tehdään ja pitää vision kirkkaana ja virtaviivaisena. Brooks on kovasti sitä mieltä, että komiteat eivät veny kuin parhaimmillaankin kuin ihan hyviin suorituksiin. Jos halutaan oikeasti poikkeuksellisen hyvä tuote, niin silloin sen takana on käytännössä oltava yksi ihminen. Arkkitehti on projektissa se ihminen, joka sen kristallinkirkkaan vision luo.

Tuottaja taas on komppipuolen ihminen. Hän mahdollistaa itse projektin onnistumisen. Projektipäälliköstä voisi myös puhua. Tuottaja pitää kiinni deadlineistä, valvoo työn etenemistä, raportoi ympäriinsä ja tukee projektitiimiä kaikin mahdollisin ja tarpeellisin tavoin, että he voivat tehdä parasta mahdollista työtä. Hyvä rooli olla olemassa, ettei esim. arkkitehdin tarvitse miettiä sitä, tappelevatko takarivin koodarit keskenään ja onko läppäristä laturi hukassa ja sen takia koko projekti seisoo, koska hän voi luottaa tuottajan hoitavan tuon puolen. Brooks suosittelee, että jopa neljän hengen projektitiimit valitsevat itselleen arkkitehdin ja tuottajan. Niinkin pienellä porukalla roolijako selkeyttää tilannetta ja virtaviivaistaa toimintaa merkittävästi.

Kristallinkirkkaasta visiosta Brooks kirjoittaa myös paljon. Ohjelmassa tärkeintä lopulta on se, onko se virtaviivainen, looginen ja elegantti kokonaisuus. Parhainkin mahdollinen ominaisuus on ihan yhtä tyhjän kanssa, jos se on täysin väärässä ohjelmassa väärässä paikassa. Esimerkiksi kuvankäsittelyohjelma, jossa yhtäkkiä on ominaisuus nauhoittaa ääntä, koska joku koodari nyt on vain epähuomiossa tehnyt ihan todella hyvän äänityskilkkeen, eikä siitä ole hennottu luopua. Äänitysominaisuus on kuvankäsittelyohjelmassa täysin turha, mutta lisäksi se tekee koko paketista sekavamman ja hukkaa resursseja, jotka olisi ohjelmointivaiheessa voinut käyttää johonkin oleelliseen. Hyväkin ominaisuus voi huonontaa tuotetta, jos se on väärässä tuotteessa ja väärässä paikassa. Yhden ihmisen takana oleva yhtenäinen näkemys tuotteesta ehkäisee tällaista rönsyilyä.

Edellinen on yksi esimerkki siitä, miten The Mythical Man-Month käsittelee IT-projekteja, mutta itse asia on täysin sovellettavissa ja ihan yhtä olleellinen melkein millä tahansa sektorilla. Vrt. sairaala, joka alkaisi järjestää vaellusretkiä, koska joku johtava lääkäri nyt vain on innostunut vaeltamisesta.

Työmäärän arvioiminen: Kirjasta löytyy hyvä pointti projektiin tarvittavan työmäärän arvioinnista. Vaikka arvio olisi kuinka muuten tarkka, niin kannattaa pitää mielessä, että projektin aikana jokainen miestyötunti ei ole tehokas miestyötunti. Lepotauotkin on vielä helppo laskea mukaan työtehoon, mutta miten otettaisiin lukuun tällaiset "toisesta ryhmästä on yksi jätkä pois ja nyt me pyöritellään peukaloita puolitoista päivää täällä" -ongelmat, kun kyseessä on kuitenkin todella verkottautuneet ja riippuvuussuhteiltaan vahvat ja monimutkaiset projektit? Käytännön tasolla ratkaistava ongelma, mutta hyvä pitää mielessä.

Projektijohtajan tehtävä: luoda suunnitelma ja toteuttaa se. Kaikessa yksinkertaisuudessaan. Hyvänä pointtina, että sen suunnitelman on oltava kirjallinen. Vaikka suunnitelma olisi mitenkä saakelin täydellinen ikinä, niin jollei projektitiimi tiedä siitä mitään, niin siitä ei ole mitään hyötyä. Mitä, milloin, kuinka paljon, missä, miten, jne. Kaikkiin kysymyksiin linjattuna jotain, joka toteuttaa suunnitelmaa parhaalla mahdollisella tavalla.

Tähän liittyvät projektin rajapyykit. Kun on yhtään pidempi projekti kyseessä, välitarkastuspisteet vain on luotava: milloin pitää olla valmiina ja mitä. Mahdollisimman mitattavia ja yksiselitteisiä mittareita: Toimiiko ohjelma? Onko manuaali kokonaan valmis? Onko grafiikka 50% tehty? Asioita, joihin voi vastata kyllä tai ei. Helpottaa kaikkien tuskaa, varsinkin mitä laadullisemmasta projektista on kyse. Varsin yleistettävissä myös muihin kuin IT-projekteihin, mutta rajapyykkien keksiminen esim. palveluita kehitettäessä voi  olla jopa vielä vähän jännittävämpi tehtävä.

Pilottisysteemi: Tästä tuntuisi löytyvän kirjallisuudessa aika hyvä konsensus. Pilottisysteemi on vain tehtävä, koska muuten tekee pilottisysteemin, mutta kutsuu sitä oikeaksi systeemiksi ja yrittää myydä sen asiakkaalle. Pilotissa on mahdollista saada halvalla kiinni räikeät virheet ja törmätä projektinsa kanssa konkretiaan, joka kuitenkin on se ainut ja paras tapa testata homman toimivuutta. Tämäkin ohje täysin yleistettävissä mihin tahansa muuhunkin projektiin, kuin IT-puolelle. Jos vain mitenkään mahdollista, testaa hommaa ensin pienemmässä mittakaavassa, koska suunnittelypöydällä kaikkia asioita ei vain määritelmällisesti pysty ottamaan huomioon.

Johtajuus: The Mythical Man-Monthista löytyy ihan rautaista asiaa johtajuudestakin. Johtajan rooli verrattuna esim. projektipäällikköön. Ratkaisuksi tarjotaan rooleja: kun johtaja tekee tarkistusta, niin silloin tarkistetaan tilanne. Kun johtaja puuttuu suoraan esimiehenä asioihin, niin hän puuttuu suoraan asioihin. Jos nämä kaksi menevät sekaisin, niin sen jälkeen luottamus alkaa rapautua ja johtaja ei enää saa luotettavaa tietoa. Esimerkkinä kerrotaan pomosta, joka statuspäivityksen toisen lauseen aikana jo tarttui puhelimeen alkaakseen pistää asioita kuntoon. Jossain vaiheessa tällaiselle pomolle ei sitten enää kerrota mitään rehellistä, ettei hän aina lähde marssimaan kaikkien muiden varpaille ja tonteille.

Hämmentävän kaappaava, viihdyttävä ja jännittävä teos. Paljon muutakin nostettavaa kirjasta oli löydettävissä, mutta nämä osuivat nyt omaan tilanteeseen parhaiten ja vaikuttivat voimakkaimmilta teeseiltä. Aivan silkkaa rautaa kyllä tämä opus. Voi suositella varauksetta aivan kenelle tahansa, joka voi joskus joutua pyörittämään tai osallistumaan mihinkään yli yhden hengen projektiin jollain koulutusta ja/tai luovuutta vaativalla alalla. Vaikka kirja kertoo IT-alasta, niin annettavaa piisaa ihan hämmentävän universaalisti. Hieno aloitus tälle blogille. Tästä on mukava jatkaa.


2 kommenttia:

  1. Muotoilut olivat aluksi jotenkin hämmentävän rikki. En tiedä mistä johtui. Epäilyksenä, että kirjoitin osan tekstistä ensin kännykän blogger-applikaatiolla. Oli kyllä muutenkin jotenkin niin härskin huonoja noi androidille tarjolla olevat blogger-apit, että eipä tarvitse siihen erheeseen enää ruveta toiste.

    VastaaPoista
  2. Toi on joo hiljaiseksi vetävä kirja. Mielenkiintoista miten aikaansa edellä Brooks oli.

    Joskus kymmenen tms vuotta sitten Extreme Programming oli, nimensä veroisesti, todella extremeä kamaa. Ohjelmoidaan pareissa, tehdään nopeita iteraatioita, prototyypataan.

    Brookshan pohjustaa kaikkea tuota.

    Sitten näyttämölle astuu päivän agiilit, ketterät, menetelmät,
    jotka ovat käytännössä vain XP, mutta hieman eri paketissa.

    Yleinen menetelmä on Scrum, josta on niin paljon kirjoja, että tämä ilmeisesti alkuperäinen kirja meinasi jäädä löytymättä.

    http://www.amazon.com/Agile-Software-Development-Scrum-Series/dp/0130676349

    Vaikka pointit edelleen pätevät ja menetelmä toimii, niin se ei ota kantaa mitenkään tiimin sisäiseen työskentelyyn. Nimittää toki roolin asiakkaan suuntaan ja eräänlaisen projektipäällikön, mutta ei sen enempää. Kovin ikävää, kun tiimin toiminta on tärkeää, eikä
    startup-piireissäkään aina tajuta sen tärkeyttä.

    Joskus väitetään, että ihmisten pitää mennä pois
    turvallisuusalueeltaan oppimaan uusia asioita, mutta
    kun lähtökohtaisesti on palkattu profiileja täydentämään
    toisiaan, niin harvoin on varaa moiseen tehottomuuteen.

    Scrum-kirjassa paistaa myös läpi sellainen tietty
    skientologinen arroganssi. "Meidän menetelmämme nyt vaan
    on paras ja siitä voi toki poiketa, mutta vasta kun on
    varma mitä tekee. PS. tiimi organisoi itsensä emmekä
    kehota lukemaan Brooksia tai mitään muutakaan sit
    kun se menee reisille. PPS. Maksakaa kursseistamme."

    Tuota samaa on käsittääkseni Kanbanissa, joka on Toyotan
    autotehtailla kehitetty prosessi, jota sovelletaan myös
    IT:hen ja vaikka mihin. Todella tiukka setti sääntöjä
    tuotantoon, mutta ei oikeastaan mitään siitä itse
    tuotannosta.

    Brooks ottaa (muistaakseni) paljon leppoisamman, jos
    ei jopa nöyremmän, lähestymisen. Hienointa on se, että
    ne periaatteet, joita MMM:ssä kuvaillaan, on käytännössä
    prosessiriippumattomia.

    Pakollista luettavaa minkä tahansa prosessioppaan kyljelle.

    Tai vaikka juontaisi agiilien menetelmien hyvät puolet itse tän pohjalta.

    VastaaPoista