Prosessi

Prosessi tai tuttavallisemmin “The Process” on Scrumin pohjalta kehittämämme ketterä toimintamalli.

Olemme huomanneet sen, että vaikka tavoitteena olisikin projektien toteuttaminen ketterästi, niin tavoiteltuun lopputulokseen päästiin ainoastaan harvoin.

Epäonnistumiseen johtaneet syyt vaihtelivat, mutta usein vastaan tuli tilanne, jossa projektia veti liian kokematon henkilö.

 

Prosessimme kolme periaatetta

1.

Maksumme perustuvat tehtäväpohjaisiin maksuihin. Emme käytä tuntihintoja, emmekä kiinteitä kuukausipalkkoja.

2.

Kaikesta projektiviestinnästä jää jälki. Koko kehitystiimi pysyy hyvin perillä työn etenemisestä. Kehitystyö on läpinäkyvää.

3.

Projektipäällikkö on vastuussa kaikesta – hän huolehtii, että kokonaisuus on teknisesti, aikataulullisesti ja kustannuksiltaan sovitunlainen.

The process tarjoaa vaihtoehdon tunteihin perustuvalle hinnoittelulle

Ohjelmistorobotiikan sekä nykyaikaisten käytäntöjen, kuten testiautomaation, CI/CD-putken ja DevOps:in avulla, olemme luoneet uuden tavan toteuttaa ohjelmistoprojekteja. Meillä ohjelmistorobotit huolehtivat kehitystehtävien hallinnasta, jolloin projektipäällikölle jää aikaa tehdä arvoa luovaa työtä.

Älykkäät robotit mahdollistavat tehtävien pilkkomisen “mikrotaskeiksi”, mikä luo asiakkaalle läpinäkyvyyttä, selkeyttää kehittäjän työtä ja luo pohjan tehtäväperusteiselle palkanmaksulle. Robotit kykenevät myös avaamaan uusia tehtäviä ja osoittavat tehtävän sopiville ohjelmistokehittäjille.

Jotta projekti onnistuu, projektipäällikön rooli on aivan välttämätön. Tehokas projektin läpivienti vaatii kokonaisuudesta vastaavan ammattilaisen, joka on aina Devolutionin palveluksessa. Projektipäällikkö tekee keskeiset hankkeeseen liittyvät päätökset ja ohjaa tiimiä.

Toisin kuin tavallisissa kehitysmalleissa, Devolutionin prosessissa kehittäjille on mahdollista maksaa palkka myös suoritettujen tehtävien mukaan. Erityisesti kokemattomien kehittäjien osalta, tämä on erinomainen tapa päästä mukaan oikeisiin asiakasprojekteihin.

Käytännössä homma toimii niin, että projektipäällikkö kuvaa loppukäyttäjän käyttötilanteen ja luo sen pohjalta osiin puretut tehtävät. Projektipäällikkö valitsee tehtäville tarvittavat osaamiskyltit, joiden perusteella ohjelmistorobotti jakaa tehtävät niiden toteuttajille. Toteuttaja luo pienimmän mahdollisen edistysaskeleen kohti toteutettavaa ominaisuutta.

Kehittäjät saavat palkkansa toteuttamalla tehtäviä, avaamalla uusia tehtäviä, löytämällä virheitä sekä pyytämällä selkeytystä annettuihin tehtäviin. Lisäksi hän merkkaa seuraavat askeleet TO DO-lipuilla. TO DO -lipuista ohjelmistorobotti puolestaan luo seuraavat tehtävät, jotka menevät projektipäällikölle tarkistettavaksi. Projektipäällikkö voi halutessaan tehdä muutoksia tehtävään ja tarkentaa tehtävän kuvausta.

Kehittäjä saa palkkionsa, kun hänen koodinsa hyväksytään versionhallinnan master-haaraan. Olemme vieneet hyväksyntäkriteerit korkealle, mutta toisaalta olemme kirjanneet ne ylös kaikkien nähtäville taataksemme kehittäjien turvan sekä edistääksemme asiakkaidemme luottamusta.

Meillä kehittäjän ei tarvitse arvailla, mitä hän on tekemässä. Epäselvissä tapauksissa kehittäjä voi pyytää lisäselvitystä projektipäälliköltä. Vaikka projektipäälliköllä on kaikki valta, on hän myös velvoitettu perustelemaan ratkaisut ja kommunikoimaan näistä. Toinen periaatteemme sanoo, että projektikommunikointi on oltava jäljitettävissä.

Ketterä kehitys on yhteistyötä. Ohjelmistoja tehdään ja kehitetään yleensä tiimeissä, joten kommunikaatio on ensiarvoisen tärkeää. Devolutionin mallissa kaikki projektikommunikaatio pitää olla näkyvissä. Informaatiokatkokset ovat yksi suurimpia syitä hukkaan ja epäonnistuneisiin projekteihin. Devolutionissa käytämme projektikommunikaatioon projektinhallintatyökalujamme. Pääsääntöisesti käytämme GitHubia projektinhallintaamme.

Koska projektipäällikkö on velvoitettu perustelemaan päätökset, hän pitää huolta, että kaikki ohjelmistoon liittyvä kommunikointi on helposti saatavilla ja löydettävissä. Agile-periaatteiden mukaan emme halua käyttää aikaamme dokumentteihin, joita kukaan ei koskaan lue, sen sijaan olemme integroineet viestinnän osaksi kehitysprosessiamme.

Ohjelmiston dokumentointiin käytämme automaattitestiä, arkkitehtuuriratkaisujen taustat löytyvät tehtäväkuvauksista sekä projektin wikisivulta. Vastatessaan asiakkaiden ja kehittäjien kysymyksiin, projektipäällikön on viitattava projektin dokumentaatioon. Jos dokumentaatiota ei ole, projektipäällikkö luo sen.

Usein on tarpeen, etenkin asiakaskommunikoinnissa, selventää asioita myös kasvotusten, puhelimella tai pikaviestintäalustoilla. Tällöin on vaarana, että luotu informaatio hukkuu. Sääntömme määrää tekemään tiivistelmän käydyistä keskusteluista projektinhallintatyökaluun. Ollaksemme täysin läpinäkyviä, myös asiakkaalla on pääsy projektinhallintatyökaluihimme.

Prosessimme rakentuu projektipäällikön ympärille. Hän vastaa siitä, että projekti noudattaa Devolution Oy:n projektikäsikirjaa ja etenee asiakkaan kanssa sovittuun päämäärään. Projektipäällikön rooli vastaa osittain Scrumista tuttua tuoteomistajan roolia, mutta myös yhtä lailla ohjelmistoarkkitehdin roolia.

Suoriutuakseen tehtävästään, projektipäällikön on oltava teknisesti asiantunteva henkilö, mutta ennen kaikkea hänellä on oltava kyky delegoida ja pyytää apua. Koska oikeiden ratkaisujen valinta on edellytys ohjelmistoprojektin onnistumiselle, pitää projektipäällikön osata kysyä apua, eikä vain luottaa omaan näkemykseen.