Ostaisinko tuotteen vai koodaisinko itse - 5 kysymystä IT-hankkeen vetäjälle

Uusi IT-hanke käynnistymässä? Näiden kysymysten avulla taklaat pahimmat sudenkuopat!

Ostaisinko tuotteen vai koodaisinko itse - 5 kysymystä IT-hankkeen vetäjälle

IT-hanke edessä, mutta et ole varma, ratkoako ongelmaa tuotepohjaisella ratkaisulla vai lähteäkö koodaamaan ”pohjanmaan kautta”. Kuulostaako tutulta tilanteelta? Mietityttääkö myös se, miksi niin suuri osa IT-hankkeista tuntuu menevän tavalla tai toisella pieleen? Miten varmistaa, ettei itse lankea pahimpiin sudenkuoppiin?

Tässä muutamia kysymyksiä (ei missään prioriteettijärjestyksessä), joiden kautta omaa hanketta kannattaa pohtia ennen sen käynnistämistä. Osa asioista soveltuu myös hankkeen aikana pohdittavaksi mahdollisten korjausliikkeiden suunnittelussa. Kun luet seuraavia kohtia läpi, huomaat ehkä niitä yhdistäviä tekijöitä.

1. Onko meillä nöyryyttä ja halua sopeutua?

Tuotepohjaisessa ratkaisussa oleellista on kunnioittaa tuotteen suunniteltua käyttölogiikkaa. Olen liian monta kertaa törmännyt tilanteeseen, että valitaan markkinoiden johtava tuotepohjainen ratkaisu ja lähdetään sovittamaan sitä vastaamaan pilkun tarkasti omiin vaatimuksiin. Jos laaditaan omat tarkat liiketoimintavaatimukset, ne lähes 100% varmuudella ei osu yksi yhteen minkään tuotepohjaisen ratkaisun kanssa. Todennäköisesti osa vaatimuksista voidaan toteuttaa tuoteratkaisua laajentamalla tai yhdistämällä useampia ratkaisuja, mutta lähes varmasti osa vaatimuksista on täysin vastaan tuotteen omaa logiikkaa. Ja jos tällaisessa tilanteessa pitää oman päänsä, melko suurella todennäköisyydellä ajautuu syviin ongelmiin.

Tuotepohjaista ratkaisua suunniteltaessa tulisi ensin listata vaatimukset yleisemmällä tasolla, oppia ymmärtämään miten eri tuoteratkaisut toteuttavat näitä vaatimuksia ja valita näistä parhaiten tarpeeseen sopiva. Seuraavassa vaiheessa sitten laaditaan tarkat vaatimukset valittua tuotetta vasten. Tällöinkin äärimmäisen tärkeää on, että ristiriitatilanteissa sopeudutaan tuotteen ratkaisumalleihin ja modifioidaan ratkaisua vain hyödyntämällä niitä laajennuspisteitä, joita tuotteen kehittäjä on suunnitellut käytettävän.

Huom: Jos markkinoilla on kasa tuotteita, jotka kaikki ovat otsikkotasolla tarpeeseen sopivia mutta käytännössä mikään niistä ei osu lähellekään omaa tarvetta, tulisi hälytyskellojen soida. Miksi olemme tällaisessa tilanteessa? Onko todella niin, että teemme jotain uniikkia koko maailmassa? Pitäisikö meidän itsemme alkaa ajattelemaan ongelmakenttää niin kuin muut tekevät? Vai onko tämä nimenomaan meidän kilpailuetu, joka erottaa meidät muista?

2. Onko meillä sitkeyttä opetella tuotepohjainen ratkaisu perin pohjin?

