En modell för prioritering

Visst vore världen underbar om vi kunde göra allt vi ville?! Om vi hade all tid i världen, ständigt fyllda av positiv energi, vadandes i drivor av betalningsvilliga kunder som gladeligen väntade på sin tur…

Riktigt så verkar det inte fungera.

Tyvärr kräver våra “moderna” liv prioriteringar; familj framför arbete, löpning är viktigare än en öl med en bekant, skriva blogg i stället för att sova. Ständigt krävs nya prioriteringar och beslut i en aldrig sinande ström. Eftersom vi inte kan göra allt vi vill göra måste vi välja. På samma sätt är det när vi utvecklar produkter eller system. Detta inlägg handlar om det svåra arbetet att prioritera inom utvecklingsarbete.

Prioritering handlar i grund och botten om det svåra beslutet att välja att lägga sin tid och energi på det som jag just nu anser viktigare än annat. Samtidigt väljer jag bort detta andra. (Det här sista brukar kallas för att “prioritera ned”, vilket ungefär är lika ologiskt som barnens “jättelite”.) Frågan är bara, vad finns att välja på? Och vem bör välja?

Det första vi måste inse är att prioriteringar och val finns på olika nivå. Figuren nedan ska föreställa en slags prioriteringsmodell. I modellen har jag valt att lägga den grövsta nivån av prioritering underst (stora block ligger alltid underst). Denna nivå kallas ofta för produktportfölj, det vill säga att vi prioriterar mellan olika produkter. Så här kan det låta: “Öka på Modell CX, lägg ned aktiv utveckling av Card Reader”. Denna typ av prioritering förefaller rätt vanlig idag bland produktutvecklingsföretag.

Prioriteringsnivåer: Produkt, Intressent, Tema, Funktion, Scenario, Implementation

Om vi kliver upp en nivå i modellen hamnar vi mitt i vidareutvecklingen av en produkt eller kanske ett egenutvecklat, internt IT-system på ett företag. På denna nivå måste prioritera mellan intressenter av systemet. Den här typen av prioritering är vanlig idag, men görs enligt min mening ofta på ett ganska indirekt sätt, kanske genom att godkänna ett projekt eller genom hur en kravspecifikation utformas.

Nästa nivå av prioritering är något som vi kan kalla teman, användaraktiviteter eller funktionella block, det vill säga större funktionsområden för produkten. Ett exempel på det här kan vara att rapportmöjligheterna inför årsrapporten är viktigare än administrationstjänsterna. Om du arbetar med flexibel (eller “inkrementell”) kravhantering, en del av moderna utvecklingsmetoder, arbetar du fram detaljerna i behoven parallellt med utvecklingen. Här finns alla möjligheter att prioritera. Typiskt kan man göra detta någon gång i månaden eller kvartalet i samband med en övergripande planering av en ny version. Intressant är att om vi öppnar denna möjlighet varierar ofta prioriteringen kraftigt – ett tydligt tecken på att den behövs.

Vi kan gå längre än så. På högre nivå måste vi besluta mer precist vilka funktioner eller “stories” vi vill utveckla. Använder man Scrum eller någon annan lättrörlig utvecklingsmetod görs detta typiskt vid förberedelserna inför eller vid en iterationsplanering. Det handlar helt enkelt om att man som produktutvecklingsledare någorlunda vet vad något är värt och hur mycket det kostar så att man kan välja det som ger mest värde för företaget. “Ska vi utveckla den snygga produktpresentationsrutan eller ska vi gå in på platsönskemål?” kan vara en typisk prioriteringsfråga på denna nivå.

Nästa möjlighet till prioritering hittar vi i scenarier – eller testfall som en testare skulle säga. På hur många sätt kan funktionen köras igenom? Vilka felsituationer kan uppstå? Vilka scenarion är viktiga att stödja just nu och vilka kan vi vänta med? Notera att det här kan vi bara göra om vi för varje funktion beskriver ett antal exempel som vi vill se fungera. Alla dessa kommer inte att kännas lika viktiga. Är det till exempel viktigt att visa ett meddelande om att en sökning fick noll träffar eller räcker det kanske att man ser en tom träfflista till vidare och i stället lägga tiden på validering av kreditkortsnummer?

Och det är faktiskt inte slut här! Inom varje testfall, hur implementationen utförs, finns ett stort antal prioriteringar att göra. När nu funktionen ska utformas finns givetvis saker i användargränssnittet som inte är lika viktiga som andra. Exempel: “Ska länken verkligen få en ny bild och ny text när fliken är utfälld?”. Och givetvis har utvecklare och testare sina egna tekniska beslut och prioriteringar att göra.

Så vad vill jag säga med allt det här? Jo, att prioriteringar inte bara finns på övergripande nivå (portfölj eller projekt) utan kan faktiskt göras ändå ned till den minsta implementationsdetalj. Och det visar sig vara en essentiell egenskap.

Nu har vi en gemensam modell att utgå ifrån. I mitt nästa inlägg tänkte jag försöka beskriva varför det är viktigt med alla dessa nivåer och vem som egentligen bör prioritera. Tills vidare, fundera på om ni inom er organisation gör medvetna prioriteringar på dessa nivåer. Hur högt når ni?