Tips för att närma sig intressenters visioner och mål: Nuläge

13 04 2015

Fick en fråga från nybliven produktägare som undrade om bra tips på hur man närmar sig intressenters visioner och mål. Här är några av mina tankar, även om det kan göras på 1000 olika sätt. Hoppas gladeligen på kommentarer och länkar till andra idéer och bra artiklar.

Vision
Kortsiktig eller långsiktig vision?  Beroende på det gör jag lite olika men gemensamt för dem båda är att jag vill bilda mig en konkret uppfattning om NUET först.  Genom att förstå och beskriva hur en produkt, tjänst, feature eller något annat fungerar just nu så uppstår visioner, det är iaf min erfarenhet.

En affärsstrateg föreslog just detta. Lägg 80% av tiden på att förstå nuet, och 20% av tiden på att förstå och beskriva framtiden så är du hemma. Det stämmer med min uppfattning.

Att beskriva nuet

Generellt gillar ju de flesta att visionera, brainstorma, tänka trender och fantastiska framtider. Att lägga tid på att undersöka nuet är inte lika populärt alla gånger. ”Har du verkligen tid med det här” är en vanlig fråga. Genom att timeboxa och återkomma till argumentet ”Om vi inte vet var vi är nånstans på kartan, hur ska vi då veta vilken riktning vi ska ta för att komma fram?”  så brukar jag få/ta mig tiden att beskriva.

Några verktyg och metoder:

1. Observationer

Hitta möjligheter att på plats observera hur dina användare, intressenter, målgrupp använder din produkt/tjänst just nu. Genom t.ex studiebesök eller att bjuda in en grupp som du ber genomföra en del uppgifter och titta på hur de gör. Detta går också virtuellt. Be din kund visa hur det ser ut på hans skärm på distans, att dema hur han jobbar, eller sätt upp user test miljöer genom t.ex http://www.usertesting.com/.  och liknande.

2. Inspelningar

Med hjälp av verktyg som t.ex http://www.clicktale.com/ och http://www.sessioncam.com/
 eller In product analysis kan du följa hur användaren rör sig genom applikationen. Ibland känns det långt borta att få köpa, installera ett sådant verktyg, men genom gratis trials och visa de som har pengarna hur bra det är så brukar acceptansen komma med tiden.

3. Enkäter & intervjuer

Lite annan sorts information får du genom att sätta upp enkäter på din webbplats, eller genom andra forum. Bästa insikten vid enkäter är generellt citaten snarare än vad man kryssat i för alternativ. Citat säger ibland mer än tusen ord om hur de uppfattar och använder din tjänst.  Se till att designa enkäten så att fria kommentarer blir naturligt. Vid intervjuer brukar jag försöka få dem att berätta snarare än beskriva. Berättelser från verkligheten snarare än ”vad tycker du”-frågor.  Nedan beskrivs närmare vad jag menar :-)

http://incontextdesign.com/articles/dont-ask-your-customer-comic/

4. Sammanfatta genom scenarios

Beskriv det du lärt dig om NUET genom scenarios – visuella eller textuella.  Nedan är ett fiktivt exempel från verkligt projekt som kanske inte säger just dig så mycket, men visar hur ett scenario kan se ut. Hade jag varit designer hade det naturligtvis varit mycket snyggare, men jag har insett att bättre rita fult än inte alls..

Nu-scenario email Bild1

Ett textuellt scenario kryddat med känslor kan se ut så här:

Namnlös

Tack @soapui @readyapi för den emotionella insynen av viss del av målgruppen :-)

Och så kan man göra långa mer eller mindre dramatiska berättelser som beskriver just din kunds upplevelse.

Det finns massor av exempel om du googlar på ”CX” som är det nya begreppet, eller ”customer scenarios” eller ”customer journey” mm.

Min poäng är att det behöver inte vara så proffsigt, snyggt eller ens strukturerat så länge som du beskriver din förståelse av nuet i form av scenarios med hjälp av bilder eller text, eller både och.

5. Value Prop Canvas

