kotilinkki webbisivut

Ohjelmoinnista tietämättömät kiinteistönvälittäjät tilaavat kiinteistönvälityksestä tietämättömiltä ohjelmoijilta kiinteistönvälityspalvelun. Kuulostaa mahdollisuudelta molemminpuoleiseen epäonnistumiseen, mutta projekti sujui loistavasti ilman mitään epäilyä asioiden sujumisesta. Ajattelin hiukan kertoa meidän prosessista yhtenä esimerkkinä verkkopalvelun tilaamisesta ja toteuttamisesta.

Sopimusneuvottelut ja vaatimusmäärittely

Toimittajayrityksen kannalta projektia ei ole ilman sopimusta tilaajan kanssa. Kannattaa kuitenkin aluksi unohtaa koko asia, sillä sopimus tulee mikäli on tullakseen. Kannattaa suoraan hypätä siis tärkeimpään asiaan, mahdollisesti tulevan projektin kannalta, eli vaatimusmäärittelyyn.

Koko projektin onnistumisen kannalta on tärkeintä, että tilaajalla ja toimittajalla on sama käsitys tulevasta tuotteesta. Itse olen kokenut vaatimusmäärittelyn 90 prosenttisesti keskusteluksi ja ehkä 10 prosenttisesti dokumentoinniksi. Pitkät yksityiskohtaiset dokumentit kannattaa jättää tekemättä ja keskittyä pilkunviilaamisen sijasta todelliseen asiakkaan ymmärtämiseen. Istukaa alas yhdessä ja keskustelkaa, piirtäkää ja vaikka väitelkää, kunnes yhteisymmärrys tuotteesta on saavutettu. Useasti tilaaja ei aluksi edes täysin tiedä mitä haluaa ja sopivan typerillä insinöörimäisillä kysymyksillä asiat tuppaavat selkeytymään kaikille osapuolille.

Kannattaa heittää uusia ideoita ilmaan, ehdotella parannuksia, antaa kritiikkiäkin, ihan mitä vaan välittämättä siitä, että sopimusta ei vielä edes ole. Jos tässä vaiheessa tilaajan mielestä sinun kanssa keskustelusta on ollut hyötyä, olet todella vahvoilla sopimuksen saajaksi. Mikäli sinua ei kuitenkaan valita, niin varmasti hyvä keskustelu antoi yrityksestäsi hyvän kuvan. Ehkä saat tilaajalta tulevaisuudessa uuden tilauksen tai sinua suositellaan muille.

Keskustelkaa tuotteesta, kunnes varmasti ymmärrätte tuotteen läpikotaisin. Toimittajan kannattaa auttaa jo sopimusneuvotteluissa tilaajaa parhaan osaamisensa mukaan.

Ketterä Agile -sopimus

Sopimuksena pyrin itse aina suosimaan Agile -sopimusta, jossa projektia ja vaatimusmäärittelyä ei erityisesti rajata, vaan sitä työstetään projektin edetessä. Käytännössä siis vain tehdään tuntilaskutuksella pohjautuen alussa annettuun työmääräarvioon ja pyritään työn edetessä mahdollisimman tiiviiseen yhteistyöhön. Kiinteähintainen aina houkuttaa tilaajaa helpon budjetoinnin vuoksi, mutta sellainen vaatii projektin tarkan rajaamisen ja “lukkoon lyömisen” rajoittaen projektin vaatimusten muuttamista kesken projektin.

Ketterässä Agile -sopimuksessa toimittaja pyrkii esittelemään tuotetta mahdollisimman useasti projektin edetessä, jolloin tilaaja pystyy vaikuttamaan projektin lopputulokseen paremmin. Kokemukseni mukaan tilaaja haluaa aina muuttaa hiukan suuntaa matkan varrella, kun hän konkreettisesti näkee tilaamansa tuotteen ensimmäisiä versioita. Asiat näyttävät paperilla niin erilaisilta ja lisäksi konkreettisen demon näkeminen useasti tuo paljon uusia ideoita, joita olisi tärkeä saada myös lopulliseen tuotteeseen.

