Projektit lähtevät luonnollisesti aina liikkeelle asiakkaan tarpeesta – siitä, mitä liiketoiminta digiratkaisulla tavoittelee. Projektista ja asiakkaan tilanteesta riippuen keskustelu sopivasta ratkaisusta voi aluksi olla hyvinkin abstraktilla tasolla, kun lähdetään avaamaan, millaista prosessia ollaan tavoittelemassa. Asiakkaalla voi myös olla ratkaisuajatus valmiiksi määriteltynä. Valmiissa tarvemäärittelyssä tiettyjen prosessien skaalautumisen tarvetta ja muita vastaavia toiminnallisuuteen liittyviä tarpeita ei kuitenkaan ole välttämättä dokumentoitu kovinkaan tarkasti, vaikka niitä olisikin jo speksiä laadittaessa mietitty, koska laatijan näkökulmasta ne ovat helposti itsestäänselvyyksiä.
Liiketoiminnan tarpeet ovat kuitenkin usein paljon helpommin täytettävissä ja toteutettavissa, kun asioita mietitään liiketoiminnan tarvelähtöisesti eikä vain valmiin speksin kautta. Samoin nyt AI-aikakaudella liikutaan siihen suuntaan että liiketoiminnan ja koodin pitää olla paljon lähempänä toisiaan koska iteraatioiden pituus pienenee, eli mahdollinen ristiriita tarpeiden ja toteutuksen välillä aiheuttaa entistä enemmän haasteita.
Melko harvassa projektissa ohjelmiston vaatimusmäärittelyt ja suunnitteludokumentit on kuvien kera niin pitkälle hiottu, että ohjelmoijalle ei jäisi mitään aukkoja täytettäväksi, miten ohjelmiston tulisi toimia. Jos ohjelmiston kehitys ja ylläpito on jaksottaista, ilman jatkuvaa suunnittelu- ja testaustiimiä, kehityksen onnistuminen on erittäin vahvasti kehittäjän ymmärryksen varassa. Yleistiedoilla toki pääsee usein pitkälle, mutta melko äkkiä yleensä tulee tarve ymmärtää liiketoimintaa ainakin perustasolla.
Meillä Fluentialla tavoitteena ja pyrkimyksenä on aina muodostaa kattava kokonaiskuva asiakasta puhututtavasta ongelmasta – mihin liiketoimintoihin ja henkilörooleihin se vaikuttaa ja mitä liikkuvia osia kokonaisuuteen liittyy. Näitä voivat olla esimerkiksi käyttäjämäärät ja niihin liittyvät toistuvat trendit, kuten työajat. Kirkastetaan ajatus siitä mikä on projektin tavoitetila ja millä tavoin toiminta asiakkaan tontilla muuttuu ratkaisun myötä. Mitkä asiat helpottuvat, mitkä prosessien osat toimivat jatkossa kokonaan automaattisesti, mikä osa-alue vaatii jatkossa enemmän työtä tai huomiota, jotta hyödyt muilla osa-alueilla mahdollistuvat.
Keskusteluissa voi nousta myös muita, varsin merkittäviäkin asioita, jotka vievätkin projektia eri suuntaan kuin alunperin oli ajateltu. Tällaisia voivat olla esimerkiksi projektin kokoluokka. Aluksi jättimäiseltä kehitysprojektilta vaikuttanut kokonaisuus saattaakin toimia paremmin pilkottuna pienempiin palasiin. Ilman huolellista keskustelua ja selvitystä liiketoiminnallisesta tarpeesta, toimittaja ei pääse arvioimaan ja tarvittaessa myös haastamaan ajatuksena ollutta toteutustapaa. Tällöin vaarana on, että saatetaan sokeasti lähteä toteuttamaan jotain, joka ratkaisee ongelman, mutta aiheuttaa ongelmia esimerkiksi ympäröivissä liiketoiminnoissa, ja projekti voi venyä esimerkiksi sen vuoksi, että kokonaisuutta lähdetään takautuvasti uudelleensovittamaan liiketoiminnan todellisiin kokonaistarpeisiin.
Yksi merkittävä asia on myös käsitellä asiakkaan toivomat toiminnallisuudet ja muodostaa yhteinen visio niiden priorisoinnista ja jaksotuksesta projektissa. Tässäkin on tärkeää uskaltaa haastaa asiakkaan suunnitelmaa ja ehdottaa vaihtoehtoisia toimia. Jotkin toiminnallisuudet kannattaa tehdä muita ennen. Osa kannattaa ottaa käyttöön ensin pienemmällä toteutuksella ja kerätä käyttäjäkokemuksia. Jotkin ominaisuudet taas kannattaa siirtää myöhempään vaiheeseen jotta projektin koko ja budjetti pysyvät kohtuullisina.
Myös meille digiratkaisujen toimittajana ja teknologiakumppanina on mielekästä, että tuotetut ratkaisut aidosti suunnataan asiakkaan liiketoiminnan tehostamiseen ja kasvun tukemiseen. Toimitaan tarkoituksenmukaisesti, kuten meillä tykätään sanoa.
Kehittäjien liiketoimintaosaaminen ja -ymmärrys ei heijastu pelkästään parempana teknologisena toteutuksena, vaan näin asiakkaalla ja toimittajalla muodostuu yhteinen visio siitä, mitä ollaan tekemässä. Tällöin kehittäjä pystyy pureutumaan paremmin siihen, miksi tietyt asiat halutaan tehdä juuri tietyllä tavalla. Näin saatetaan löytää tehokkaampia toteutustapoja, mikä taas johtaa parempiin liiketoimintaprosesseihin.
Joissain kokoonpanoissa toki riittää, että ohjelmoija hoitaa vain ohjelmointipuolen, ja vielä vähän kokemusta omaavat kehittäjät luonnollisesti ovat enemmän speksin varassa, mutta jokaisessa projektissa jonkun speksin tulkinta ohjelmistoksi täytyy kuitenkin tehdä. Kun sen tekee osaava, liiketoimintaa puhuva kehittäjä, voi asiakas parhaimmillaan saada paljon parempaa kuin oli alunperin tilaamassa. Asiakkaan ja teknologiakumppanin yhteinen pitkän tähtäimen visio liiketoimintaratkaisujen kehittämiseksi muodostaa myös erinomaiset puitteet pitkäaikaiselle, tulokselliselle ja luottamukselliselle kumppanuudelle.
Jos etsit liiketoimintaasi ymmärtäviä ohjelmistokehittäjiä toteuttamaan digitavoitteitasi, otathan yhteyttä!
