Kun räätälöityä ohjelmistoa tai palvelua lähdetään hankkimaan, sen lopullinen sijoituspaikka on lähes aina jossain päin asiakkaan liiketoimintaympäristöä. Tämä aiheuttaa mielenkiintoisia haasteita, varsinkin kun järjestelmiltä vaaditaan yhä enemmän hyvää käyttökokemusta, tehokkuutta ja panostamista ulkoasuun. Tietämys järjestelmän teknisistä tarpeista ei välttämättä riitä parhaaseen mahdolliseen lopputulokseen pääsemiseen – tarvitaan ymmärrystä myös järjestelmää ympäröivästä maailmasta.
Palvelu- ja tuoteprojektien onnistuminen ei välttämättä korreloi asiakkaan tyytyväisyyden kanssa. Toki useimmiten tuotantovaiheen aikana saadaan viitteitä mahdollisista konflikteista, mutta mikäli sovittuja käytänteitä konfliktien hoitamiseen ei ole, saattavat nämä jäädä piiloon pitkäksi aikaa.
Eräs yleinen syy konflikteille, muuttuville vaatimuksille tai muille perinteisesti “haittana” näkyville asioille löytyy yllättäen liiallisesta keskittymisestä itse tuotteen ominaisuuksiin. Alamme on nuori, mutta kokemuksemme riittävä huomaamaan, että palveluilla ja tuotteilla on harvoin täysin staattisia, muuttumattomia ominaisuuksia.
Kuvaa järjestelmää käyttäjän roolista käsin
Tuote tai palvelu ei elä tyhjiössä. Useimmiten sen elinympäristö on melkeinpä täysin sidoksissa asiakkaan ydinliiketoimintaan. Tavat joilla kehityksen kohde kommunikoi ympäristönsä kanssa ovat hyvin olennaisia ja tarjoavat usein ratkaisuja kehitysvaiheen ongelmiin. Monet ketteriin menetelmiin liittyvät metodit ja työkalut keskittyvätkin järjestelmän ominaisuuksien kuvaamiseen ulkoa käsin: käyttäjän tai liiketoiminnan roolista katsottuna.
Järjestelmän tarkoituksen kannalta tässä on paljon järkeä. Suurin osa teknisistä vaatimuksista ja valinnoista on johdettavissa näistä kuvauksista. Ajan käyttäminen ulkoisten liittymien – olivat ne sitten käyttäjiä tai muita järjestelmiä – kuvaamiseen harvoin menee hukkaan. Nämä kuvaukset vaativat tietoa liiketoiminnasta, johon järjestelmää tehdään. Siksi näiden käsittely onkin yhteistyötä ja eritoten yhdessä oppimista, jotta asiakkaan omaama tieto omasta toiminnastaan saadaan yhdistettyä järjestelmän toteuttavan merkistön kanssa.
Vähennä konflikteja kommunikoimalla
Asiakkaan ja toteuttajan välisen kommunikaation ei suinkaan tarvitse olla raskassoutuista. Eikä edes tarpeettoman formaalia. Kommunikaatio ja sitoutumisen aste kulkevat kuitenkin jossain määrin käsi kädessä, joten jonkinlaisia sopimuksia on syytä tehdä.
“Tiedon jakamisen” -käsitteeseen törmää hyvin usein sekä organisaation sisäisen että ulkoisen viestinnän parissa. Asiakkaan ja toteuttajan suhteessa itse “tiedon” määritelmä saattaa jo aiheuttaa ongelmia: “Verkkokauppa” ei esimerkiksi ole yksiselitteinen käsite. Yhteneväisyyksiä toki löytyy, mutta mitä syvemmälle toteutuksen tai halutun käyttäytymisen kuvaamisessa mennään sitä enemmän pienten näkemyserojen vaikutus näkyy ja kertautuu ajan kuluessa.
Aukaise merkitykset ja kerro halutut vaikutukset
Tapamme selittää merkityksiä eroavat. Palvelun tai ohjelmiston kehittäjän ja asiakkaan suhteessa merkitysten ymmärtäminen on ensiarvoisen tärkeää: Millainen punainen on punainen? Mitä tarkoittaa tallentaminen? Merkitysten monitulkintaisuudesta nousevat ongelmat voidaan ratkaista monella tavalla.
Palvelun tai ohjelmiston kehittäjän ja asiakkaan suhteessa merkitysten ymmärtäminen on ensiarvoisen tärkeää: Millainen punainen on punainen? Mitä tarkoittaa tallentaminen?
Koska ohjelmisto tai palvelu hyvin harvoin toimii irrallaan muista, on hyvä käydä läpi sen vaikutuksia ympäröivään järjestelmään joka usein muodostaa asiakkaan liiketoiminnan. Keskusteltaessa kehitettävästä järjestelmästä voidaan puhua “impakteista” eli halutuista vaikutuksista.
Kuvattaessa käyttäjän interaktioita palvelun kanssa voidaan erilaisia skenaarioita esittää vuolassanaisemmin käyttäjän näkökulmasta sen sijaan, että puhuttaisiin pelkästään käyttöliittymän komponenteista. Yleensä tämä merkitysten auki selittäminen antaa kuvan myös palvelua ympäröivästä ekosfääristä, jota kehittäjä pystyy monin paikoin hyödyntämään omassa työssään.
Kommunikaatiossa ja käytetyissä menetelmissä on kyse sopimuksista. Palvelujen ja ohjelmistojen tuottamiseen käytettävät metodit eivät ole olemassa metodien itsensä vuoksi. Huolimatta siitä, tehdäänkö työtä “ketterästi” vai “perinteisesti”, eri vaiheiden on syytä tuottaa arvoa. Ero on siinä, missä vaiheessa toimitusta kommunikoidaan ja mitkä sen tavoitteet ovat.