Kravhantering – kontraproduktivt?

Kravhantering, så som den bedrivs i IT-projekt idag, är slöseri med tid och resurser. Med tanke på hur många, särskilt inom användbarhetsområdet, som arbetar med kravhantering är det förstås en provokativ tanke.

Kraven finns där för att det är en stor lucka mellan affärs- och verksamhetskonsulternas abstrakta rapporter och den faktiska systemimplementationen de ibland förordar. Så långt allt väl. Men vad är kraven egentligen bra för? Vad försöker de beskriva?

Jag hävdar bestämt att krav är en artefakt av ett alltför ingenjörsorienterat arbetssätt. Ett arbetssätt där man trots allt uppmärksammat att man på något sätt måste definiera och specificera vad det är som ska göras, visst. Problemet är att så fort kraven är formulerade glömmer man varenda ord om vad, varför och för vem. Du kan ha kartlagt och skrivit personas, definierat scenarios, vad som helst, men när kraven finns där är det dom som styr. Obevekligt. Och i 9 fall av 10 levereras ett system som uppfyller tillräckligt många av kraven för att leveransen ska vara godkänd men som inte går att använda och som inte fyller nån affärsnytta.

Pengar i sjön.

Och det värsta är inte att jag säger dethär utan att det faktiskt händer. Igen och igen och igen. Och beställarna svarar med att försöka bli bättre och bättre på att skriva krav. Blir det det?

Inte så vitt jag vet.

Snarare har kraven förvandlats från generella ”bilen ska vara bränslesnål” till specifika ”bränsleinsprutningen måste vara kalibrerad till 0,00001% marginal”. Kontraproduktivt.

Därför har jag börjat prata om att krav är föråldrat. Vill man verkligen uppnå affärsnytta kartlägger man behov och förväntningar och matchar dem mot verksamhetens strategier och visioner.

Detdär är ju inget nytt för de flesta av oss. Men nästan alla arbetar fortfarande med krav och kravhantering – det är till och med en särskild yrkesroll och i linjeverksamhet har man ofta kravhanterare anställda; först tar man fram behoven, målen och konceptet. Sen simsalabim gör man krav.

Och där någonstans tappar man bort hela nyttan med investeringen.

Som en konsekvens av detta provar jag just nu med att strunta i krav. Det enda (sic!) som behövs är ju egentligen att kartlägga, prioritera och balansera alla intressenters behov och förväntningar, inklusive affärsstrategierna och målen. Sen dokumenterar man det i koncept, design rationale, lösningsarkitektur och interaktionsdesign. Hur exakt man går till väga beror ju på om man implementerar standardsystem, om man gör en app till en padda, eller vad det nu är, men i grunden är det ju inga konstigheter.

Självklart måste man ha koll på informationsarkitektur och verksamhetsregler och en massa andra saker. Men så fort man gör krav av dem blir det de som styr, inte nyttan eller meningen med hela investeringen.

Och hela meningen med det vi gör är ju att det ska bli nytta, nytta och ändamålsenligt!

Användbarhet och standardsystem – är det möjligt?

Spontant vill man svara ett rungande NEJ på den frågan och jag tror att de flesta som jobbat med den typen av lösningar är beredda att hålla med. Ändå köps de. Beslutet tas ofta av IS/IT och det baseras på att det passar ihop med IT-strategin, att man redan äger plattformen som en del i en licens man ändå betalar för och för att man har krav på sej att minska utvecklings- och förvaltningskostnaderna.

Men faktum är att detdär NEJ:et inte behöver vara så rungande. Nycklarna är tre -

1. Väl genomförd behovsanalys
Grunden anger förutsättningarna. Många projekt byggs på ett gungfly av lösa antaganden; antaganden om affärsnytta, om användarnas behov, om organisationens behov… Oavsett om du ska implementera ett handläggarstöd, en extern webb eller ett verksamhetsstödjande intranät måste du ha koll på följande faktorer -

• Affärsmål och de därmed sammanlänkade affärsstrategierna
• Verksamhetens och affärens nu och bör-lägen
• Kulturen internt, samt det interna politiska spelet
• Samtliga intressenters förväntan, både på företaget/organisationen och på ett eventuellt system

Förstår man ovanstående kan man koppla affärsmål, strategier, användarbehov, förväntningar och kultur till bör-läget varpå man kan börja ta fram en konkret åtgärdlista. Åtgärdslistan bildar sedan tillsammans med övriga faktorer underlag för effektmål och produktmål.

