Ensimmäisestä tapaamisesta pitkäaikaiseen kehitykseen

Kaikki alkaa ensimmäisestä keskustelusta myynti- ja kumppanimanagerimme, Ebba Gyllinin, kanssa.

Haluamme ensisijaisesti ymmärtää liiketoimintaa ja tarvetta. Kyse voi olla siirtymisestä Shopifyyn, täysin uudesta verkkokaupasta, B2B-toiminnasta, integraatioista tai pitkäaikaisesta yhteistyöstä jonkin palvelupakettiemme kautta.

Keräämme jo olemassa olevat tiedot ja dokumentaation ja aloitamme samalla rakentamaan sisäistä osaamistamme liiketoiminnasta, nykyisestä ratkaisusta ja asiakkaan tavoittelemista tavoitteista.

Ensimmäisen tapaamisen tarkoituksena ei ole myydä valmista ratkaisua. Sen tarkoituksena on ymmärtää ongelma riittävän hyvin, jotta voimme ehdottaa oikeaa seuraavaa askelta.

Seuraava vaihe on yleensä Discovery-vaiheemme.

Discovery voi olla yksittäinen työpaja tai pidempi työpajasarja projektin laajuudesta ja monimutkaisuudesta riippuen. Suuremmissa siirroissa, B2B-ratkaisuissa tai monia integraatioita sisältävissä organisaatioissa voimme joutua menemään huomattavasti syvemmälle.

Käymme yhdessä läpi ne osa-alueet, jotka on selvitettävä ennen tuotannon alkamista. Näitä voivat olla esimerkiksi liiketoimintaprosessit, Shopify, ERP, PIM, WMS, maksut, logistiikka, asiakastiedot, B2B-virrat, siirto, SEO ja integraatiot.

Työpajat voidaan toteuttaa digitaalisesti, jossakin toimistossamme Göteborgissa tai Malmossa tai asiakkaan toimipaikalla.

Tekniikka on mukana alusta alkaen

Discoveryyn osallistuu ei pelkästään Sales & Partner Manager. Mukana on myös Striden Solution Engineer.

Solution Engineerimme ovat fullstack-kehittäjiä, jotka yhdistävät kehitystyön laajempaan vastuuseen ratkaisusta ja asiakkaan projektista. Discoveryssä he auttavat arvioimaan mahdollisuuksia, tunnistamaan tekniset riippuvuudet ja laatimaan arkkitehtuurin ratkaisun toteuttamiseksi.

Tämä tarkoittaa, ettei teknisiä päätöksiä jätetä myöhemmäksi ajaksi. Ne ovat osa keskustelua jo alusta alkaen.

Sama Solution Engineer jatkaa myöhemmin mukana tuotannossa. Henkilö, joka on ollut mukana ja ymmärtää liiketoimintaa, keskusteluja ja päätöksiä Discoveryn aikana, tulee siis myös keskeiseksi yhteyshenkilöksi toteutuksen aikana.

Discovery-vaiheessa jatkamme asiakkaan tuntemuksen syventämistä, kunnes meillä on riittävästi tietoa ratkaisun määrittelyyn.

MIGRAatio- tai kehityshankkeen työ huipentuu kattavaan ehdotukseen, jossa kuvataan muun muassa:

• tekniset vaatimukset
• ratkaisun arkkitehtuuri
• hankkeen laajuus
• sprinttisuunnittelu
• toimitussuunnitelma
• kiinteä hinta

Tästä ei tule erillistä asiakirjaa, joka jäisi unholaan projektin alkaessa. Suunnitelma muodostaa pohjan asiakkaan allekirjoittamaan tarjoukseen ja sopimukseen.

Yksinkertaisesti sanottuna pyrimme tekemään mahdollisimman paljon suunnittelutyötä ennen kehityksen alkamista.

Tämä johtaa selkeämpään laajuuteen, parempaan kustannseurantaan ja huomattavasti vähempään yllätyksiin projektin aikana.

Haluamme, että asiakas ostaa ratkaisun, ei tunteja.

Siksi käytämme projekteissamme kiinteitä hintoja. Hinnoittelu perustuu Discovery-vaiheessa yhdessä laatimamme laajuusmäärittelyyn ja sprinttisuunnitelmaan.

Asiakasta ei kiinnosta sen sijaan, kuinka monta tuntia yksittäinen kehittäjä työskentelee tietyn toiminnon parissa.

Tärkeintä on, että toimitamme sovittua oikealla laadulla ja sovittujen kustannusten puitteissa.

Perusteellinen Discovery-prosessi on tärkeä edellytys sille, että voimme työskennellä tällä tavoin.

Kun sopimus on allekirjoitettu, tuotanto alkaa yhteisellä käynnistystapahtumalla.

Tässä kokoamme yhteen asiakkaan ja Striden keskeiset sidosryhmät. Käymme yhdessä läpi projektin, sprinttisuunnittelun, vastuujakautumisen ja toimitussuunnitelman.

Tarkennamme, mitä materiaalia ja päätöksiä tarvitsemme asiakkaalta, ja sovimme projektin aikana käytettävät säännölliset tapaamiset.