Kukaan muu ei tunne liiketoimintaasi niin kuin sinä itse. Myöskään kukaan muu kuin sinä itse ei voi tietää, kuinka hyvin tuote soveltuu liiketoimintaasi. Jos haluat onnistua tuotepohjaisen ratkaisun käyttöönotossa, jonkun organisaatiostasi on pakko ajaa itsensä syvälle sisään tuotteeseen. Tämä on tehtävä viimeistään hankkeen suunnitteluvaiheessa. Jos vain luotat siihen, mitä myyjä tuotteesta kertoo, olet heikoilla jäillä. Kokenut myyjä osaa asetella sanansa niin, että kaikki on mahdollista. Kuitenkin projektitoimitussopimuksessa tällaiset karikot on todennäköisesti osattu väistellä. Tai jos ei olla osattu väistellä, ollaan silti samassa konkurssissa mutta itse ongelman ratkaisun sijaan keskustellaan ongelman syyllisistä. Muista: Et saa kiitosta siitä, että olet oikeassa tai syytön ongelmiin. Vain onnistunut hanke on onnistunut hanke.

Sinun pitää myös pystyä arvioimaan, kuka on oikea taho toimittajaksi tuotepohjaisen ratkaisun käyttöönotossa. Olen nähnyt tilanteen, jossa asiakas maksoi tuotepohjaisesta ratkaisusta useita satoja tuhansia euroja, mutta käyttöönottokumppani ei ollut hyödyntänyt ainoatakaan tuotteen ominaisuutta. Sen sijaan kumppani oli käyttänyt 1,5 vuotta siihen, että oli etsinyt tuotteesta kohdan josta pääsee koodaamaan, ja oli toteuttanut koko ratkaisun koodaamalla itse. Lopputuloksena oli arviolta 1,5-2,0 miljoonaa euroa hukkaan heitettyä rahaa ja järjestelmä, joka ei kestänyt edes yhden käyttäjän aiheuttamaa kuormaa.

Oppina seuraavaa: Perehdy tuotteeseen niin hyvin, että tiedät sen sopivan tarpeeseesi. Tämän jälkeen pystyt myös arvioimaan, kuka osaa ja pystyy toteuttamaan tarvittavan ratkaisun tuotteen avulla. Ja ennen kaikkea pystyt jollain tasolla arvioimaan, onko kumppanin ehdottamat ja toteuttamat ratkaisut järkevän kuuloisia.

3. Tiedämmekö, minkälaista ratkaisua rakennamme?

Mitä selkeämmin tiedämme, mitä olemme tekemässä, sen paremmalta tuotepohjainen ratkaisu kuulostaa. Jos tuote siis vastaa tarvetta. Koodauspohjainen ratkaisu soveltuu paremmin käyttöön silloin, kun markkinoilta ei löydy soveltuvaa valmisratkaisua, tai kun emme ihan tiedä, mihin suuntaan ratkaisu tulee jatkossa kehittymään. Tällöin on fiksua lähteä liikkeelle mahdollisimman pienellä toteutuksella ja päästä koestamaan ratkaisua käytännössä. Näin käyttäjiltä saadaan arvokasta palautetta siitä, mihin suuntaan ratkaisua pitää kehittää.

Nyrkkisääntönä: Jos pystyt määrittelemään vaatimukset/käyttötapaukset, tee se. Joudut sen tekemään kuitenkin ennemmin tai myöhemmin. Mitä paremmin tiedät tarpeesi jo toteutukseen lähdettäessä, sen varmemmalla pohjalla ratkaisun suunnittelu ja hankkeen onnistuminen on. Speksauksen puute ei ole ketteryyttä, se on laiskuutta.

4. Tiedämmekö, mitä rahalla saamme?

Tämä on iso kysymys. Ehkä se isoin yksittäisen hankkeen näkökulmasta.

Tämän kysymyksen parissa olemme usein selkeämmillä vesillä tuotepohjaisessa ratkaisussa. Meillä on jotain konkreettista, jonka tiedämme saavamme. Voimme kliksutella tuotetta ja nähdä miten se toimii ja minkälainen käytettävyys sillä on. Oleellista tuotepohjaisen ratkaisun osalta on varmistua siitä, mitä kaikkea tuotelisenssi kattaa. Onko meillä tarvittavat lisenssit/ratkaisut kaikille käyttäjille? Kaikille integraatioille? Kaikille eri ympäristöille joita tarvitsemme kehittämiseen, laadunvarmistukseen ja tuotantoon? Olemmeko ottaneet huomioon muihin järjestelmiin tarvittavat kehitys- ja sovitustyöt? Kaikki integraatiotyöt? Kaikki testaustyö? Oman henkilöstön työ? Ylläpitokustannukset? Olemmeko varautuneet tulevaisuuteen, eli tiedämme, mitä maksaa ratkaisun laajentaminen uusille käyttäjille ja uusiin käyttötarpeisiin?