Mycket trevligt verktyg för att beskriva nuet. Genom att förstå och beskriva din produkts Value proposition blir det betydligt lättare att identifera vision. Vad är din produkts kärnvärde? Vad gör att dina kunder köper den och dina användare använder den? Vad är deras Gains och Pains när de använder produkten?  Läs mer och prova själv med dina intressenter.

value_proposition_canvas

Det finns ju många fler verktyg, detta var några av mina favoriter.

När du beskrivit nuet kan du fundera på framtiden, visionen. Och det får bli i nästa inlägg..





Produktägaren – domänexpert eller processguru?

3 03 2015

Efter ett samtal häromdagen om produktägarrollen på en organisation så började jag fundera igen över detta.
Vad är det för slags produktägare man ska tillsätta, om man nu som beställare, chef, processägare eller något annat vill ha en sådan roll i sin utvecklingsorganisation?

Är det den person som kan bäst om domänen man verkar i – försäkringar, marknadsföring, administration, kundservice etc? (kan ibland vara superanvändare).
Eller är det någon som är proffs på utvecklingsmetoder, systemutveckling, processer, användbarhet etc i allmänhet? Någon som levt och verkat i utvecklingsmiljöer.
Eller är det affärsägaren – den som faktiskt ansvarar för att affären eller verksamhetsnyttan går hem? Ofta en linjechef av något slag.

Jag har sett olika varianter på detta och naturligtvis finns inget rätt svar. Min slutsats är att oavsett vilken av dem man väljer så:

1. kommer den personen behöva ordentilgt avsatt TID – dvs bli av med andra uppgifter.

2. personen kommer behöva lära sig ordentligt något utanför hens normala zon. Är man domänexpert/superanvändare behöver man t.ex lära sig utvecklingsmetodik på riktigt. Är man process-proffs behöver man lära sig domänen och marknad. Är man affärsägare behöver man lära sig UX-metoder etc. Tid behöver ägnas åt detta och ibland investering i utbildning och liknande.

3. personen kommer behöva stöd av någon av de andra rollerna för att lyckas i sin produktägarroll. Processproffset kommer behöva enkel tillgång till superanvändare och domänexperter som kan vara med i designdiskussioner och delta i acceptanstest, dvs kunna ägna tid åt utvecklingen. Affärsägaren kommer behöva ett processproffs som kan fokusera på behov & kravställning, domänexperten kommer behöva en tillgänglig affärsägare för att kunna fatta affärsmässiga beslut etc.

4. personen behöver ett tydligt mandat – mer eller mindre, bara det är tydligt.

För den som sett en produktägarorganisation riggad på detta sätt, har troligen också sett de resultat man vill åstadkomma med agila metoder – dvs bättre time to market & bättre värde till kund

Tyvärr behandlas produktägarrollen i de flesta organisationer slarvigt. Man tillsätter någon som känns rätt, utan att ge den det stöd eller framför allt den TID som krävs för att få full nytta av rollen. Sedan säger man att man jobbar ”agilt” fast utvecklingsteamen och leverantörerna fortfarande inte har någon riktigt närvarande att kommunicera med utan kör sitt race som vanligt. Alternativt en alltför teknisk produktägare som inte uppmuntras till att kunna och faktiskt få ta ett större affärsansvar.

Om den ideale produktägaren, t.ex en affärsägare, helt enkelt inte KAN flyttas från sina ordinarie uppgifter, kanske är det bättre att hon medverkar som aktivt affärsstöd istället till någon annan utsedd produktägare – t.ex en superanvändare eller processexpert?

När jag sett produktägarrollen fungera så har det inte spelat någon roll vilken av ovanstående som varit produktägare, utan skillnaden har bestått i NÄRVARO, TID samt ordentlig backup på det område hen inte är expert i.

I den gamla metoden XP – Extreme Programming, föreslog man ration 1-1 av kodnära utvecklare och andra roller i teamet  t.ex som nedan:

Skärmavbild 2015-03-03 kl. 12.04.38

