The ABC of Prioritizing

Hvis jeg skulle vælge blandt alle de værktøjer jeg har i skuret, så er mine favoritværktøjer nok fra hylden “prioriteringsværktøjer”. At være dygtig til at prioritere øger både effektivitet (da vi altid laver det vigtigste først), indtjening (da vi kun udvikler de ting, der giver kundeværdi) og medarbejdertilfredshed (da der er mere risikovillig tid til at eksperimentere, når vi ikke bruger tiden på ligegyldige aktiviteter). Se min slides nedenunder, hvor jeg beviser sammenhængen mellem prioritering, udviklingshastighed og medarbejdertilfredshed.

Se også mine slides 10 tips til brugercentreret produktudvikling, hvor tip 4-6 handler om prioriteringskultur, prioriteringspoker m.m.


Mine 10 tips til brugerdrevet innovation og udvikling

My 10 tips for user driven innovation and development.
Feedback og kommentarer modtages med kyshånd:)


Benjamin Interactive lancerer nyt modefællesskab

stylegallery_overview1.jpg

 I samarbejde med Costume og MSN Style har vi i Benjamin Interactive lanceret et nyt modefællesskab:

stylegallery.jpg

 

Hvad er styleGALLERY?

www.stylegallery.dk har modeinteresserede kvinder fra hele landet mulighed for:

  •  At søge inspiration til at sammensætte et outfit med f.eks. udgangspunkt i deres sorte nederdel.
  • At uploade egne outfits, samt følge andre brugere med lignende stil og evt. gemme favorit outfits til senere inspiration.
  • At se udvalgte outfits og få konkrete og nærværende råd og eksempler på sæsonens tendenser fra bla. Costumes redaktion.

Noget af det unikke ved styleGALLERY er at det skabes 50% af brugerne og 50% af redaktionen.

 

Værktøjer anvendt til at udvikle stylegallery.dk

stylegallery_proces.jpg

  • agile metoder (2 iterationer med 2 x prioriteringspoker)
  • 2 x fokusgruppe (quick & dirty)
  •  løbende brugertests og –feedback (quick & dirty)
  • persona/positionerings matrix
  • alpha/beta testing
  • Ruby on Rails
  • … likviditet og masser af hårdt arbejdeJ

Vi er ret stolte af resultatet  - prøv det på www.stylegallery.dk og giv os gerne feedback på feedback@benjamin.dk


Prioriter i starten… ikke i slutningen

Vi har for nyligt haft et års jubilæum med agile projektmetoder, som især bidrager med værktøjer til at prioritere. De nye simple metoder har gjort os dygtige til at:

  1. prioritere de 20% af ”knapper” som udgør 80% af brugsoplevelsen
  2. nå deadlines
  3. overholde budgetter (nogenlunde).

Desværre er der et sted hvor vi endnu ikke har succes med vores benhårde prioritering: De sidste detaljer før launch.Færdiggørelse ved hjælp af grovfilen…I teamet prioriterer vi åbent i alle intervaller – fra timer til måneder og fra små funktioner til hele porteføljen. Det er en kultur vi har skabt og som vi hele tiden skal og vil vedligeholde og forbedre. Prioritering giver os energi, da vi ved at vi arbejder med det rigtige og lader det uvigtige ligge. Desværre er prioritering også en aktivitet vi anvender, når vi nærmer os launch med hastige skridt. Så kommer grovfilen frem, og de mindst launch kritiske elementer bliver udskudt til efter launch.Nogle af de elemementer som oftest udskydes til efter launch er:

  • detaljeret kommunikation om tjenestens formål
  • lækre kontaktpunkter (feedback, email sign up, kundesservice funktioner, FAQ etc.)
  • tuning af grafikker og egen annoncering
  • gennemskrivning og strømligning af hjælpetekster efter sidste funktioner er på plads
  • end2end brugertest
  • 360 graders admin funktioner