Koodauspohjaisessa ratkaisussa olemmekin sitten usein heikommilla jäillä. Selkeitä kysymyksiä on vähemmän, mutta etenemisen päälinjoja on kaksi:

  1. Sovitaan käytettävissä olevista resursseista tai
  2. Sovitaan toteutettavista käyttötapauksista/vaatimuksista.

Näistä ensimmäinen vaihtoehto soveltuu silloin, kun ratkaisua lähdetään rakentamaan aidosti ketterästi. Meillä on tiedossa kuukausittainen burn rate ja ratkaisua kehitetään priorisoimalla käyttötapauksia ja vaatimuksia kehittäjille työjonoksi. Ongelmana on, että kukaan ei osaa ennen hankkeen alkua sanoa, koska ollaan maalissa ja paljonko kustannuksia lopulta kertyy. Tämä voi olla vaikea pala organisaation johdolle.

Jälkimmäinen vaihtoehto vastaa aika pitkälti tuotepohjaista ratkaisua, mutta sen vaatimuksena on hyvin yksityiskohtainen ratkaisusuunnitteluvaihe. Ja riskinä on valheellinen kuvitelma siitä, milloin ratkaisu on valmis. Usein tehdään virheellinen päätös silloin, kun lukitaan investointi kattamaan tiukasti vain vaatimusmäärittelyssä pakolliseksi merkityt ominaisuudet. Kun vaatimusmäärittely tehdään itse ilman valmista referenssiratkaisua, siitä hyvin suurella todennäköisyydellä unohtuu oleellisia toiminnallisuuksia ja näkymiä. Usein myös päädytään harmaalle alueelle siinä, mikä on riittävän laadukas toteutus tai riittävän hyvä käytettävyys.

Vinkki: Jos rahkeet ei kestä heittäytyä aidosti ketterään ”sumussa kehittämiseen”, voi hyvänä ratkaisuna olla vaiheittainen hankemalli ja sitä vastaava investointivaraus. Eli lukitaan hankkeen ensimmäisen vaiheen vaatimukset ja kustannukset melko tiukasti. Hankkeen toisen vaiheen vaatimukset listataan suunnitelmaan ja investointiesitykseen merkittävästi karkeammalla tasolla. Ja merkitään hankkeelle vielä kolmaskin vaihe, mutta sen vaatimukset kannattaa hankkeeseen lähdettäessä linjata hyvin ylätasoisina tavoitteina. Näin hanke pidetään selkeästi vaiheistettuna ja annetaan itselle mahdollisuus hankkeen edetessä arvioida seuraavien vaiheiden priorisointia uusiksi eteen tulevien havaintojen pohjalta.

5. Tiedämmekö, mitä maailmaa rakennamme?

Tämä ei ole hankkeen kannalta se isoin kysymys, mutta tämä on ehkä IT:n pitkän kantaman suorituskyvyn ja kustannustehokkuuden kannalta se suurin kysymys. Tämä kysymys korostuu koodausvoittoisessa maailmassa. Erityisesti nykymaailmassa, kun ratkaisut rakennetaan pääosin erilaisten pilviratkaisujen päälle. Ja erityisesti, kun rakennamme ketterästi, ilman raskaita vaatimusdokumentteja.