Nyttan av detta är tydlig i två olika lägen: dels när helt ny plattform ska väljas/köpas in – man vet helt enkelt vad plattformen måste kunna för att komma ifråga; dels när det redan finns en inköpt plattform (vanligare än man skulle önska) eftersom man då har ett bra underlag när den ska konfigureras för att fungera optimalt.

2. Dokumenterat stark produktkunskap aktivt tillgänglig
Majoriteten av standardprodukterna är väldigt flexibla… och oflexibla. Vissa saker kan konfigureras väldigt långt och kan fås att både fungera och uppträda mot användaren på olika sätt. Andra saker är oerhört stelbenta. Att ha en teknisk arkitekt som kan plattformen i sömnen är ett måste, och vet man redan i behovsanalysen vilken plattform det handlar om (som sagt – vanligare än man skulle önska) kan man löpande diskutera olika alternativa åtgärder/sätt att hantera behovet.
Att ha en sån person med är också en garant för att det som designas och implementeras faktiskt är optimalt både för användarna, ägarna och tekniken.

Jag brukar säga att vem som helst kan designa det perfekta tidrapporteringssystemet men bara några få kan ta fram ett som fungerar både tekniskt och för användarna – ALLA användarna. Det gäller särskilt när det gäller lösningar baserade på standardplattformar; för användarna kan det ibland vara mer eller mindre egalt om det är en dropplista eller kryssrutor men för systemet kan det vara skillnaden mellan att ställa om ett värde eller en veckas specialanpassning (som sedan gör att dedär vinsterna man ville göra i förvaltningsledet omintetgjordes).

3. Mikroanvändbarhet som en del i konfigurationsprocessen
Eftersom många av standardplattformarna är oflexibla på punkter som egentligen är avgörande för den vanliga användaren är det extra viktigt att de får hjälp i de små detaljerna. Här är enkla användningstester ett starkt kort. I praktiken betyder det att namngivning, visuella informationsstrukturer, placeringar och disposition/layout inte ska tas fram enbart av projektgruppen utan med stöd i kontinuerliga tester genomförda under själva implementeringen. Ska avdelningen/sektionen heta ”Om oss”, ”Om företaget” eller ”Om NAMNXYZ”? Gör enkla klicktester så ökar sannolikheten för att folk hittar rätt när de väl behöver vad-det-nu-är.

Undantaget är de fall när det finns starka skäl, kopplade till bör-läget, för centralt beslut, till exempel när namngivning, visuell informationsstruktur med mera är ett sätt att kommunicera identitet och riktning.

Medvetenheten om dessa tre nyckelpunkter innebär att sannolikheten att de nyttor man ursprungligen tänkt sej faktiskt kan realiseras, i tid och på budget, i ett system som faktiskt går att använda. Och inte minst det senare är ju vi UX och användbarhetsexperter intresserade av

Inte längre mobil mobil

Var går gränsen för när en apparat slutar vara mobil?

Jag är hyfsat nöjd med min iPhone. När folk säger att det är en dålig telefon svarar jag oftast att den inte är en telefon, den är en pytteliten bärbar dator – en kommunikationsmanick i miniatyr som man dessutom kan använda för att prata i telefon med. För det är så det känns. Att väldigt få lyckas göra appar till den som är innovativa på riktigt kan jag leva med. Utveckling tar tid, och just nu är det som när filmkameran kom – en massa stillbilder med lite ryck i, här och där. Men det kommer förändras.

Vad som stör mej är att den inte är sant mobil. Den är lite för stor för att man enkelt ska kunna ta den med sig, eller så kan det vara så att formatet inte riktigt funkar för mina händer. Den halkar lätt omkring, i alla fall, och är lite för stor för att funka i alla fickor. Redan innan den var inne för glasbyte (glaset sprack av sej självt, spänningsspricka) var jag också oändligt försiktig – den KÄNNS ömtålig, och ÄR ömtålig – men nu är jag närmast hysteriskt nogrann med var jag har den. Det påverkar mobiliteten negativt, helt klart.

Ytterligare en negativ faktor är priset. Missförstå mej rätt – jag tycker visserligen att den är för dyr men vad jag är ute efter här är att summan man betalt påverkar användandet. När man står på Slussens tunnelbanestation och väntar på tåget klockan 00:43 en fredag tar man inte gärna upp sin iPhone och kollar om det kommer stå en buss och vänta i Ropsten eller om det kommer gå snabbare att gå hem – domdär killarna som står därborta verkar allt annat än pålitliga… Jag tog inte med den på solsemestern utomlands heller. För stor stöldrisk, plus att jag ville ägna semestern åt annat än att vara aktsam om en telefon.