Process-stödet (t.ex en Scrum-master, teamcoach och liknande) finns inte i XP om jag minns rätt, men ofta behövs också en sådan roll något beroende på teamets storlek, uppgift och mognad.

Testaren har jag lagt till som en egen roll, beroende på teamets uppdrag och kvalitetsmognad behövs också en sådan. Testaren har jag också sett vara ett ovärdeligt stöd till produktägaren i fråga om både kravställning, acceptans, användningstest mm.

Detta är motsvarande heltidare. Dvs om man har en UX på 50% så borde också en av kodnära utvecklarna vara på 50%… för att hålla ration. Om du vill ”fördela” testaren eller UX:aren på 2 team på 50% vardera, har du också tänkt fördela en av utvecklarna på två olika team? Det hänger också på reell närvaro (fysiskt eller virtuellt) för att fördelningen ska fungera. Dvs en testare som aldrig är delaktig i utvecklingsteamet på riktigt, gör antagligen inte så stor nytta som hon skulle kunna.

Jag vill helt enkelt slå ett slag för XP igen och att alla som beslutar om produktägarskap tar sig en funderare på vad man vill uppnå. Räcker det med att någon får hatten Produktägare för att öka nytta, kvalitet och time to market?  Eller krävs helt enkelt en ny och mer seriös approach till det utvecklingsarbete som är av mindre teknisk art för att våra nya metoder ska löna sig?

Heja alla produktägare därute som gör sitt bästa för att få någonting gjort på sin lilla tid och kämpar för att hålla takten i analys, kommunikation, visionerande, utredningar, planering och uppföljning av utvecklingsarbete, acceptanstest, marknadsresearch, kundstudier….





Vad är krav?

26 01 2015

Häromdagen hörde jag en presentation av en person som jobbar på ett spelföretag. Han sa att de inte arbetar med krav alls. Vad jag hörde var att de inte har den gamla formen av kravanalytiker som sitter och samlar och specificerar allt de kommit fram till, för att sen föda utvecklare med dessa specifikationer. I stället låter de spelutvecklarna testa och experimentera fram olika varianter tills något känns bra. De har också en relativt stor grupp hängivna spelare (användare) som får pröva spelen tills de identifierar vilka som faktiskt är bra och roliga och då eventuellt släpper de spelen. Han sa att endast en bråkdel av spelen faktiskt når ut i produktion.

De arbetar också mycket med test, förutom användningstesten så automatiserar de test av sådant som bara måste fungera gång på gång, typ login och annat. Dessutom har de fasta regler att förhålla sig till, t.ex från API:er (gränssnitt) med tjänster som de använder, t.ex Facebook, Google mfl. Och det är ju bara att följa de gränssnittsspecarna.

I mitt huvud tänkte jag, men! Ni jobbar ju visst med krav! I alla fall enligt min personliga tolkning av vad krav faktiskt är. Det är bara så att ni jobbar mycket mer modernt och snabbt med kravarbete än vad många andra gör.

Det ni gör när ni experimenterar och släpper lös den kreativa sidan hos utvecklarna, testar med spelare och automatiserar gränssnitt och studerar och programmerar utifrån API-specar är ju också krav!

Fast ”Krav” är ett olyckligt ord. Just här använder jag ”krav” som ett samlingsord för alla tekniker, metoder och arbetsuppgifter som leder till förståelse av vad användarna faktiskt behöver och beslut om vad som ska ut i drift eller inte.

”Krav” för mig kan uttryckas muntligt, skriftligt, som en teckning, en modell, en skiss, en dialog, som ett test, som programkod, en första version av mjukvara. Någon sa att den enda sanna kravspecen är programkoden, och det håller jag med om, även om den kanske inte är så läsbar för alla. Programkoden talar faktiskt om för maskinen vad den ska utföra. Det mesta som inte är programkod är tankar och idéer som uttrycks på mer eller mindre luddiga sätt.

”Krav” är analysarbete. Att göra en prototyp av ett spel, eller en tjänst och att låta testa den samt studera och dra slutsatser av resultatet och förbättra eller förkasta är också analysarbete.