Kotilinkki Oy:n kanssa teimme Agile -sopimuksen muutamilla lisäehdoilla koskien aikarajoja. Eli käytännössä lupasimme toteuttaa tietyn perustoiminnallisuuden sovittuun aikarajaan mennessä tai muussa tapauksessa … noh jätetään jotain kertomattakin. Joka tapauksessa hyvä sopimus suojaa kumpaakin osapuolta ilman turhia rajoitteita.

Agile -sopimus on suositeltavaa ja toimii ennenkaikkea tuotteen parhaaksi. Raameja voi tehdä ympärille koskien aikatauluja ja kokonaistyöaikoja, mutta kannattaa varoa, etteivät ne ala rajoittamaan itse tuotetta.

Palvelun ominaisuudet ja teknologiat

Teknologioiden valinnoissa on yleensä toimittajalla suuri vastuu teknisenä osaajana. Jos toimittaja haluaa yritykselleen hyvän maineen, kannattaa tietysti valita yleisesti tunnetut ja hyviksi todetut teknologiat. Lisäksi ei kannata alkaa rakentamaan mitään omia teknologioita, mikäli vastaavia on jo olemassa. Omia teknologioita rakentamalla vain tuhlataan resursseja ja samalla tehdään tilaajalle toimittajan vaihtaminen vaikeammaksi.

Toimittajan olisi erittäin tärkeää olla luotettava ja ajatella Tilaajan etua. Varsinkin mikäli Tilaajalla ei ole omaa teknistä ymmärrystä. Toimittajan on myös tärkeää kertoa Tilaajalle pääpiirteittäin tuleva arkkitehtuuri. Vaikka kyse on teknisistä asioista, niin on tärkeää, että Tilaaja edes yleisellä tasolla ymmärtää mitä tuotteen “konepellin” alle kätkeytyy. Monesti Tilaajasta yksinkertainen palvelu onkin todellisuudessa yllättävän kompleksinen toteuttaa – tai päinvastoin. Väärinymmärrysten ja epäselvyyksien vuoksi on kuitenkin parempi pyrkiä antamaan mahdollisimman selkeä kuva asioista, jotka vaikuttavat projektin kestoon ja kustannuksiin.

Kotilinkki.fi palvelussa (rankasti yksinkertaistettuna) Asiakas voi tehdä sähköisen toimeksiannon (asunnon/kiinteistön myynnistä/vuokrauksesta) lain vaatimalla tavalla ja kiinteistönvälittäjillä on mahdollisuus hallinnoida palveluun saapuneet toimeksiannot. Pelkästään tällainen palvelu vaatii seuraavia asioita:

  • Verkkokäyttöliittymän asiakkaille ja välittäjille
  • Taustalla pyörivän tietokannan joka hallinnoi kohteita, niiden omistajia, sopimusasioita, välittäjien tietoja, jne.
  • Palvelun tietoturva-asioista huolehtiminen
  • Sähköisen allekirjoituksen toteuttamisen (TUPAS -palvelu)
  • PDF sopimusdokumenttien luomiset ja postittamiset

Toteuttamiseen käytimme teknologioita, jotka ovat hyvin skaalautuvia isompaankin käyttöön ja samalla tunnettuja yleisesti tiedossa olevia. Pyrimme myös käyttämään mahdollisimman paljon valmiita komponentteja, jotta sekä ylläpidettävyys helpottuisi että aikaa kuluisi vähemmän ja siten maksaisi tilaajalle vähemmän.

Käytä tai vaadi käytettäväksi tunnettuja ja hyväksi havaittuja teknologioita. Toimittajan kannattaa kertoa teknisestä toteutuksesta karkealla tasolla myös Tilaajalle, jotta vältytään epäselvyyksiltä.

Tuotteen kehittäminen

