Ostat sivun... ja mitä sitten?
Kun ostamme auton, kysymme takuusta. Kun ostamme elektroniikkaa, haluamme tietää huollosta. Kun remontoimme taloa, odotamme, että tekijä kantaa vastuunsa työstä.
Entä kun tilaat verkkosivun tai sovelluksen?
Hyvin usein esitetään vain yksi kysymys: "Milloin se on valmis?"
Se on ymmärrettävää. Kaikki haluavat käynnistää projektinsa mahdollisimman nopeasti. Ongelma on siinä, ettei julkaisu ole projektin loppu. Se on hetki, jolloin ratkaisu alkaa toimia todellisessa ympäristössä.
Ja juuri silloin takuu saa suurimman merkityksen.
Mitä ohjelmistotakuu oikeastaan on?
Monet olettavat virheellisesti, että takuu tarkoittaa uusien ominaisuuksien lisäämistä ilmaiseksi. Näin ei ole.
Takuu kattaa ratkaisun toimivuuden sovitun projektin laajuuden mukaisesti.
Jos käyttöönoton jälkeen ilmenee virhe, joka johtuu suunnittelu- tai toteutusprosessista, tekijän tulisi korjata se takuun ehtojen mukaisesti. Kyse on vastuusta oman työn laadusta, ei muuttuvista liiketoimintavaatimuksista.
Takuu ja järjestelmän kehitys — ne eivät ole sama asia
Tämä on erittäin tärkeä ero.
Esimerkiksi: yritys haluaa puolen vuoden jälkeen lisätä varausmoduulin. Se ei ole korjausvirhe vaan järjestelmän kehitystä.
Vastaavasti integraatio uuteen ERP-järjestelmään, lisämaksutapojen lisääminen tai hallintapaneelin uudelleenrakennus ovat uusia toiminnallisuuksia.
Jos taas yhteydenottolomake lakkaa toimimasta projektin toteutuksen aikana tehdyn koodivirheen vuoksi, kyse on takuukysymyksestä.
Mitä hyvä takuu tulisi kattaa?
Yhtä yleispätevää standardia ei ole, mutta kannattaa kiinnittää huomiota siihen, määritteleekö tekijä selkeästi:
- mitä takuu kattaa,
- miten virheet ilmoitetaan,
- mikä on vasteaika,
- mikä on ilmoitusten tarkastusprosessi,
- tehdäänkö korjaukset ilman lisäkustannuksia,
- mitkä tilanteet eivät kuulu takuun piiriin.
Mitä läpinäkyvämmät säännöt, sitä vähemmän väärinkäsityksiä tulevaisuudessa.
Miksi takuun pituus ei kerro kaikkea?
Yhden vuoden takuu ei aina ole huonompi kuin kolmen vuoden. Kolmen vuoden takuu ei myöskään aina tarkoita parasta laatua.
Tärkein kysymys on: Onko tekijä todella saatavilla, kun ongelma ilmenee?
Sillä pisinkään takuu ei merkitse paljoa, jos tekijään on vaikea saada yhteyttä muutaman kuukauden jälkeen. Siksi kannattaa kiinnittää huomiota paitsi sopimuksen ehtoihin myös yrityksen kokemukseen, historiaan, viestintätapaan ja asiakaslähtöisyyteen.
Yleisimmät tilanteet käyttöönoton jälkeen
Projektin käynnistyksen jälkeen voi ilmetä erilaisia skenaarioita.
Esimerkiksi:
- käyttäjät käyttävät järjestelmää ennakoimattomalla tavalla,
- selaimet päivittyvät ja ilmestyy uusia versioita,
- ulkopuoliset API-rajapinnat muuttuvat,
- maksupalvelun operaattori päivittää ratkaisunsa,
- yritys haluaa laajentaa järjestelmää uusilla moduuleilla.
Kaikki näistä eivät ole toteutusvirheitä. Siksi on tärkeää erottaa takuu, tekninen tuki ja projektin kehitys toisistaan.
Takuu on myös luottamuksen osoitus
Pitkä takuu kertoo myös tekijästä. Se osoittaa, että tekijä kantaa vastuuta valmistamastaan ratkaisusta eikä lopeta yhteistyötä julkaisupäivään. Tämä on erityisen tärkeää räätälöidyissä järjestelmissä, verkkokaupoissa ja sovelluksissa, joita kehitetään usein vuosien ajan.
Miten meillä Web24:ssa toimitaan?
Web24:ssä lähdemme siitä oletuksesta, että projektin käyttöönotto ei päätä yhteistyötä.
Siksi myönnämme tekemillemme verkkosivuille, verkkokaupoille ja sovelluksille 3 vuoden takuun toteuttamiimme töihin.
Se ei tarkoita, että laajennamme projektia uusilla ominaisuuksilla ilmaiseksi kolmen vuoden ajan. Se tarkoittaa sitä, että otamme vastuun siitä, että se, mitä olemme luoneet, on laadukasta.
Uskomme, että hyvä software house on kumppani myös käyttöönoton jälkeen.
Yhteenveto
Valitessasi tekijää kannattaa kysyä muutakin kuin hintaa, toimitusaikaa tai teknologiaa.
Kannattaa myös kysyä:
- Miltä takuu näyttää?
- Mitä se kattaa?
- Miten ongelmat ilmoitetaan?
- Tarjoaako yritys tukea käyttöönoton jälkeen?
- Kuinka pitkään se kantaa vastuuta ratkaisustaan?
Nämä kysymykset usein ratkaisevat yhteistyön laadun seuraavina vuosina.
Hyvin kirjoitettu koodi on arvokasta.
Mutta yhtä tärkeää on varmuus siitä, ettet jää sen kanssa yksin käyttöönoton jälkeen.
