Modulaarista projektimallia voidaan verrata Lego-rakentamiseen. Samoja moduuleja voidaan käyttää useisiin eri tarkoituksiin. Tuolloin projektin työntekijöiden vastuualue muuttuu kapeammaksi, joten he voivat syventyä tarkemmin kapeamman sektorin osa-alueeseen, mikä toivon mukaan lisää tehokkuutta. Mutta samalla se muuttaa työn yksipuolisemmaksi sekä erottaa projektin osa-alueita toisistaan.
Varsinkin ohjelmointityössä ns. agile malli on tällä hetkellä suurinta, mitä projektinhallinnan saralla on tehty. Yhtiöt ostavat kilpaa agile-kursseja, jossa tuota mallia opetetaan suurelle joukolle ihmisiä, joiden pitää johtaa projekteja. Usein unohdetaan että mikään teoriassa opetettu malli ei ole sellainen, että se suoraan sopii käytännön elämään. Kun agile mallia siirretään teoriasta käytäntöön, niin esimerkiksi palaverien väli pitää suhteuttaa tarpeeseen. Ja noiden palaverien avulla pitäisi myös kerätä oikeaa tietoa projektin tilasta, eikä vain sitä mitä johtaja haluaa milloinkin kuulla.
Palaverien tarkoitus ei ole se, että niitä pidetään niiden itsensä takia. Palaverit pidetään siksi, että projekteissa olevat epäkohdat tai ongelmat tulevat esiin. Palaverien tarve korostuu silloin, jos projektissa on ongelmia. Ja jos projekti sujuu kuten pitäisi, niin silloin palavereille ei ole niin suurta tarvetta. Mutta miten saadaan ihmiset kertomaan se, että projektissa on ongelmia?
Ja ongelmat voidaan ratkaista vain, jos ne ovat sellaisten ihmisten tiedossa, jotka voivat niitä ratkoa. Jos ongelma kuten se, että joku ei osaa työtään ei tule esimiesten tietoon, niin silloin ongelmaan ei voida puuttua. Tietenkin ongelmaan puuttujalla pitää olla sellaiset valtuudet, että hän voi joko erottaa pätemättömän työntekijän tai siirtää hänet toisiin tehtäviin.
Agile tai ns. "Ketterä" kehitysmalli perustuu ajatukseen, että projektin johto kerää jatkuvasti palautetta siitä, mitä alaiset tekevät. Ja usein puhutaan siitä, että kyseinen malli tappaa vähintään luovuuden, lisää stressiä sekä muuttaa projektiryhmien osaamista kapea-alaisemmaksi. Tuo viimeinen asia johtuu siitä, että agile-mallissa projektiryhmän osaset ikään kuin erotetaan toisistaan soluiksi. Tuolloin jokainen solu työskentelee vain yksittäisen projektin osasen tai moduulin parissa. Ja tätä mallia perustellaan sillä, että näin ei ohjelmoijien tai muiden projektityöhön osallistuvien tarvitse osata kaikkea. Riittää että he osaavat oman kapean erikoisalansa, ja sen he sitten osaavat hyvin. Se aiheuttaa tietenkin työn yksipuolistumista sekä lisää omalla tavallaan stressiä.
Mutta miten sitten tuo oma kapea sektorinen moduuli saadaan liitettyä yhteen muiden kapea-alaisten moduulien kanssa, niin että ne muodostavat dynaamisen kokonaisuuden. Eli periaatteessa agile-malli on sellainen, että siinä käyttöliittymien tekijät työskentelevät ilman yhteydenpitoa muihin projektin osa-alueiden kanssa työskenteleviin henkilöihin. Tuolloin esimerkiksi tietokannat ja muut vastaavat asiat kuten käyttöliittymien yhdistäminen tietokantoihin tehdään kaikki erikseen, ja sitten tietenkin tuo tuo syvällisyyttä, mutta samalla myös yksipuolisuutta projektiin.
Kuitenkin olisi hyvä tehdä ainakin kerran projektin puolivälin paikkeilla sellainen palaveri, jossa kaikki projektin osa-alueet tai projektitiimit voivat yhdessä pohtia sitä, miten kokonaisuus saadaan toimimaan tehokkaasti sekä näyttämään hyvältä.
Modulaarisen agile-mallin avulla voidaan luoda erilaisia moduuleja, joita sitten liitetään uusiin projekteihin. Sen takia näitä malleja kutsutaan joskus Lego-projekteiksi. Nuo moduulit ovat ikään kuin Lego-palikoita, joita voidaan liittää toisiinsa useilla eri tavoilla. Idea on se, että esimerkiksi tietokantoja ei tarvitse tehdä erikseen jokaista projektia varten, vaan se riittää, että tietokantojen nimet muutetaan, ja ne asennetaan erinimisiin kansioihin. Tuolloin riittää, että tietokantojen polkujen osoitteet vaihdetaan, mutta se mitä, tällainen tekee tietoturvalle on asia, josta voidaan keskustella.
Joskus tätä mallia verrataan tilanteeseen, jossa auton moottori, jarrut sekä runko suunnitellaan erikseen. Siis kun esimerkiksi ohjelmistoja tehdään, niin silloin käyttöliittymän pitäisi toimia tehokkaasti sekä luotettavasti yhdessä kokonaisuuden kanssa. Tietoturva on nykyään jokaisen huulilla oleva asia, ja se pitäisi integroida jokaiseen tuotteeseen, eli se ei saa olla mikään erillinen, kaikesta irrallaan oleva abstraktio. Agile malli voi olla erittäin hyvä ja tehokas tapa hallita projekteja. Sen takia tuon asian tiimoilta pidetään erittäin paljon koulutuksia.
Mutta jos agile mallia toteutetaan väärin, niin siitä tulee valtava stressitekijä. Siis jos agile mallia viedään käytäntöön, niin silloin pitäisi muistaa se, että palavereja ei pidetä niiden itsensä takia. Samoin palavereissa alaisten pitäisi uskaltaa tuoda esiin myös se, jos työ ei onnistu. Joten olisi ehkä hyvä kysyä kaikilta erikseen esimerkiksi ryhmäsähköpostin tai pikaviestimen välityksellä, että onko heillä jotain ilmoitettavaa? Ja samalla pitäisi esimiehen myös käväistä katsomassa, miten työ oikeasti edistyy. Nimitäin ongelma on siinä, että esimiehille kerrotaan paljon sellaista, mitä alaiset luulevat heidän haluavan kuulla.
Ja esimerkiksi oman epäonnistumisen myöntäminen on asia, mistä on työelämässä tehty jotenkin noloa. Sen takia joissakin yhtiöissä on sellainen ilmapiiri tai asenne, että omaa osaamattomuutta salaillaan loppuun asti, koska alainen pelkää saavansa potkut.
https://www.tivi.fi/uutiset/tietoturvalegenda-tylyttaa-agile-menetelmia-tuhoavat-innovaatiot/d27d8cff-64e7-4777-afce-34ba0ef7360b
Ei kommentteja:
Lähetä kommentti
Huomaa: vain tämän blogin jäsen voi lisätä kommentin.