Vad, varför, hur och hur

Utvecklingsmetoder får ofta stor uppmärksamhet inom it-området. Leverantörer säljer sin unika metod, kunder som beställer system och tjänster har sin metod vilka ofta är kvalitetssäkrade. Men hur mycket påverkar egentligen metoden slutresultatet?

Det är bra att det finns metoder, utan dessa skulle  skapandet av it-lösningar vara en än mer svårlöst uppgift och jag tror valet av metod (SCRUM, RUP mfl.) är av stor vikt för hur tidsramar och produkt svarar upp till en kravmängd.

Men är det ”rätt” krav och avvägningar som adresseras givet det tänkta verksamhets- och användningssammanhanget? Vad och varför-frågor riskerar lätt att hamna mellan stolarna. Projektet kan med andra ord hålla tiden men resultatet i användning – i verksamhetssammanhanget kan vara en besvikelse. Den andra extremen är ett försenat projekt där lösningen blir en succé. Det är helt klart att vissa metoder är mer öppna för att krav/behov behandlas mer flexibelt under projektets gång men jag tror generellt på att ett ökat fokus på verksamhets/användarbehov och effekter skulle ge fördelar.

I dagsläget känns det som att metoder och ansatser som tagits fram (de som används idag) gjorts av personer som främst arbetat med implementation av programvara. Fokus blir då lätt på en effektiv utvecklingsprocess ur ett implementationsperspektiv.

Det är ytterst viktigt att it-projekt drivs mer i termer av affärsutvecklingsprojekt och metoderna måste därför ligga mer i linje kring hur en verksamhet i allmänhet utvecklar sina koncept/produkter och idéer. Samtidigt är det viktigt att projektet drivs kostnadseffektivt och levererar en it-lösning av hög kvalitet baserad på en väl genomtänkt och stabil arkitektur. Vad, varför, hur (process), hur (teknisk lösning) samt förväntade effekter måste i många fall balanseras bättre.

Utfallet av en it-investering påverkas ju trots allt av hur lösningen fungerar i faktisk användning i ett sammanhang. Jag är övertygad om att ux-kompetenser kan bidra i mycket större utsträckning och betydligt tidigare i arbetet med nya it-lösningar genom att arbeta mer integrerat med krav- och verksamhetsfrågor för att uppnå tänkta effekter i användning.

2 reaktioner på ”Vad, varför, hur och hur

  1. Tror också det blir fel om man sätter igång med t.ex. SCRUM direkt i ett projekt. Risken blir då att backlogen kommer bestå av endast beställarens önskemål, inte användarens.
    Varje utvecklingsprojekt bör börja med en ordentlig kravfas. När man har alla målgrupper, behov och prioriteringar klara för sig kan man börja jobba agilt (eller motsv) i tvärfunktionella team innehållande utvecklare, interaktionsdesigners, testare osv. Innan dess finns det liksom ingen mening med att involvera dessa roller.

  2. Jag tycker du tar upp en mycket intressant aspekt där, att många av de att metoder och ansatser som tagits fram gjorts av personer som främst arbetat med implementation av programvara. Inte minst är det uppenbart när man studerar hur SCRUM och Agila metoder, som är så populärt i dessa dagar. Inte minst vittnar denna beskrivning av metodens User Stories hur metodens förespråkare ser på problematiken med att avtäcka användarbehov:

    At the start of a project, capture an initial list of User Stories up-front. In Scrum this would be the initial Product Backlog. This feature list is useful for estimating and planning. But defer capturing all the details until the story is prioritised and due to be developed in the next Sprint or iteration.
    In meetings with users (or user representatives), users will often tell stories about the failings of their current system or process. Or they might tell stories about how they see things working better in future. Try capturing these stories as User Stories. On cards. While you’re in the meeting. As they are told.
    In traditional development projects, these stories often aren’t captured as they are told, they’re captured in a lengthy analysis process and captured in a lengthy document; a format that isn’t particularly user friendly.
    Using User Stories, you might be surprised just how easy it is to leave a meeting with users, with their key requirements already captured.
    http://www.agile-software-development.com/2008/01/user-stories.html

    Här beskrivs användarstudier som en relativt enkel och straightforward metod där utvecklarna själva går ut och pratar med användarna och ber dessa beskriva vad problemet är. Ajajaj…

    Det finns å andra sidan vettigare förespråkare av SCRUM/Agile som hävdar att UX- arbetet ska föregå hela utvecklingsarbetet i en egen s.k. UX-sprint. Detta låter mer rimligt och mer i linje med det fokus på implementationsfasen som metoden faktiskt har.

    Vi får se var vi hamnar. Jag hoppas bara att de rådande diskussioner som finns om mer totala Agila projektmetoder leder fram till en metodik där det visas lite mer respekt för avtäckande av användningsbehov och slutlig användningseffekt, vilket de facto är det som ger reell ROI för beställaren.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s