Problemet är att ”Krav” är ett så dåligt ord eftersom det associerar direkt till långa kravspecar.

”Krav” kan i min värld vara t.ex:

– En backlog
– Ett experiment eller en prototyp
– En skiss på en näsduk eller whiteboard
– En begrepps/informationsmodell eller domänmodell (vilket ord man nu föredrar..)
– En användarberättelse (user story eller en hel text om kundens resa genom systemen)
– Ett testscenario
– Feedback från någon
– En vision förmedlad av någon (användare, utvecklare, vd, medarbetare, marknadschef, säljare, kundtjänst…)
– Ett kommunicerat mål
– Regler definierade av någon

Jag vill dumpa ordet ”krav” och det är antagligen det vi måste göra för att komma loss från de långa kravspecarnas och användningsfallens bojor. Fenomenet i sig: att analysera, förstå, testa, undersöka, följa upp, visionera & designa försvinner dock inte för att vi dumpar ordet ”Krav”. Det är fortfarande en nödvändighet för att få något värdefullt ut av den mjukvara vi producerar.

Att hej vilt koda utan mål, mening, vision eller feedback vore hrm.. intressant.. att se resultatet av. Jag tror att den här killen från spelföretaget ville säga att de kodade hej vilt och ”kravlöst”, men faktum var att de verkar väldigt strukturerade i sin metod att experimentera och samla in feedback, förstå spelarna och jobba med visioner.

Kravspecifikationen då? Har den spelat ut sin roll?
Ordet i sig, ”kravspecifikation”, måste vi nog också göra oss av med för att bli av med dokument som ingen varken läser eller förstår, förutom den som skrev den.

Specifikationer och dokumentation av olika slag däremot kommer vi fortsätta behöva. I olika grad beroende på hur många beroenden vi har och hur stor vår affär eller verksamhet är. Att publicera ett API/webservice för någon internt eller externt att använda utan någon form av dokumentation blir… svårt för de som ska använda den. Att förvänta sig att mjukvara hos myndigheter, banker eller andra regulerade verksamheter ska anpassa sig till lagstiftning utan någon dokumentation av lagarna blir också.. svårt. Det är också specar.

Att gång på gång undersöka och muntligt sprida affärs- och verksamhetsregler i en stor organisation blir också… svårt. Lyckas man dokumentera dessa regler på ett läsbart och hållbart sätt så kanske man inte behöver så många fler specifikationer.

Problemet med specifikationer är inte att de finns, utan att de är för omfattande, att de snabbt blir inaktuella och beskriver design och andra delar som konstant förändras och att de är svårtillgängliga.

Utmaningen är att specificera tillräckligt lite.

I spelföretagets fall så höll de sina specifikationer i form av automatiserade testfall. Genom att titta i de specarna så förstår man hur spelen fungerar.

Jag har sett verksamheter där man faktiskt har en lätt tillgänglig källa över domänmodellen (informationsmodellen) som uppdateras med exakt vilka koder som betyder vad och vilka regler som gäller.

Det går.

Men kanske går det inte att prata om ”krav” och ”specifikationer” längre. Det för med sig en ryggsäck som vi inte vill ha.

Min ambition är att jobba med både krav och specifikationer utan att prata om dem.





We want parallell (agile) & predefined (waterfall) requirements at the same time.

19 01 2015

I believe we are many in the same situation. At the same time as we are developing the software we define the requirements in different formats – verbally, written or as drawings & models. Also we define our requirements in parallell with other projects who are dependent on our project or vice versa, and who already have started development.

This is basically something good. Previously many did the specifications up front – sometimes for months or years (!), then handed over to development who tried to understand and implement what was written. This led to many errors so the ”requirements phase” has basically disappeared completely.

I have many good experiences from working with requirements in parallell with development. It’s pretty messy and frustrating for everyone, but in the end, the result seems to get a bit better off.

The problem arise when the organization do want to work like this, and at the same time expects the product owners, business analysts, solution architechts or whoever works with requirements to have ALL the answers exactly specified completely for every conversation.

