Ketterän projektin johtaminen asiakkaan näkökulmasta

Vierityspalkin ja Kelan yhdessä järjestämä ”Ketterän verkkoprojektin johtaminen” -seminaari pidettiin pari viikkoa sitten Helsingissä. Videot ja materiaalit tulevat saataville lähiviikkoina. Sitä odotellessa tässä seminaarin puheenjohtajan viisi (5) valikoitua poimintaa seminaarissa käsitellyistä aiheista.

Poiminnat voivat sisältää tulkintoja esityksistä, joten täydellisenä dokumentaationa seminaarin asiasisällöstä näitä muistiinpanoja ei kannata ottaa.

1) Product Ownerin osaaminen ja näkemys ratkaisee.

Aidosti ketterässä projektissa vastuu laadusta, tekemisen järjestyksestä ja myös käytettävistä menetelmistä on lopulta Product Ownerin (PO) vallassa ja vastuulla. Siksi ketterien projektien onnistuminen kiteytyy paljolti asiakkaan puolelta löytyvän pätevän PO:n löytymiseen.

Rooli on myös monella tapaa epäkiitollinen, koska PO on jatkuvasti vaarassa joutua ristipaineeseen jossa häntä prässäävät niin oma organisaatio kuin ketterä kehitystiimi. Täten erityisesti paineensietokyky ja vahva näkemys projektin tavoitteista korostuvat PO:n ominaisuuksina.

PO:lle myös kasautuu herkästi erittäin paljon tehtävää, joten erilaisia PO:ta tukevia rooleja kannattaa isossa projektissa harkita. Esimerkiksi HS.fi:n kehityksessä PO:n tukena on erillinen tekninen projektipäällikkö.

PO vastaa myös toteutuksen laatutasosta, joka helposti ketterissä projekteissa voi karata ylilaadun puolelle. Yksi seminaarissa korostetuista vaikeista asioista olikin se, että PO:n pitää olla valmis hyväksymään ”seiskan laatutaso” silloin kun tärkeätä on vain päästä eteenpäin eikä jäädä hiomaan yksittäisiä ominaisuuksia.

Ylipäätään PO:lta vaadittavia ominaisuuksia pidettiin hyvin ratkaisevina ketterässä projektissa, jossa tiimi työskentelee juuri niiden toimintojen eteen jotka PO on määritellyt seuraavana toteutettaviksi.

Selvästi PO:lta vaadittavat ominaisuudet ovat myös asioita joita ei perinteisemmissä verkkoprojekteissa ole asiakkaan puolen projektipäälliköltä aiemmin odotettu. Täten asiakkaan puolen edustajalle kasautuva osaamispaine on yksi ketterien projektien merkittävä erityispiirre.

2) Kaikki mitä voi tehdä ennakkoon, niin kannattaa tehdä ennakkoon.

Erityisesti käyttöliittymän suunnittelu koettiin seminaarissa asiaksi jonka ennakkosuunnittelu on tärkeätä. Hyviä kokemuksia kuultiin etenkin prototyyppivetoisesta suunnittelusta, jossa on huomioitu alusta alkaen myös mobiili- ja tablettilaitteet. Tämän lisäksi tosin kannustettiin ottamaan ketterään projektiin mukaan myös käyttöliittymäsuunnittelija ainakin osa-aikaisesti jotta toteutustyön rinnalla voidaan tarkentaa ennakkoon tehtyjä ratkaisuja. Esimerkiksi Kela joutui toteutustyön rinnalla miettimään palvelunsa mobiilikäyttöliittymän varsin uusiksi, koska ennakkoon tehdyt suunnitteluratkaisut osoittautuivat ongelmallisiksi.

Käyttöliittymän suunnittelua ja toteutusta pidettiinkin yhtenä osa-alueena joka etenkin verkkopalveluprojekteissa voi aiheuttaa ongelmia vaikka sen suunnittelisikin pitkälti etukäteen.

Esimerkiksi paneelikeskustelussa kaikki pitivät käyttöliittymän ennakkosuunnittelua parhaana käytäntönä, mutta samalla painottivat mahdollisuutta muuttaa suunnitteluratkaisuja toteutustyön aikana.

Ehkä jopa hieman yllättäin paneelissa ei nähty käyttöliittymäsuunnittelijan olevan välttämättä osa teknisen toteutuksen tiimiä, vaan työskentely irrallaan tiimistä koettiin varsin hyvänä mallina.

Myös teknisen arkkitehtuurin ja palvelinratkaisujen suunnittelun osalta seminaarissa kannustettiin ”perinteiseen” tapaan, eli tarkkaan ennakkosuunnitteluun. Palvelinraudan ja teknisten arkkitehtuuriratkaisujen todettiin olevan hyvin ei-ketterää luonteeltaan, joten nämä suositeltiin hoitamaan kuntoon ennenkuin ohjelmiston toteutustiimi saapuu paikalle.

Ennakkoon tehtävän määrittelytyön osalta kuultiin myös mielenkiintoisia esimerkkejä erilaisista ”bootcamp”-ratkaisuista, joissa muutaman päivän hektisellä työpajatyöskentelyllä tehdään ennakkomäärittelyt kertarysäyksellä riittävään kuntoon. Näiden todettiin olevan hyviä ratkaisuja etenkin jos aikataulu on kiireellinen ja avainhenkilöitä on vaikea saada osallistumaan pitkään sarjaan suunnittelupalavereita.

