Älä ole kiinnostunut asiakkaan prosesseista, vaan minimoi tuotettavan tiedon määrää
Jo määritysvaiheessa kannattaa unohtaa asiakkaan käyttäjäroolit sekä niihin liittyvät tehtävät ja tavoitteet. Älä osoita kiinnostusta sen selvittämiseen, mitä asiakkaan todelliset käyttäjäryhmät ovat, mitä he tarvitsevat tai saavatko he äänensä kuuluviin. Määritystyöpajojen ensisijainen tehtävä on juoda kahvia ja jutella mukavia samalla kun selataan läpi irrallisia vaatimuksia ja tuotetaan sisällötöntä dokumentaatiota erilaisten johtajien luettavaksi.
Parasta on, jos saat määritystyöhön nakitettua henkilön, joka ei ymmärrä mitään asiakkaan toimialasta eikä myymästään teknologiasta, mutta osaa poliittisen jargonin jolla voidaan antaa kaikille käsitys että tässä nyt määritetään jotain vaikkei oikeasti määritetäkään. Jos myyt valmissoftaa, älä ainakaan esittele tuotteen demoympäristöä asiakkaalle - hehän saattaisivat vaikka ymmärtää, mistä määritystä tehtäessä puhutaan.
Suunnittelu- ja toteutusvaiheessa panosta vain siihen, että koodaaja pääsee mahdollisimman helpolla. Pyydetty toiminnallisuus on olemassa, jos sen yksinkertaisin käyttötapaus on mahdollista viedä läpi. Ei väliä, onko normaalin ihmisen mahdollista muistaa prosessin läpiviemisen vaatima akrobatia, tai löytyykö käyttöliittymästä kaikki tarvittava sen tekemiseen. Tärkeintä on, että ratkaisu on olemassa.
Panosta käyttöliittymän sekavuuteen
Pidä huolta, että käyttöliittymässä näkyy käyttäjälle moninkertainen määrä toiminnallisuuksia siihen nähden mitä hän tarvitsee. Parasta on, jos joukossa on viattoman näköisiä toiminnallisuuksia, joiden käyttäminen aiheuttaa katastrofin. Ja lupaavan ja tarpeellisen näköisiä toiminnallisuuksia, jotka eivät tee mitään. Ja toiminnallisuuksia, joista kukaan ei tiedä, mitä ne ovat ja miksi ne ovat siellä, saati seuraisiko niiden piilottamisesta katastrofi.
Jos käyttöliittymässä on personointeja kuten asiakkaan nimi, kirjoita se väärin. Tai kopioi toiminnallisuus toiselta asiakkaalta ja jätä vaihtamatta nimi, jotta käyttäjät varmasti ymmärtäisivät, ettei tätä järjestelmää heitä varten rakenneta.
Pyydä asiakkaalta vastauksia samoihin kysymyksiin useampaan kertaan
Älä lue projektissa tuotettua määritysdokumentaatiota. Älä pidä sitä ajantasalla. Pyydä asiakkaalta tietoa listoina, joiden merkityksiä he eivät ymmärrä, ja pyydä tätä tietoa kuukauden päästä uudelleen hukattuasi ensimmäisen version tai todettuasi ettei sen sisältö kuitenkaan vastaa asiakkaan tarpeita.
Älä näytä asiakasta ja teknisiä asiantuntijoita toisilleen, vaan pidä välissä suodattimena henkilöä joka ei ymmärrä heistä kumpaakaan, ja jolla ei riitä aika tehtäviensä hoitamiseen.
Kouluta keskeneräisellä järjestelmällä
Mikään ei ole parempi tapa pelotella ja hämmentää tulevia käyttäjiä kuin koulutusten järjestäminen heti kun jotain likipitäen pystyssä pysyvää on saatu asennettua. Oppi uppoaa parhaiten, kun koulutuksessa toistuvat fraasit "tämä olisi järkevämpää tehdä vähän toisella tavalla, mutta koska siinä on nyt bugi niin tehdään vähän vaikeammalla ja epäintuitiivisemmalla tavalla" sekä "sitten kun tämä valmistuu, niin tänne tulee näkyviin sellainen toiminto jonka kautta voitte tehdä sitä-ja-tätä". Parasta on, että järjestelmän ollessa koulutuksessa riittävän keskeneräinen, asiakas pääsee käyttämään sitä itse vasta kuukausia myöhemmin, mihin mennessä kaikki opitut tiedonmuruset ovat ehtineet unohtua.
Kikkaile raportoinnin kanssa, jotta asiakas aloittaisi hyväksymistestauksen vaikka toteutus on kesken
Tekee aina hyvää asiakassuhteelle väittää kirkkain silmin että kaikki toimii, kun seuraavana päivänä asiakas kokeilee itse ja saa todeta että mikään ei toimi. Ja kuinka mielenkiintoista onkaan selvittää, miten monta kertaa asiakas suostuu aloittamaan hyväksymistestauksen.
Tee toiminnallisia muutoksia kun järjestelmä on jo asiakastestauksessa tai pilotoinnissa
Jos tuntuu, että joku juttu olisi sitten kuitenkin järkevämpi jollain toisella tavalla, muuta se toimimaan järkevämmin. Ja jää sitten odottamaan, huomaako kukaan eroa, ja jos huomaa, keksiikö millaiseksi toiminnallisuus on muuttunut. Älä ainakaan päivitä käyttöohjetta muutoksen mukaiseksi, älä kerro kouluttajille, testaajille äläkä asiakkaille. Suunnittele valmiiksi ylimielinen vastaus, kun joku onneton kuolevainen uskaltautuu kysymään asiasta tai raportoi muutoksen bugina.
Älä ota asiakkaan ongelmia vakavasti
Kun asiakas on tyytymätön, totea että he eivät vain osaa käyttää järjestelmää, ja siksi heidän pitäisi ostaa lisää koulutusta. Toista tätä viestiä, vaikka asiakas olisi jo maksanut useammasta ekstrakoulutuspäivästä kuin mitä olit sisällyttänyt alkuperäiseen tarjoukseesi riittävänä koulutuspakettina järjestelmän käyttöönottamiseksi.
Ei kommentteja :
Lähetä kommentti