”If you can’t give us a complete specification this week on feature x then we cannot commit to give you any delivery for the next 8 months, and possibly not at all”

-”But, in order for us to give you a good spec we need to see your first version of the software so we know where the gaps are, and can fill in the blanks”

I have seen this many times. You don’t want a 6 months requirements specification phase, because you know this will generate too many errors. Still you don’t want to accept that by removing this you DON’T have a complete specification to offer, you DON’T have the answers to new or modified business rules and you actually HAVE to have a development process that deals with this.  (There are many available..)

It seems so hard for many organizations to accept the fact that there is no specification and to adjust the processes to fit with the new reality of requirements discovery during development.

Those organizations who learns how to facilitate the new way of working by building in these facts into agreements with suppliers or dependent organizatons will succeed.

And those who have realized you need people who spend more or less 100% of their time with requirements investigation, disvovery, design in the teams & projects will also have a better chance to succeed. In mature teams, with time, the ”agile” requirement process will settle but it needs attention, competence and focus.

We’re in the middle of a change and too many are trying to work both in the old and the new way with requirements. This creates only more mess. Let’s accept the new form of working with requirements in parallell with development, and adjust our organizations, agreements and contracts to this.





Kundupplevelse vid sök av resa

22 11 2014

Nu råkar jag ju själv arbeta för ett reseföretag så med stor risk att kasta ett helt gäng stenar i glashuset vill jag ändå dokumentera min frustration och feedback till alla – ALLA – researrangörer därute, även enkla fjällanläggningars hemsidor.

Nu talar jag som kund, med relativt stor summa pengar att spendera på just ert reseföretag.

Får också en dejá vu, tror minsann jag bloggat om detta tidigare för ett antal år sen, men eftersom ingenting förbättrats under den tiden så fortsätter jag.

Med lite insyn i resebranschens system, så har jag trott att det finns tekniska skäl till att alla resesiter ser likadana ut när man ska söka en resa. Att Amadeus eller något annat gammalt system helt enkelt gjort det för svårt att göra webbsidor som gör det lätt att hitta en resa.

MEN.. tyvärr går det inte ens att skylla på det. När jag alldeles nyss skulle kolla upp en enkel skidresa till fjällen för en familj under jul, så inte kan det väl vara Amadeus eller något gammalt resebokningssystem som varit orsaken till att de har exakt kopierat sökgränssnitten för de stora resesiterna.  Allt jag skulle kolla upp var boende, tillgänglighet och pris ungefär runt jul/nyår.

Mina två frågor: ”Finns det något ledigt för 2 vuxna + 2 barn” i december/januari och ”vad kostar det”?

Jag måste istället för att få en översikt, ange exakt ankomstdatum och avresedatum, och försöka gissa mig till vilka kombinationer av veckodagar som kan vara rimligt. Onsdag-söndag? Fredag-söndag? Måndag-onsdag? Efter 5 min ger jag upp och bestämmer mig för att ringa och fråga någon dag. Hade jag fått svar på min fråga kanske jag hade bokat redan idag.

Varför, varför undrar jag kan inte dessa fjällsiter bara presentera en enkel matris, som i de gamla tidernas kataloger, över vad som finns ledigt?

Om jag minns rätt såg en sådan tabell ungefär ut så här en gång i tiden, förenklat:

Skärmavbild 2014-11-22 kl. 21.48.23

Med någon röd/grönmarkering i dagens digitala värld skulle det kunna visa om det var ledigt eller ej.

What’s the problem..?

Varför är det ingen som gör detta, på någon resesite någonstans. Undrar jag.

Damma av de gamla katalogmatriserna, gör de lite levande och är det för krångligt att utveckla webb nuförtiden, så varför inte bara lägga upp en aktuell PDF om dan? Det skulle få pengarna att klirra in, konverteringen gå på ett bums..  i juletider är det väl inget problem att sälja i vilket fall som helst, men alla andra dagar?

Snälla Funäsfjällen, Åre, skistar, eller för den delen valfritt resebolag, ge mig en matris och jag ska ge er mina pengar.