En mobil manick måste vara slagtålig, eller i alla fall inte ömtålig. Men jag ska vara ärlig – det finns en massa tillbehör att köpa som hanterar just detta. Skyddande plastfilm som kostar allt mellan 40 och 200 kronor, beroende på om du bara är orolig för repor eller vill undvika krosskador på glaset. Fodral som skyddar själva apparaten, från 150 spänn… Hallå! En iPhone kostar mucho dinares att köpa! Ska man sen behöva köpa till en massa prylar bara för att få den att hålla ihop på ett normalt sätt?!

Nej, iPhonen är inte en sant mobil manick. Men en dag kommer det komma en annan lur, en som gör allt detdär som iPhone kan och som dessutom håller… kanske Android-lurarna är en bit på vägen.

Vi får väl se.

Krav – funktionella, ickefunktionella, och helt fel?

Jag kanske är helt korkad i huvudet, men trots att jag i över tio års tid plöjt systemspecifikationer fattar jag faktiskt inte vad det är för skillnad på funktionella och ickefunktionella krav.

Typexempel på funtionellt krav: ”Sökfunktionen ska klara av trunkerade sökningar”

Typexempel på ickefunktionellt krav: ”Det ska vara möjligt att nå sökfunktionen från alla delar av systemet”

Att sökfunktionen ska vara nåbar överallt är ett funktionellt krav, som jag ser det – det har att göra med hur funktionen ska ”funka’.
Trots det skulle ovanstående exempel kunna vara taget från i princip vilken kravspec som helst.

Inte konstigt att IT-bolag levererar kajko lösningar när det blir viktigare att tillgängliggöra en sökfunktion än att leverera nån typ av nytta.

Ett typiskt ickefunktionellt krav borde, enligt mitt sätt att se det, vara ett överordnat krav som säkerställer nyttan i systemet. Ett ickefunktionelt krav är ”användarna ska kunna hitta relevant material oavsett var de befinner sig på webbplatsen”. Eller ”webbplatsen ska minska behovet av telefonsupport med 1500 samtal om dygnet”.
Sedan drar man streck från dessa övergripande och målstyrande krav och till allt detdär som belamrar en normal kravspec men som borde vara en del av systemspecifikationen – beskrivning av hur man ska möta kraven.

*skakar på huvudet*

Men vad vet jag.

Det finns säkert nån bra anledning till att man gör sådär.

Fast andelen lyckade IT-projekt totalt sett får mej att tvivla…

Så, Wolfram Alpha – vad ger du oss som ingen annan ger?

Under en längre tid har det gått rykten i etern om den nya sökmotorn Wolfram|Alpha. Nu är den slutligen uppe på riktigt. Hur blev det, då?

Tja, intrycket är blandat. Den grafiska designen är OK, och att avsluta sökfältet med ett likamed-tecken är kaxigt.
Men numera förväntar jag mej att professionellt utförda tjänster ska vara kodade på ett sådant sätt att olika typer av tillgänglighetsfel inte uppstår, och en söktjänst som inte fungerar utan Javaskript känns lite… kass. Så det blir det minus för.

Sökningen, då?

Hm. Först måste man förstå att detta är inte en sökfunktion. Wolfram Alpha är ett försök att vara ett uppslagsverk inom några avgränsade områden, och sökfältet används bara som ett sätt att hitta bland allt data.

Stephen Wolfram, som ligger bakom uppslagsverket, är matematiker och här har han försökt applicera en teori om data som kopplas till data blir information. Såhär säger de själva -

We aim to collect and curate all objective data; implement every known model, method, and algorithm; and make it possible to compute whatever can be computed about anything.

För mej är detta grundproblemet. Jag tror helt enkelt inte på att all data kan sorteras till information med hjälp av supersmarta algoritmer. Eller – information kan det ju bli, av ett begränsat slag, men kunskap uppstår genom en process av erfarenheter och i dialog med andra. Därför är kunskap individuell och kollektiv på en och samma gång, och det är att de intuitiva och totalt ologiska kopplingarna en människa kan göra som leder till nya insikter – det klarar inte datorn åt en. Oberoende hur smart utvecklaren är.

Nu är det väl ingen som tror att Wolfram Alpha ska göra det åt en, heller. I citatet ovan säger de också ”compute’, det vill säga ”beräkna’, och ”data’. Hade de inte haft ”knowledge engine” som tagline hade jag förmodligen varit hur nöjd som helst

Men för den som vill göra matematiska beräkningar är det ett toppverktyg.

(Marcus Brisenfeldt på InUse har för övrigt också skrivit om WA)

Nej, webben är inte ett broschyrställ

Jag blir ständigt lika förvånad när jag stöter på folk som fortfarande behandlar webben som om den vore ett broschyrställ.

