tiistai 19. huhtikuuta 2011

Muutoshallinta: käytettävyysongelmien vastuun vierityksen kulminaatiopiste

Tyypillisessä asiakaskohtaisen järjestelmän kehitysprosessissa tapahtuu seuraavaa (kuva):


  1. Toimittaja (käyttöliittymäsuunnittelija) suunnittelee käyttöliittymäratkaisuja (rautalankamalleja ym), perustuen vaatimusmäärittelyihin ja muihin asiakkaalta saamiin tietoihin
  2. Toimittajan ehdotus käydään läpi projektin ohjausryhmässä tai vastaavassa, jossa suunnitelma hyväksytään. Toimittaja voi suostua pieniin muutosehdotuksiin, mutta ei isoihin. 
  3. Tämän jälkeen suunnitteluratkaisu laitetaan muutoshallintaan. Käytännössä tämä tarkoittaa sitä, että jos käyttöliittymää halutaan muuttaa, se tarkoittaa lisätilausta. 
Tässäpä sitä ollaan. Kun asiakas hyväksyy suunnitelman, niin samalla tapahtuu vastuun siirto käyttöliittymän laadusta asiakkaalle. Käyttöliittymän laitto muutoshallintaan on helpotus toimittajalle, mutta tarkoittaa haasteita asiakkaalle, jos käyttöliittymä ei toimikaan.

Toisella tavalla sanottuna: Voidaan puhua asiakas- ja käyttäjälähtöisyydestä. Sitä se onkin tietenkin jossain määrin. Mutta käytännössä oleellista on vastuun siirtäminen asiakkaalle.

2 kommenttia:

  1. Olen itse ollut tekemässä alihankintana pienkehitystä järjestelmään X. Ehdotukset muutoksiin voi tulla asiakkaalta tai toimittajalta. Asiakas on maksaja ja tilaaja, ja sitä kautta viime kädessä päätöksentekijä. Jos asiakas ehdottaa jotain päätöntä, niin sitä vastaan on taisteltu monien sähköpostien voimin. Välillä on voitettu, välillä hävitty. Tosi paljon käytettävyyteen vaikuttaa se, että ajasta tuntuu olevan aina pula. Tai rahasta, koska aika maksaa. Sitten tehdään mitä ehditään.

    VastaaPoista
  2. Kiitos hyvästä kirjoituksesta, tulkinta on erittäin osuva. Julkisella sektorilla ollaan vielä siinä mielessä hankalassa tilanteessa, että saman järjestelmän tilaajana saattaa olla useampi kunta. Tällöin vastuu päätöksistä ja käyttöliittymän laadusta jakautuu epämääräisesti "ei kenellekään".

    VastaaPoista