Prioriteringen betyder at vi altid bliver færdige med produktet til deadline, men vi mangler ofte den sidste 1% af projektet, som bliver barberet de sidste dage op til søsættelsen. Den ene procent, som vi som projektteam har tendens til at negligere, da komplektetsgraden er lav, den opfattede værkshøjde er lille og projektmæssig risiko er ukritisk. Den sidste 1% er oftest kendetegnet ved at kæle for detaljer. Men for brugerne kan denne 1% udgøre en stor del af oplevelsen (se illustration), da teksterne er utjekkede, ukorrekte og dermed utroværdige. Links peger forkert og flere knapper giver ikke mening. De sidste detaljer før launch må ikke prioriteres!Min holdning er at de prioriterede 20% skal være 100% færdige til launch. Det er ikke de sidste detaljer, der udgår den store omkostning af det samlede budget, så de skal simpelthen masseres helt på plads. Den store omkosning er allerede barberet ved de 80% ikke-prioriterede ”knapper”, som omkostningen ved de sidste detaljer er minimal.


Der tælles ned til launch… fokuser dialogen

I projektets sidste faser er det ikke nok at alle på teamet har fokus på at sparke bolden i mål. Der skal også skabes en kommunikationskultur, der bidrager til en fælles vinderstemning. Manglende ”sense of urgency” skaber nervøsitet og frustration på alle niveauer.

Eksempel på ufokuseret kommunikation :
Fodboldholdet sidder i omklædningsrummet før straffesparkskonkurrencen i årets sidste kamp. Alle tænker på hvordan bolden skal bankes i nettet, mentalt gennemgår spillerne egne skridt til mål og glæder sig til at modtage publikums hyldest og drikke pils ovenpå sejren. Mikkel ”The coach” tjekker rækkefølgen en sidste gang. Spændingen er intens og ingen taler. Pludselig siger Søren: ”Vi skal også huske at lave en plan for, hvem der kører til hvilke kampe i næste sæson”.

Der er vist ingen grund til at grave i, hvorledes teamets ”sense of urgency” bliver påvirket af Sørens ufokuseret kommunikation.

Vis hinanden at I løber efter den samme bold…
Eksempelvis bør man i 11. time nøje overveje, hvad man kaster op til åben diskussion eller inspiration på teamet. F.eks. bør man ikke begynde at diskutere detaljer i tidligere eller fremtidige projekter, da det gør ens teammedlemmer opmærksomme på, at fokus ikke er kollektiv og negative kontrolmekanismer starter op. Det skaber frustration og eventuelle konflikter i en vigtig, intensiv og måske i forvejen anspændt periode. Selvom emnet om tidligere eller fremtidige projekter måske er relevant og vigtigt, så samler det ikke den nødvendige fokus lige før man skal løbe over målstregen.

Houston, we are ready to launch… 10… 9… 8… ”anybody seen the donuts?”… 7… 6… ”Will be back in half an hour”… 5… 4… ”maybe we should consider a blue rocket next time”… 3… 2… 1… 1…. 1!… press that button for f… sake!


Gør driftopgaver til små successer…

I mit team arbejder vi næsten udelukkende med udviklingsprojekter, hvis kompleksitet kræver dedikering for alle i båden. Derfor er det møj-belastende hele tiden at blive afbrudt af “Kan vi ændre farven til rød?” eller “Der er en stavebøf i FAQ’en?”.  Da 9 ud af 10 driftforspørgsler ikke er kritiske, er det fjollet løbende at afbryde et projektmedlem med demotivation til følge.

Løsning: Man – tors = projekter, fredag = drift

Vi har derfor genopfundet “HOLY FRIDAY”: Ugens første 4 dage arbejder hele styrken på projekter og om fredagen laver alle drift.

Vores kollegaer kender HOLY FRIDAY og der er derfor helt legalt for projektmedlemmerne at sige “Er du sød at sætte din forspørgsel på fredagslisten?”.

Det fede ved HOLY FRIDAY, udover at det skaber mulighed for fokus i hverdagen, er, at alle kan skabe et par små successer inden weekenden. I projekterne er der i sagens natur længere mellem successerne, hvorfor afkrydsning at driftopgaverne på fredagslisten fungerer som små afslutninger og dermed successer.

Eventuelle drama bliver selvfølgelig håndteret øjeblikkelig uanset ugedag:)

BONUS: Holyfriday medfører også at vi ikke har noget drift/support team – det er de kollegaer der har lavet produkterne der selv udfører supporten om fredagen. Altså når det gør ondt på kunderne, gør der også ondt på produktudviklerne, hvilket skaber øget viden og incitament til at lave gode produkter – dumme fejl finder altid hjem igen.