Vad webben behöver är inte en till redaktör, utan någon som kan ta ansvar för att utveckla affärsmöjligheten. Trots det hör man fortfarande talas om affärsdrivande företag som försöker bygga upp redaktörsorganisationer. Själva ordet, och begreppet, indikerar att någon ska skriva material av redaktionell och publicistisk karaktär.
Är det vad ett företag behöver? Ännu en kanal att gödsla med stilsäkert skrivna texter fyllda med corporate bullshit och anonyma bilder?

Tror inte det.

När professionella konsulter understödjer detta beteende blir jag än mer upprörd. Istället för att ta sitt professionella ansvar spelar de med. Jag får förmoda att det beror på att de ser mer på pengarna än på nyttan.

Som konsult, och särskilt då som specialistkonsult, så tycker jag att man har ett ansvar för sin specialistroll och specialistkompetens. Självklart kan det bli obekvämt ibland. För alla. Men min personliga åsikt är att den som betalar har rätt att få valuta för pengarna.

Och valuta för pengarna är inte att klippa ihop bildbyråbilder med texter saxade ur senaste trycksaken. Även om interaktionsdesignen och den grafiska formen är tipptopp.

Och det är inte ens ”tyvärr”.

Företagsinterna bloggar 10 år senare – är kulturen redo?

Under en stor del av 90-talet jobbade jag på ett företag som hette WM-data Education. På den tiden var WM-data, som nu är Logica, inte ett bolag utan vad som kändes som miljarders autonoma företag.

Vi var hyfsat tidigt intresserade av detdär med webb, jag tror mitt första webbprojekt var våren 1995 men några andra var igång redan senhösten 1994. För att slippa hålla på med datorstödd utbildning, som var ryggraden i vår enhets affär, lärde jag mej snabbt html. Jag skrev En rödstrumpas betraktelser med ny reflektion en gång i veckan. Jag var inte ensam. Snart poppade det upp en massa webbar. Vi behövde en knutpunkt för dem, och snart hade vi ett litet proto-intranät. Så småningom blev det vad man indag kan kalla ett intranät, med flera avdelningar. Bland annat kunde ekonomigänget tjata på våra tidrapporter (svart lista!), resurser fanns samlade… Men mest av allt fanns en anslagstavla. Där kunde vem som helst skriva vad som helst, och kulturen i företaget var sån att många skrev just vad som helst.

Där bedrevs debatt och diskuterades om ledningens sätt att driva företaget, blandat med lustigheter, reflektioner och viktiga meddelanden. Visst deltog inte alla anställda (förlåt – medarbetare) aktivt, men det kan man inte heller räkna med. 10-15% är ett rimligt antagande, resten har fullt upp med jobbet och livet, men de läser och får ta del, dvs. är passiva användare som tar del av debatt och information som de annars inte hade fått.

För varför levde inte detdär intranätet kvar sen, genom alla omorganisationer?

Ganska enkelt. Så småningom fick moderbolaget upp ögonen för detdär med intranät, och det blev inte längre tillåtet för bolagen att ha egna. Nu skulle alla samordnas på en plats, i en miljö.

Kulturkrock. Jag var med och byggde det nya intranätet. Vi hade inga resurser och ingen ville lägga tid på kravställning. Jag, en informatör och en utvecklare påtade på, byggde allt från scratch. Inte helt misslyckat, med tanke på att det var 1997 och det ännu fanns en del att lära, men vi byggde något som skulle rymma den öppna debatt som fanns på Education… och resultatet blev att 98% av intranätet, dvs de delar som hörde till de andra bolagen, ekade tomma.
Lärdom: bygg inte för dialog om inte kulturen stöder det. Om man ändå gör det måste det vara för att ledningen vill ändra kulturen, och då har de ett stort ansvar i att förändra den. Görs inte bara med en ny plattform.
Detta är något jag burit med mig, ända sedan dess – företagets interna kultur är avgörande för vilka lösningar man föreslår.

Tio år senare dyker de företagsinterna bloggarna upp som fenomen. Är kulturerna ute på de svenska företagen redo? Har cheferna plötsligt blivit prestigelösa, har bevakningen av de egna karriärmöjligheterna minskat i betydelse, har risken för de obekväma att få sparken vid nästa lågkonjunktur försvunnit?

Troligen inte.

Har trycket från omvärlden och dessa vid dethär laget 10 år gamla sätten att kommunicera förändrat verkligheten?

Kanske.

Jag håller tummarna, men fortfarande sitter det folk och skriker kontroll, kontroll, man får inte säga vad som helst! därute på de svenska företagen.
Dom skulle aldrig erkänna att de är vår tids motsvarighet till sovjetstatens politbyrå, men det är vad de är.
Många företag har sitt eget interna Stasi. Hur ska medarbetarna våga uttala sig fritt under sådana förutsättningar?