Tuotekehityksen aikana kannattaa olla jotain prosesseja mietittynä, kuinka Tilaaja voi parhaiten nähdä tuotekehityksen edistymisen ja mahdollisesti kokeilla keskeneräistäkin palvelua käytännössä. Ominaisuuksista pitää puhua ja varsinkin mikäli alussa uskalsi jättää vaatimusmäärittelyn mahdollisimman avoimeksi, täytyy ominaisuuksista keskustella yksityiskohdat selviksi projektin edetessä.

kotilinkki.fi tuotekehityksen aikana työstimme verkkopalvelua salasanalla suojatulle palvelimelle, jossa tilaaja pystyi testaamaan systeemiä koko ajan projektin edetessä. Raportoimme säännöllisesti uusista toteutetuista ominaisuuksista ja korjatuista puutteista. Viestittelimme ja soittelimme tilaajan kanssa tiheästi unohtamatta myös välillä keskustella kasvotusten. Yllättävän paljon kuitenkin hoidimme etänä, osittain johtuen siitä, että ymmärsimme hyvin toisiamme ja luottamus tuntui olevan kohdillaan.

Pelkän tuotteen edistymisen raportoinnin lisäksi töytyy tilaajalle säännölliseti kertoa käytetyistä tunneista ja siitä, ollaanko vielä aika-arvioissa vai pitääkö arvioita muuttaa.

Meidän projektissamme alkuperäinen työmääräarviokin ylitettiin, mutta tämä johtui suurimmaksi osaksi muuttuvista vaatimuksista. Alkuperäinen suunnitelma oli huomattavasti karsitumpi ominaisuuksiltaan, kuin se mihin lopulta päädyttiin. Raportoimme kuitenkin koko ajan myös käytetyistä tunneista, jotta myös tilaajalla on mahdollisimman tarkka kuva projektin kuluista.

Tuote täytyy saada Tilaajalle koekäyttöön mahdollisimman aikaisessa vaiheessa jotta lopputulos olisi mahdollisimman laadukas. Tämä tietenkin vaatii, että tilaajalla on aikaa kokeilla tuotetta ja antaa palautetta. Toimittajan pitää raportoida tehdyistä ja tulevista työmääristä riittävän usein.

Kolmannet osapuolet

Yksi yllättävän aikaavievä osuus projektista oli Tilaajan puolesta tapahtuvien teknisten asioiden hoitaminen kolmansien osapuolten kanssa. Palvelua varten tarvittiin esimerkiksipalvelimet, domain-nimen nimen ohjaaminen palvelimille, sähköpostitunnukset, SSL sertifikaatit ja TUPAS -sopimukset pankkien kanssa.

Näitä asioita varten kannattaa valmiiksi keskustella raamit, sillä on todella aikaavievää, jos Tilaaja toimii esimerkiksi kolmannen osapuolen ja Toimittajan välikätenä teknistä osaamista vaativassa asiassa. Asioinnissa auttoi todella paljon, mikäli tilaaja oli pystynyt sopimaan kolmannen osapuolen kanssa, että me toimimme heidän valtuuttamana. Tällöin asioiden hoito oli nopeaa ja mutkatonta. Kaikkea ei kuitenkaa näin voinut järjestää, sillä esimerkiksi TUPAS sopimuksia pankit eivät tee kuin suoraan tilaajan kanssa.

Sopikaa etukäteen kuinka Toimittaja voi hoitaa Tilaajan hyväksyntää vaativat tekniset asioinnit kolmansien osapuolten kanssa.

Viimehetken muutokset ja loppurutistus

Pari viikkoa ennen suunniteltua julkaisupäivää tilaaja halusi palveluun isohkon muutoksen, joka täytyi ehdottomasti saada palveluun mukaan. Jokainen tällaisen muutoksen tehnyt tietää, että se helposti tarkoittaa harmeja. Kun muutoksia tehdään projektin loppuvaiheessa, tarkoittaa se yleensä paljon sivuoireena tulevia ns regressiovirheitä ja vaatii uudelleentestauksen myös vanhojen ominaisuuksien osalta. Meidätkin pääsi yllättämään tämä regressiovirheiden määrä.

