Kun projekti epäonnistuu

Vincitillä ei varsinaisia projektipäälliköitä ole, mutta yksi koodaajista tai palvelumuotoilijoista ottaa aina suuremman vastuun projektin vetämisestä ja asiakkaan kanssa kommunikoinnista. Itse pääsin heti ensimmäisessä projektissani Vincitin leivissä tuohon projektivetäjän rooliin. Kova näytön paikka siis.

Projektin aloituspalaveri pidettiin maaliskuussa 2016. Asiakkaana oli startup-firma, joka on jo pitkään tehnyt omaa tuotekehitystä. Työn alla taisi olla peräti viides versio sovelluksesta. Tällä kertaa olivat kuitenkin päätyneet käyttämään alihankintaa osana toteutusta, koska olivat todenneet, että omalla tavalla tehden sovelluksen koodi päätyy aina hankalasti ylläpidettäväksi spagetiksi. Nyt he halusivat nähdä, kuinka kovimmat ammattilaiset sen tekevät.

Ymmärsimme siis, että nyt halutaan tehdä homma kunnolla ja aloimme laittaa tarkoitukseen parhaiten sopivaa sovelluskehystä kohdilleen. Koska tarkoituksena oli tehdä maailmanluokan tuote, otettiin myös palvelumuotoilu isoon osaan, käyttäjähaastatteluineen kaikkineen.

Tässä vaiheessa valittiin myös käytettävät teknologiat. Teimme valinnan yhdessä asiakkaan kanssa, sillä heillä oli runsaasti omaa osaamista ja näkemystä sekä perustellut mielipiteet. Alun perin oli ollut puhetta Angularista, mutta sen ykkösversion koimme molemmat vanhentuneeksi ja uudemman version puolestaan vielä liian raakileeksi. React vaikutti tarkoitukseen paljon sopivammalta. Projektiin Vincitin puolelta jo valituilla tekijöillä oli kokemusta Angularista, mutta Reactista lähinnä innostusta. Talon sisälläkin React-kokemusta oli tuossa vaiheessa vain muutamasta projektista, eikä käytettävissä ollut mitään kunnollista projektipohjaa. Tämä kaikki käytiin asiakkaan kanssa läpi hyvässä hengessä ja sovimme, että otamme uuden teknologian opetteluun kuuluvan osuuden projektista Vincitin piikkiin eikä asiakasta laskuteta siitä.

Seuraavat kaksi viikkoa kuluivatkin pitkälti tuotteeseen tutustumiseen, Reactin parhaiden käytäntöjen opiskeluun ja ympäristön pystytykseen. Taisimme saada valmiiksi lähinnä kirjautumisen palveluun. Seuraavan kuukauden aikana pääsimme omasta mielestämme jo hyvin vauhtiin, mutta lähinnä toistimme olemassa olevan sovelluksen toiminnallisuuksia uudella teknologialla ja ulkoasulla. Emme siis vieläkään luoneet mitään, millä olisi oikeasti voinut ihastuttaa asiakkaan. Pidimme tässä vaiheessa ensimmäisen retrospektiivin, jossa kaikki olimme sitä mieltä, että liikkeelle lähtö on ollut harmillisen tahmeaa.

Nyt kehys oli kuitenkin jo mallillaan ja kehittäminen selkeästi nopeampaa. Sovimme asiakkaan kanssa vielä priorisointipalaverin, jossa selvitettäisiin missä järjestyksessä eri ominaisuuksia toteutettaisiin ja sitouduttaisiin tiettyihin toimituksiin. Toki meillä oli ollut backlog käytössä koko ajan, mutta molemmin puolin kaipasimme laajempaa näkemystä ja ennustettavuutta.

Nyt elettiin toukokuun alkua. Tuossa priorisointipalaverissa meille kävi selväksi, että asiakkaalla oli aikomus toimittaa sovellus alkavan kesän aikana uudelle asiakkaalleen ja tämä oli nyt tärkein prioriteetti. Itse tässä vaiheessa hieman kyseenalaistin valittua lähestymistapaa: kannattaako lähteä tekemään uutta sovellusta tyhjältä pöydältä, jos tärkeintä on saada uusi asiakastoimitus tehtyä mahdollisimman nopeasti? Kyseessä oli kuitenkin melko mittavan kokoinen kokonaisuus. Eikö siitä olemassa olevasta versiosta silti saisi nopeammin puristettua toimivan ratkaisun? Asiakas taisi todeta, että näinhän se lienee ja parin viikon sisään projekti laitettiin jäihin. Kaikesta aikaan saamastamme koodista asiakas ei uskoakseni koskaan käyttänyt yhtään mitään. Rahatkin palautettiin.