Asiakas saa samalla käyttöönsä Productiven, järjestelmän, jossa hallinnoimme projektejamme.

Haluamme, että asiakas voi seurata projektiaan ilman, että hänen tarvitsee odottaa tilannepäivitystä.

Productivessa projektin tehtävät ja toimitukset on koottu yhteen. Asiakas voi seurata muun muassa:

• jokaisen projektitehtävän
• ajankohtaista tilannetta
• tulevaa työtä
• sprinttejä ja toimitussuunnitelmaa
• projektin budjettia ja taloudellista kehitystä suhteessa sovittuun talousarvioon
• tehtäviin ja päätöksiin liittyvää viestintää

Asiakas voi myös ottaa suoraan yhteyttä Solution Engineerilleen ja muihin projektissa työskenteleviin henkilöihin.

Näin työskentelemme samassa projektinäkymässä sen sijaan, että tieto katoaisi sähköpostiketjujen, asiakirjojen ja eri sisäisten järjestelmien väliin.

Kaikki työntekijämme ovat kotoisin Ruotsista ja puhuvat ruotsia.

Migraatio- ja uudisrakennusprojekteissa meillä on yleensä vähintään yksi yhteinen projektipalaveri joka viikko asiakkaan, Solution Engineerin ja Striden asianomaisten henkilöiden kesken.

Palaverit pidetään yleensä Teamsin välityksellä, ja niissä käydään läpi tila, tulevat sprintit, päätökset, riippuvuudet ja ratkaistavat kysymykset.

Näin asiakas pysyy koko ajan lähellä projektia, ja päätöksiä voidaan tehdä sitä mukaa kun projekti etenee sen sijaan, että ne kasautuisivat yhteen.

Vaikka laajuusmäärittely olisi tarkka, projektin aikana jotain muuttuu lähes aina.

Uusia ideoita syntyy. Yritys huomaa, että se haluaisi lisätä jonkin toiminon. Tarve, jota ei ollut tunnistettu Discovery-vaiheessa, muuttuu yhtäkkiä ajankohtaiseksi.

Tämä on täysin normaalia.

Uudet toiveet käsitellään erikseen Productivessa. Siellä asiakas voi lisätä toimintoja tai muutoksia, jotka jäävät alkuperäisen laajuusmäärittelyn ulkopuolelle ja joiden hinnasta hän haluaa tarjouksen.

Tarkistamme tarpeen ja palaamme kiinteällä hinnalla.

Jos asiakas hyväksyy hinnan, työ lisätään projektiin ja suunnitellaan muiden toimitusten ohella. Asiakkaan ei siis tarvitse hyväksyä jatkuvasti konsulttitunteja, vaan hän tietää muutoksen hinnan ennen työn alkamista.

Emme kehita suoraan asiakkaan live-teemaan.

Työ tehdään erillisissä kehitysteemoissa ja alateemoissa, ja koodimme versioidaan GitHubissa. Tämä antaa meille hallinnan muutoksista ja versiohistoriasta sekä mahdollisuuden tarkistaa koodi ennen sen siirtämistä eteenpäin.

Työskentelemme vakiintuneiden QA-prosessiemme mukaisesti, ja koodi tarkistetaan ennen sen julkaisua.

Tämä vähentää riskiä, että käynnissä oleva kehitys vaikuttaa olemassa olevaan kauppaan, ja mahdollistaa muutosten asianmukaisen testaamisen ennen kuin ne saavuttavat asiakkaan kävijät.

Kun uusi projekti lähestyy julkaisua, alkaa laaja UAT-jakso – User Acceptance Testing.

Tässä vaiheessa ratkaisua testataan järjestelmällisesti sekä Striden että asiakkaan toimesta.

Käytämme valmiita testialustoja ja käymme läpi toiminnot, prosessit ja tärkeät käyttötapaukset ennen kuin ratkaisu hyväksytään julkaistavaksi.

Kyse ei ole vain siitä, että tarkistetaan, näyttääkö sivu oikealta. Haluamme varmistaa, että kokonaisuus toimii käytännössä – asiakkaan polusta ja kassavaiheesta aina integraatioihin ja sisäisiin työprosesseihin asti.

Vasta kun testit on suoritettu ja ratkaisu hyväksytty, suunnittelemme lopullisen julkaisun.

Autamme asiakasta koko matkan ajan, kunnes uusi ratkaisu on julkaistu.

Siirron aikana nykyinen verkkokauppa säilyy ja toimii projektin ajan. Uutta ratkaisua kehitetään ja testataan rinnakkain, ja se korvaa vanhan vasta, kun olemme yhdessä valmiita toteuttamaan julkaisun.

Siirtoa edeltäen suunnittelemme itse siirtymisen, datan siirron, integraatiot ja muut siirtymän yhteydessä hoidettavat riippuvuudet.

Autamme myös uudelleenohjausten ja siirtoon liittyvän SEO-työn kanssa, jotta esimerkiksi nykyiset URL-osoitteet ja orgaaninen näkyvyys hoidetaan osana siirtoa.

Tavoitteena on, että itse siirtyminen on mahdollisimman hallittua.