Julkaisuviikon aikana jäi yöunet lyhyeksi, kun viimeisiä korjauksia tehtiin yötäpäivää. Iso kiitos tilaajalle luottamuksesta ja rauhallisuudesta loppumetreillä. Vielä julkaisua edeltävänä päivänä meillä oli systeemissä pari melko kriittistä ongelmaa, mutta silti tilaaja vain totesi, että “tehkää mitä täytyy, niin eiköhän se saada ajoissa kuntoon”. En ole aivan olisinko itse ollut yhtä luottavainen Tilaajan saappaissa, mutta olen ollut vastaavissa tilanteissa ennenkin ja aina niistä ollaan hiukan työpäiviä venyttämällä selvitty.

Tuote yleensä valmistuu lopullisesti vasta juuri sovittuun aikarajaan. Niinsanottu viimehetken paniikki on oleellinen osa ohjelmistoprojekteja.

Pepsit
Loppurutistus

Ylläpito ja jatkokehitys

Tekemämme Agile -sopimus kattaa tuotten ylläpidon tietyillä molemminpuolisilla irtisanomisehdoilla. Koska toteutimme tuotteen käyttäen laajalti tunnettuja standardeja ja teknologioita, ylläpidon siirtäminen jollekin toiselle ei ole vaikeaa. Jos esimerkiksi tilaaja haluaa palkata itselleen ylläpitäjän tai ostaa palvelunsa toiselta yritykseltä, siihen ei ole mitän estettä. Olemme lisäksi luvanneet sopimuksessa tarvittaessa kouluttavamme mahdolliset uudet ylläpitäjät tai tuotteen jatkokehittäjät.

Miksi teemme meistä luopumisen näin helpoksi? Siihen on monta syytä, joista ehkä tärkein on meidän nörttien maine. Jos pelaamma tilaajan toimittajaloukkuun, menetämme oman maineemme, mutta myös pilaamme muiden ohjelmistotalojen maineetta. Toisaalta, joku tilaaja ei ehkä tekisi näin pienen yrityksen kanssa sopimusta ilman tuollaisia ehtoja.

Toimittajaloukulla pilaat yrityksesi maineen ja mahdollisesti myös Tilatun tuotteen. Lisäksi saat niskaasi muiden ohjelmistoyritysten paheksunnan ja Grace “kaikkien koodajien äiti” Hopperin haamun öisin kummittelemaan!

Yhteenveto

Yhteenveto nörteille

  • HTML, Bootstrap, LESS, JavaScript, JQuery, Python, Django, MySQL, NginX, …
  • Erilaisia laajennuskirjastoja (CMS, lokalisointi, PDF generointi, …)
  • 210 GIT committia ja ~50 tiedostoa täysin omaa koodia
  • Koodin osuudet suunnilleen: Python 75%, HTML 15%, LESS 5% ja JavaScript+JQuery 5%
  • Pepsiä ja kahvia
  • Lukemattomia Googlehakuja, joista useasti päädyttiin stackoverflow.com sivustolle

Yhteenveto normaaleille ihmisille

  • Keskustelkaa kunnes varmasti molemmat ymmärtävät tehtävän tuotteen läpikotaisin ja vielä vähän enemmän
  • Agile -sopimus takaa yleensä paremman lopputuloksen
  • Toimittajan päätavoitteena täytyy olla Tilaajan menestyminen
  • Mikäli haluaa hyvän tuotteen, täytyy myös Tilaajan osallistua kehitykseen aktiivisesti
  • Keskustelkaa rehellisesti jatkosta, myös mahdollisuudesta Toimittajan vaihtamiseen. Mikäli tuntuu hankalalta, vaihda Toimittajaa.
Saku
Founder, CEO and SW nerd of Eeku Oy. Yrittäjä, toimitusjohtaja ja koodinörtti @ Eeku Oy.

Leave a Reply

Your email address will not be published.

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.