Och jag beskriver gärna närmare mitt problem med dagens sökning, och idéer om hur det skulle bli enklare.





Varför Pride är viktigt för en hetero

2 08 2014

Hade än en gång en liten anledning att göra ett besök på Pride-festivalen i Stockholm. Med mina barn viftandes med regnbågs-flaggor på vägen därifrån, fick jag fråga från 8-åringen ”varför är den här festivalen?”. Efter några ord om att det är viktigt för att alla ska få tycka om alla och att män ska få pussa män o kvinnor kvinnor om de vill och att folk hamnar i fängelse för det fortfarande idag, så slog det mig också att det som firas o symboliseras under Pride, iaf gör jag det, är också ett stort uttryck för tolerans – för alla slags olikheter, utseenden, intressen o människor. Inte bara hbtq, utan t.ex även funktionshindrade får under festivalen en särskild respekt. Jag menar, en festival som har seriöst uttryckta fartbegränsningar för permobiler.. är helt enkelt mer inkluderande än de flesta andra..

Främlingsfientlighet går hand i hand med homofobi och allmän intolerans mot.. allt.
Hbtq-rörelsen vågar jag påstå från min kammare går hand i hand med stark tolerans för kulturer och minoriteter och socialt hindrade i allmänhet.

Du kan säkert komma på någon bög du träffat nångång som var nazist eller sverigedemokrat, men jag kan det inte.

Därför är det viktigt att fortsätta fira, stötta och flagga för Pride även för oss hetero-svennar som för det mesta håller oss till normerna.
Att flagga med regnbågsflaggan är att flagga för frihet att tycka om vem man vill, för allmän tolerans och inkluderande av konstiga eller bara främmande människor, för yttrandefrihet och tryckfrihet, mänskliga rättigheter och inte minst att flagga för fest!

Och hur sjutton kan det i så många länder vara lagligt att slå barn, men olagligt att vara kär i någon??

Happy Pride, Leve friheten och mångfalden!

bild





Word of the week: Sustainable

11 06 2014

I was at an organization where the top management changed more or less every year.
At another well reputed organization where some of my friends used to work and deliver good stuff, BAAM, top management changed or it got bought or something and then it changed from a team-oriented organization to a very bureaucratic top-down way of work.

A third one, smaller, same thing happen and within a few months the crew was gone.

At a forth one..  I can give you thousands of stories of companies and organizations who seriously changed in very short time. If these organizations are still successful today, more successful or less successful I don’t know.

At one organization, an academy, not much changed at all, bits and pieces now and then and sometimes a small change could take 250 years. Is this academy successful? 

What are you’re criterias?

The academy keeps, as far as I know, ”delivering” awesome bright students.

The ”team-oriented” to ”top-down bureaucratic” organization I still believe have profit and a loyal customer base.

Some organizations die, some of them turn into something else, better or worse – who is the one to judge? The market?

The market is not always right. Just think about all those seriously successful industries.. which get so much profit, to the cost of humanitary and environmental disasters. Are they successful? They keep selling.

Was the .com era a failure? Oh NOOO way if you ask me! I too was part of ”portal site projects” stopped before launch ’cause of the crack in the bubble. But .com was successful, don’t you agree?

And for all those companies who might have got sucked in and died within HP or whatever huge enterprise, how long would they have succeeded, how long would their technology have stood up for the seriously high pace of their competitors with much cooler stuff.

What makes a sustainable company? How long will HP be around? SAP? H&M? Twitter..? Myspace?

I think Google will be around for a while. As HP. Will Apple?

But all those ”we have such a cool map/search product, it can draw you a map very easy”.. well they disappeared or live a tiny existance today. 

The owners, the entrepreneurs, they keep going on most of them even after something happened to their baby. Taking what they learned and doing something new, wiser from the previous experience and possible with a contribution to technology development that get injected in someones project somewhere. Or they retire on that sought after palm beach.

What is sustainable? 

Kids are.

 

 

 

 








Följ

Få meddelanden om nya inlägg via e-post.