Pilvitoimijat (AWS, Google Cloud, MS Azure,…) ovat saaneet koodarit innolla fanittamaan alustojansa, koska niiden päälle on niin helppo toteuttaa palveluja. Aiemmin, jos halusit rakentaa webbipalvelun, piti IT-infraan pystyttää yksi tai useampia palvelimia, konffata verkkoasetuksia ja palomuureja, asentaa käyttöjärjestelmästä lähtien kaikki tarvittava. Tähän kaikkeen saattoi hyvin kulua kuukausia aikaa. Ja tuhansia euroja rahaa. Nyt riittää muutama koodarin ranneliike ja palvelut ovat pystyssä päästä päähän, ilman raudan ja käyttöjärjestelmien ylimääräisiä päänvaivoja ja kuormaa. Ja yksittäisen mikropalvelun pyörittäminen on usein hyvin edullista verrattuna vanhoihin rautapohjaisiin palvelimiin ja softalisensseihin.

Ideaalinen ympäristö nopeaan ja ketterään kehittämiseen! Miksi rustata kilometreittäin vaatimusdokumentaatiota, kun samassa ajassa ehtii koodata netin täydeltä softaa ja saada käyttäjät testaamaan ja antamaan palautetta kehitystyöstä?

Kuitenkin olemme ajautuneet tilanteeseen, jossa yhä useampi valittaa siitä, että uusi maailma on huomattavasti monimutkaisempi kuin aiempi. Aiemmin meillä oli yksi omassa tai lähellä olevan kumppanin hallinnassa oleva konesali ja kaikki mitä saliin tuotiin, oli oman IT:n vastuulla ja ylläpidettävää. Konesalissa oli todennäköisesti muutamia suuria IT-järjestelmiä pyörimässä ja selkeä release-vuosikello. Nyt olemme maailmassa, jossa yksittäinen sovelluskehittäjä voi kuukauden aikana saada aikaiseksi koko nipun pilven reunalla toimivia mikropalveluita ja vastaavia, jotka kutsuvat toisiaan ristiin. Yksi sovelluskehittäjä tuottaa niitä AWS:ään ja toinen Azureen.

Lisäksi ollaan siirretty selkeistä vanhojen tietojärjestelmä-monoliittien korvausinvestoinneista monoliittien louhintaan, eli korvataan monoliittien yksittäisiä toimintoja uuden sukupolven mikropalveluilla. Lopputuloksena paitsi monimutkaisuutta, myös vuosia ja vuosia kestävä tilanne, jossa uutta kustannettavaa syntyy mutta vanhaa ei pystytä ajamaan alas.

Oleellista: IT-organisaatiolta vaaditaan uudessa maailmassa uudenlainen rooli. IT:n tulisi ottaa uusi pilvimaailma selkeästi haltuunsa. Tätä valintaa ei voi jättää yksittäisen kehittäjän tai yksittäisen projektin vastuulle. IT:llä pitää olla selkeä kuva ja ohjaus siitä, mihin pilvipalveluihin ratkaisuja rakennetaan, mitä komponentteja ratkaisuissa käytetään, miten tietoturva, käyttäjähallinta ja integraatiot ratkotaan. Lisäksi organisaatiolla pitää olla realistinen kuva siitä, mitä uusi maailmankaikkeus maksaa ja millä aikataululla vanhaa maailmaa todellisuudessa pystytään ajamaan alas. Vaikka koodarilla on uudessa maailmanjärjestyksessä enemmän käytännön toimivaltaa, IT:n pitää ottaa vastuunsa IT-ratkaisuista.

Lopuksi

Kuten edellä luetelluista kohdista huomaat, IT-hankkeen onnistumiseen tarvitaan vahvaa sitoutumista. Tahtoa ja pitkäjänteisyyttä. Täytyy perehtyä asiaansa. Oli sitten kyse tuotepohjaisen ratkaisun käyttöönotosta tai pitkästä tavarasta koodaamisesta. Pysy lähellä kehitystiimiä ja tiedä, mitä on tapahtumassa. Jos jokin asia epäilyttää tai mietityttää, asiassa todennäköisesti on jotain epäilyttävää tai mietityttävää. Uskalla siis pysäyttää kone ja selvittää asia. Pehmeä johtaminen johtaa pehmeisiin tuloksiin.

Tsemppiä kaikille tuleviin hankkeisiin!

Categories:

Want to be the hero of cloud?

Good, because we don't. We make you the hero.

Let's start!