3) Ketteryys sopii erityisen hyvin pitkäjänteiseen verkkopalveluiden kehitystyöhön.

Esimerkiksi Helsingin Sanomille ”ketterä projekti” oli vain tapa päästä parempaan jatkuvan kehittämisen tilaan. Myös Kelalla ketteryyden valinta perustui siihen, että edessä on heillä usean vuoden siirto- ja kehityshanke joka kattaa laajan julkisen sivuston lisäksi myös erittäin laajan kirjon uudelle alustalle siirtyviä extranet-palveluita.

Seminaarissa korostettiinkin moneen otteeseen, että projektimaisesti tehdyt ”ketterät projektit” ovat vain tapoja saada kerralla hieman enemmän muutosta aikaiseksi – ja ehkä ketteryyteen pitäisikin verkkoprojekteissa suhtautua enemmän jatkuvan kehityksen mallina. Etenkin HS.fi:n käyttämä Scrumin ja Kanbanin yhdistelmä korosti tätä jatkuvan kehityksen mallia – ja ketteryyden sopivuutta juuri tällaiseen jatkuvaan, hektiseen verkkopalvelun kehitystyöhön.

4) Prosessia ja toimintatapoja kannattaa muokata itselle sopivaksi.

Kaikesta ketterän kehityksen ympärillä käytävästä keskustelusta ja kirjallisuudesta voi helposti tulla mielikuva, että malliin liittyy paljon tiukkoja käytänteitä ja ehdottomia toimintatapoja. Käytännössä toimintamalleja saa ja kannattaa muokata rohkeasti omiin tarpeisiin soveltuviksi. Olipa HS ja Houston Inc kehitellyt jopa oman Scrumin ja Kanbanin yhdistelmänsä, ja piti tätä hyvin onnistuneena keitoksena.

Product Ownerinkin rooli ja tehtävät todettiin mukautuvan hyvin tapauskohtaisesti verkkoprojekteissa. Myös muiden tiimin jäsenten ja tukevien roolien tasapainoa kannustettiin hakemaan rohkeasti oman tilanteen mukaan. Esimerkiksi käyttöliittymäsuunnittelijan osallistumisesta teknisen toteutustiimin työhön tuntui olevan vielä useita eri näkemyksiä.

5) Mitä enemmän pystyy itse panostamaan projektiin, niin sitä enemmän ketteryydestä saa hyötyjä.

Kela ja HS.fi kumpikin osallistuvat kehitystyöhön huomattavan monipuolisella omalla tiimillä. Kelalla projektiin osallistui ulkopuolisten kehittäjien lisäksi myös kaksi täysipäiväistä omaa kehittäjää sekä neljän hengen sisältötiimi. Nämä olivat yhtä lailla osa projektia tekevää tiimiä kuin ulkopuolelta ostettu koodaustiimi.

Seminaarissa korostuikin vahvasti sisäisten resurssien merkitys ja riittävyys. Ilman riittäviä sisäisiä resursseja ketterä tiimi jää helposti tehottomaksi, ja esimerkiksi sisällöntuotantoa on vaikea saada pidettyä teknisen kehityksen tahdissa – testauksesta puhumattakaan.

Ketteryyden tuoma läpinäkyvyys ja muutoskyky vaatiikin vastapainokseen asiakkaalta vahvan tiimin ja kyvyn reagoida uusiin toimintoihin jatkuvasti. Pelkän testauskyvyn lisäksi asiakkaan tiimillä pitää olla resursseja aidosti käyttää uutta järjestelmää ja syöttää kehitystiimille palautetta ja kehitysehdotuksia. Jos tällaiseen hektiseen tiimityöhön ei ole asiakkaan puolella resursseja, niin merkittävä osa ketterän kehityksen tuomista hyödyistä jää toteutumatta.

Parhaimmillaan ketterä toteutustiimi tuo organisaation sisälle positiivista energiaa hehkuvan pyörremyrskyn joka auttaa uudistamaan ohjelmiston lisäksi sisältöjä, toimintatapoja ja koko tekemisen kulttuuria. Pahimmassa tapauksessa ketterä tiimi taas vain törmäilee jäykästi toimivan organisaation rakenteisiin ja toimintatapoihin eikä saa tuloksia aikaiseksi, koska joutuu odottelemaan muun organisaation hitaampaa toimintakulttuuria.

Lue lisää: Ketterät menetelmät olivat pieni askel oikeaan suuntaan

—

Perttu Tolvanen

Kirjoittaja on konsulttiyhtiö North Patrol Oy:n konsultti ja omistaja. North Patrol Oy on digitoimistoista ja järjestelmätoimittajista riippumaton toimija, joka auttaa asiakkaita valmistelemaan verkkopalveluhankkeita ja valitsemaan sopivimmat kumppanit ja teknologiat.

—

Lue lisää aiheista:

• Hyvä vaatimusmäärittely kuvaa mitä halutaan, muttei kerro miten
• Verkkopalvelun konseptisuunnittelu North Patrolissa

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee Drupalin, WordPressin sekä monet muut teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja verkkopalveluiden jatkokehityksen suunnittelussa.