Har du råd att inte prioritera?

I mitt förra inlägg presenterade jag en modell för prioritering med olika nivåer. Inget speciellt överraskande eller provocerande där, kanske. Anledningen till att jag tycker att prioritering inom utvecklingsarbete är värt att skriva om är två fundamentala poänger som jag tycker inte uppmärksammas tillräckligt:

  1. Inom produktutveckling kan de minsta detaljerna vara avgörande. Hur många iPhone har inte Apple sålt efter att människor har sett och känt på den underbara rullfunktionen? Eller ett annat exempel: Hur rappa systemsvar till användare i en stressad miljö kan utgöra skillnaden mellan acceptans och motvilja. Hur “läckert” eller användbart systemet är ner till minsta pixel kan vara avgörande för dess framgång.
  2. Prioriteringar görs, vare sig vi vill eller inte. Om inte rätt personer är på plats kommer prioriteringarna att göras ändå – helt enkelt för att de måste göras. Enda skillnaden är att de då görs omedvetet, alternativt av personer som inte ser helheten, inte helt förstår vad som är viktigt, inte exakt vet hur användarna arbetar eller hur företaget tjänar pengar.

I det här inlägget tänkte jag utforska prioritering på lite olika nivåer ännu mer. Hur fungerar traditionella metoder? Hur kan man nå högre nivåer och mer finkorning prioritering? Vem ska egentligen prioritera?

Låt oss börja med den rådande, det man kan kalla för den traditionella modellen (handen på hjärtat, det är ju mest en tradition, eller hur?). Hur brukar det fungera? Jag bedömer lite löst att konventionella metoder eller utkontrakterad utveckling ungefär når upp till nivå 1,5 i modellen (en bit över produktnivån). Prioritering görs ofta på produkt- eller projektnivå, men därefter är det sämre. Typiskt stödjs inte prioritering på finkornigare nivå än projekt/kravspecifikation.

Vad som i stället sker är en indirekt och omedveten prioritering på intressentnivå. Verksamhetsprocesserna är vaga. Beskrivningarna stämmer inte. Kopplingen till projektet är oklar. Användarna är osynliga. Användarroller okända. Kravspecifikationen är skriven och “allt är lika viktigt”. Det här är en beskrivning av en svag modell för prioritering eftersom 1. den är inte medveten 2. den görs på mycket grovkorning nivå när det egentligen är så att det finns både viktiga och oviktiga saker inom varje område som produkten rör.

Hur kan man då göra för nå högre nivåer på prioriteringsskalan? Det första vi behöver göra är att tydliggöra vilka prioriteringar som faktiskt görs så att de blir medvetna. En typ av prioritering mellan intressenter är den mellan olika verksamhetsprocesser. Ska vi stödja inköp med bättre lagerkontroll eller är det säljanalysen som behöver bättre underlag? För att göra detta behöver vi givetvis förstå hur våra verksamhetsprocesser ser ut och arbeta för att optimera flödet genom dem.

En annan typ av prioritering är den mellan olika typer av användare (roller). Vi skulle till exempel kunna välja att prioritera Adam, 21 år, från nätgenerationen eller är det kanske informationen till David, 28 år, finansanalytiker på SHB som måste bli bättre? För att kunna göra detta krävs en djup kunskap om sina kunder och användare. Det är tyvärr fortfarande skrämmande vanligt idag att utvecklingsteam “skyddas” från sina användare, vilket gör att kunskapen om dem är begränsad.

För att nå ännu högre skikt, prioritering på tema eller funktionsnivå, krävs ett regelbundet samarbete mellan kund och leverantör. Det här brukar de flesta agila/lättrörliga team klara av eftersom det är inbyggt i de agila metoder som de försöker följa. Tyvärr missar man lika ofta process- eller rollprioriteringen som jag nämnde ovan, vilket gör grunden som hela prioriteringen står på skakig.

Har vi kommit så långt vi kan nu? Absolut inte. Moderna, lättrörliga metoder är baserade på samarbete mellan roller. Det är svårt, men om vi utnyttjar samarbete har vi stora chanser att låta prioriteringen fortsätta i än mer detalj. Om vi har alla kompetenser på plats, varför inte utnyttja det? För att ta ett exempel: Hur kan programmerna avgöra om det är viktigast att lägga tid på att göra en läcker animering på startsidan eller lägga till en hjälptext vid formuläret som många missförstår? Det kan de inte, eftersom det både kräver kunskap om företagets affärsutveckling och användningen. På detaljnivå vid design av ett system kan en framgångsrik prioritering bara göras om områdeskunniga, specialister på användbarhet och tekniskspecialister alla får komma till tals. Tillsammans kan de göra välbalanserade avväganden i den aldrig sinande ström av beslut som måste fattas. Att rätt personer ges chansen att tycka till kan göra hela skillnaden.

För att sammanfatta: Jag är övertygad om att prioritering är viktigt ned till den minsta beståndsdelen av en produkt eller ett system. Det är därför viktigt att organisera arbetet på ett sådant sätt att prioritering på olika nivåer kan göras och dessutom ske i samarbete mellan rätt personer. Många arbetar idag på ett sätt som skapar obalans i utvecklingsarbetet. Är du som kund frånvarande eller oengagerad ökar risken markant för att det görs felaktiga prioriteringar, vilket leder till att du får fel sak levererad – eller kanske rätt sak men utformad på fel sätt. Hur som helst minskar värdet du får ut av din investering. Är du beställare av produkter eller IT-system, ställ dig gärna följande fråga när utvecklingsteamen kallar till nästa möte: Har du råd att inte samarbeta?