Miltä ohjelmistoprojektin tekijöistä tuntuu tuollaisen epäonnistumisen jälkeen? Ainakin itselleni jäi pitkäksi aikaa paha mieli. Meidän olisi pitänyt pystyä parempaan. Ja mieltä askarruttavia kysymyksiäkin jäi. Olisimmeko voineet palvella asiakasta paremmin, jos olisimme aiemmin ymmärtäneet mikä merkitys nopealla toimituksella on?

Toki epäonnistumiset täytyy ensisijaisesti kääntää opiksi. Nykyään Vincitiltä löytyy Reactille projektipohja, jonka avulla liikkeelle lähtö on monin verroin nopeampaa. Itse yritän projektin aloituksissa ja myös projektin kuluessa vielä tarkemmin kaivella niitä kaikkein tärkeimpiä prioriteetteja. Jos ei voi saada hyvää, nopeasti ja halvalla, mistä tingitään? Jos ei edes voi saada niitä kahta jäljelle jäävää, tingitäänkö edelleen vai jätetäänkö tekemättä?

Itselleni tämä oli työurallani ensimmäinen tuolla tavoin kesken jäänyt projekti. Seuraavissa projekteissa on tuo keskeyttämisenkin mahdollisuus konkreettisemmin mielessä.

Mikael Rinnetmäki

Mikael Rinnetmäki
Erityisesti terveysteknologian parissa työskentelevä intohimoinen vanhempi ohjelmistoasiantuntija

4 kommenttia

Mikael Ahonen sanoo:

Hyvä kuulla näitäkin tarinoita. Yleensä firmoilla on vain sitä hurmoksellista hehkutusta, vaikka kaikki tietää minkälaista kaaosta työnteko keskimäärin on.

Varsinkin nuorena yrittäjänä tuli mietittyä, että miten menestyvät IT-firmat hoitaa projektinsa. Näköjään ihan yhtä paljon riittää opettelua ja haasteita puljusta riippumatta.

Kiitos jakamisesta!

xet7 sanoo:

https://codewithoutrules.com postituslistalla tuli 21h sitten samantapainen juttu aiheesta, tässä pätkiä siitä:

”Failing to do the impossible
Hi,
Today I’d like to tell you about the importance of saying “no.”

….(tässä oli samantapainen tarina)…

I never felt I did a good job for this particular client. Even as a proof-of-concept the software I delivered wasn’t very good. What should I have done differently?

In retrospect I should have said just said “no” to the customer: “No, I can’t do that with this budget. I don’t know enough to do it reasonably.”

Perhaps they would have found the extra budget, and so I would have had the time to do the work the right way, and fix any problems that came up. Or they would have realized what they were asking for was unrealistic. Perhaps they could have found someone cheaper to do the work.

Regardless of what they chose, they would have had a better outcome than what I provided by agreeing to the job.

Don’t make my mistake: don’t say “yes” to impossible tasks. By agreeing to do them you’re agreeing to solve the impossible, and that rarely turns out well.

Until next time,
-Itamar”

Mietin kyllä itsekin miten tunnistaa projekteista tarkemmin mihin kannattaa lähteä mukaan. Tärkeä aihe, kiitos kirjoituksesta! 🙂

Rohkeasti ja hyvin kirjoitettu Mikael! Etenkin mainitsemasi kohta ”myös projektin kuluessa vielä tarkemmin kaivella niitä kaikkein tärkeimpiä prioriteetteja” on tärkeä, koska prioriteetit ja ymmärrys asiakkaankin mielessä saattavat pyörähdellä samalla, kun ketterästi projektia tehdessä kokoajan viisastutaan… 🙂 Keep rocking!

amuranen sanoo:

Kiitos jakamisesta ja hienoa, että näistä puhutaan ääneen. Alalla toki tapahtuu paljonkin kömmähdyksiä, mutta harvemmin niistä kuulee jossei kyseessä ole esim. iso valtion investointi.

Mielestäni kaikki huomioon ottaen hyvin hoidettu ja vaikka lopputulos olikin ikävä, ei suurta vahinkoa saatu aikaiseksi. Virheistä pitää vaan oppia – sitä varten niitä tehdään. 🙂

Liity keskusteluun