Jag följer med spänning utvecklingen!

Användarna ska inte designa systemet!

Ibland börjar man skriva ett blogginlägg och så kommer man av sej. Så var det i maj i år när tiden inte riktigt räckte till. Idag fick rubriken ny fart – i dagens CS fanns en artikel med rubriken Innovation måste styras av kundens behov – och det är inte alltid samma sak som det de efterfrågar.

Man kan tycka att det är en självklarhet, men uppenbarligen är det inte det – Bengt Karlöf kan i alla fall skriva en bok om det, i förhoppning att den ska finna en marknad.

Min personliga erfarenhet är i alla fall att man inte ska låta användarna designa systemet. Självklart ska deras behov färga designarbetet men folk med verksamhets- och användbarhetsfokus måste tolka och prioritera behoven – ställa dem i relation till övergripande mål som exempelvis behovet av att förändra ett företags kultur och arbetssätt.

Första gången jag arbetade på det viset var 1997, men fortafarande ses det som kontroversiellt. Och inte minst så sedan beställarna började förstå att man ska blanda in användarna. Och – det ska man. Men vid rätt tillfällen, och på rätt sätt.

Att användarna vet hur de helst vill söka information eller vilken struktur eller namngivning som är mest logisk för just dem betyder inte att de vet VAD systemet ska göra.

Så fick jag det sagt, också

Vad är användbarhet, egentligen?

Det finns en uppsjö av ISO standarder och beskrivningar, och alla (utom en, ISO 9241-11) handlar de om den tekniska graden av användbarhet – ett ingenjörsperspektiv på användning; bakomliggande faktorer som avgränsningen av vad systemet ska göra ligger traditionellt utanför.

Ur ett svenskt perspektiv kan man tycka att det är självklart att nyttan är en del av användbarheten, och då pratar jag både om slutanvändarnytta och systemägarnytta. (Trots det stöter man ibland på de som hoppas att urspårade projekt ska kunna räddas fem i tolv av en inhoppande interaktiondesigner som bara smetar läppstift på liket… outgrundlig äro människans /brist på/ tankeförmåga…)

Personligen tycker jag också att faktorer som fysisk tillgänglighet är relevanta – ska en lösning användas av folk ute på fältet, med begränsade uppkopplingsmöjligheter, så måste man veta det. För varför ska man bygga ett system som sedan inte kan användas som det är tänkt?

Ibland kan graden av användbarhet avgöras av den valda IT- eller systemarkitekturen; även det är ett intressant område, som kräver sin speciella kompetens.

Allt detta gör vårt fält väldigt brett. Men det är också det som gör det intressant! Det finns utrymme för så många olika kompetenser, intressen och inriktningar, och alla kompletterar vi varandra.

Det är roligt!

Skit in, skit ut (och var och en är sig själv närmast)

Det är märkligt hur ofta fokus ligger på presentation istället för på insamling och inlämning av data. Många långa meningar har talats och skrivits om vikten av transparens, om att tillhandahålla den information som ”användaren” verkligen behöver, om kanaler för kommunikation.
Vad få talar om är hur informationen ska hamna där.

Normalanvändaren på företag A eller myndighet B eller vårdinrättning C har helt andra saker att fokusera på än att lära sig hur CMS:et funkar i MOSS eller EPi eller WebSphere eller allt vad de heter.
Ja, de går på kurs. Nej, de minns inte riktigt hur man skulle göra, sen när det väl är dags att skriva något. Nej, systemen är inte intuitiva. Särskilt inte för sällananvändare.
Resultatet blir låg kvalitet i informationen, vilket i sin tur resulterar i lågt användande.

Tyvärr har leverantörerna av sagda system ingen som helst insikt i att det huvudsakligen är backend som deras system fallerar. Istället pratar de om integration med funktionalitet X och Y, eller om möjligheterna att anpassa presentationsmallarna.

Lägg lite krut på att göra de gränssnitt som ska användas för informationslämning mer intuitiva, och inse att egennyttan regerar – ingen vill bara ge och ge, man vill ha något tillbaka också. Varför ska jag göra denna ansträngning om jag inte får något tillbaka också?

Dags för tillverkarna av standardsystemen att börja bry sig om användbarheten. På riktigt.

(Ett annat problem är att beställare, leverantörer, etc. fortfarande, år 2007, tror att ”intranät” är synonymt med ”personaltidning på nätet’. Pinsamt. Men det är en fråga för ett annat inlägg.)