Digital frustration och glädje

6 11 2015

Till största delen så har den digitala utvecklingen löst många problem och allt är så mycket lättare nu än förr. Inget behöver planeras längre, eftersom allt går att lösa på plats med hjälp av någon device med internet. Inga papper behöver sparas för allt finns lagrat digitalt (hur orkade man ha 1000-tals pärmar och papper?). De flesta bankärenden kan göras direkt, på momangen, inga väntetider på något kontor. Kan fortfarande minnas hur jag o mamma stod i lång kö till posten för att betala räkningar när jag var en sådär 8 år. Hur sjutton hade man tid med det undrar jag?

Men ibland blir det fel i den digitala designen.

Och all denna tidsbesparing har också en baksida, t.ex att man faktiskt aldrig har den där halvtimmen att stå i kö någonstans eller göra något som helt enkelt, tar tid.

Vad gäller den digitala designen och vidareutveckling finns en hel del att uppröras över, när man blivit van med att saker ska fungera. T.ex:

Varför i all världen visar Google Map GPS sedan en tid tillbaka kartan upp och ner?? Och i stället för ”kör vänster” ”kör höger” så säger den ”kör åt sydost” för att direkt därefter säga ”kör norrut”. Hur sjutton ska jag kunna veta vad som är norr och sydost på en plats jag aldrig varit, i en stad med hundra gator i alla riktningar? Googles GPS brukade fungera toppen. Vad hände?  

Jag googlade på detta för att se om det var någon konstig inställning jag råkat göra, men icke. Enda hjälpen jag lyckades hitta var att om man lyckas pricka rätt och trycka på navigerings-ikonen så kan den börja visa kartan, som ja, en GPS-karta rimligtvis visas, i körriktningen. Saken är den att man måste trycka på den där ikonen för att sätta igång navigeringen och då defaultas kartan tillbaka till upp och ner, dvs motsatt riktning. Vilket gör att kartfunktionen blir het meningslös, det går inte att följa en visning åt motsatt håll och försöka ställa om i huvudet vilket håll som egentligen avses. Vad hände Google?  Någon som vet?  Jag skulle tro digital vidareutveckling från sin sämsta sida.

Eller möjligtvis en programmerare som helt enkelt tycker det är roligt att navigera upp och ner, och försöka hålla väderstrecken i huvudet, och ingen vågade ifrågasätta denna tech lead, eller möjligtvis design lead.

Till glädje för Garmin och andra GPS-tillverkare och appar som lär ha ökat försäljningen på sistone.

Fördelen med denna design-katastrof är att jag nu tvingats använda huvudet igen och lära mig hitta i stan, norr om stan t.om, och överallt med hjälp av huvudet, mitt eget minne och trial & error även om jag behöver mer tids-mariginal för att hitta till en ny plats. Och jag glömmer inte platsen när mitt eget minne och uppmärksamhet tvingats navigera själv.

Och jo, jag kommer köpa en riktig gps-app eller device snart. För SÅ kul är det inte att göra u-svängar och gissa sig fram, när det kommer till kritan.

Ett annat vanligt exempel på digital frustration, är den numera ofta återkommande bristen på översikter, t.ex i gallerior. I stället för en översikt ska man klicka och söka sig fram via en informationstavla för att hitta dit man ska.

För inte så länge sen kom man in i en galleria, t.ex Farsta centrum, och där satt det kartor lite överallt med alla butiker och hus utritade. Titta snabbt för att hitta den butik du letar efter. 

Nu har man ersatt dessa med digitala tavlor som du först måste klicka på en gång för att alls kunna se något. En översikt över alla butiker är inte att tala om. I stället ska du via A-Ö-funktion eller en pekfingervals i ett sökfält försöka leta fram H&M, Apoteket eller vad det nu var du skulle till. 6 klick senare har du fått upp Apoteket, men du kan inte i samma bild se var H&M ligger, utan måste klicka dig tillbaka och göra en ny sökning.

Vad hände? Snälla Farsta och andra gallerior, ge oss översiktskartorna tillbaka! Eller varför inte erbjuda båda möjligheterna?

Digital design som skapar frustration i en ofta tidspressad situation.

Samma sak gäller resekataloger men det har jag skrivit om tidigare. Vad var det liksom för fel med de där översikterna som visade ort, pris & olika hotell vecka för vecka under året i en och samma bild? Att göra samma sak på en digital skärm är inte svårt, bara det att ingen haft lust. Kanske kändes omodernt. Men översikter behövs fortfarande.

Tidtabeller samma sak, ibland vet man helt enkelt inte exakt vad man ska söka på, utan vill ha en enkel översikt över alla bussar på en gång.

Sökfunktioner är bra till mycket, men inte till allt. Kom ihåg att vi, dina kunder & köpare behöver både sök och översikt! Beroende på vilken situation vi är i för stunden.

Ett glädjande exempel på digital design när den är som bäst enligt mitt tycke, är när jag surfar in på posten.se (okejdå postnord.se)  för att kolla upp ett paket som är på väg. Och minsann! Direkt på förstasidan, mitt på, finns ett stort fält för att ange kolli-nr med en trevlig text ”Spåra paket.”  Här är det någon som tagit reda på fakta om sina användare. Kan de kanske få ett pris för att ha tagit reda på vad som är det huvudsakliga behovet hos de som surfar in?

Postnord

Inga krångligheter, inga komplicerade navigeringsfält, rakt på, den funktion jag efterfrågade just nu. I det här fallet älskar jag den digitala världen. Hur gjorde man egentligen förr? Letade upp en avi som satt i en pärm nånstans, och ringde till en lång telefonkö för att få ett luddigt svar om var paketet befann sig?

Och för att vara lite hygglig mot google, så är det helt fantastiskt att sökresultatet nu visar delar av innehållet direkt i sökresultatet. Så att man direkt kan se och välja den funktion som (jag gissar) är mest poppis på sidan, t.ex ”öppettider” eller liknande.  Vidareutveckling när den är som bäst. Någon där som verkligen förstått att förenkla sökandet.

Google GPS-teamet kanske skulle göra studiebesök hos Sök-gruppen och lära sig något?

Har du några exempel på digitala designkatastrofer? Eller glädjande överraskningar? Dela gärna med dig så kanske vi faktiskt påverkar alla dessa tokstollar, som en själv, som utvecklar både bra och dåliga digitala lösningar.

Annonser




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.





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.





Agilt, Iterativ & Inkrementell!

22 03 2013

Jag fick den här frågan från en kompis & student:

”Agile, Iterativ & Inkremell! Vi har pratat lite om det jag & några från klassen, och alla typ blandar ihop allt!
Vissa säger att tex Scrum är agilt, andra säger att det är ngt annat bla bla, jätte förvirrande :b det ända jag har
koll på är att RUP iaf är iterativt haha.”

Ska jag göra ett försök att förklara begreppen lite kort?  Jag gör ett försök..

Agile
Agile är ett sätt att tänka. Det är inte ett verktyg. Det är inte en metod. Det finns metoder som Scrum, Kanban, Lean Software Development som kan hjälpa dig att komma framåt. Du kan vara agil utan att använda någon metod alls. Du kan också vara agil med en gammaldags metod som RUP, eller vilken som helst annars. Det handlar om ditt sätt att se på projekt som en icke-förutsägbar händelse, och ditt sätt att se på verkligt samarbete (arbeta tillsammans), ständigt omfamna förändringar i omgivningen och hos dina kunder, kontinuerligt förbättra hur du och ditt team arbetar och samarbetar.

Det går att jobba enligt Scrum och inte alls vara agil, även om Scrum med sina regler om att inom en kort tid leverera fungerande programvara ofta hjälper till på vägen att bli agil.

Den här blog posten beskriver vad agile inte är  – med referenser till principerna i det Agila manifestet, som handlar om principer – inte verktyg & metoder.   http://www.tommycode.se/2012/12/what-is-agile.html?m=1

En gång delade jag några tankar om vad agilt är, på stapplande engelska..

http://blog.smartbear.com/software-quality/bid/224669/Ulrika-Park-Becoming-Agile

Iterativ

Iteration är ett annat ord för upprepning. Inom matematiken och i programmering handlar detta om att en funktion eller process åstadkommer något genom att upprepa tills ett önskat resultat uppnåtts.  (wikipedia nerkortat)

Ett annat ord är loop. Tänk dig ett flygplan som gör en loop. Sedan gör flygplanet samma loop igen. Det är den 2:a iterationen. Bilden nedan är ett gäng iterationer av samma flygplan.

Smoke-Loops-Flight-demonstration-Circle-Sky-300x187

Inom systemutveckling är det att utveckla samma funktion flera gånger tills den är tillräckligt bra.
Det kan också vara att genomföra samma projekt flera gånger tills det är tillräckligt bra att släppa till kund.

Säg att du skriver en uppsats om ett ämne. Du skriver en version rakt på tills den är klar. Sedan börjar du om och skriver samma uppsats en gång till. Du tar med dig saker från första versionen, kanske många meningar, men lägger till saker, tar bort saker, ändrar ord. Den andra versionen är andra iterationen. Skriver du den en tredje gång, har du gjort 3 iterationer.

Detta är något som glömts bort i många genomföranden av s.k agile.

Jag har varit med i ett par projekt där vi verkligen jobbade iterativt. Det vill säga – vi valde en funktion att bygga. Definierade vilka krav & testfall som skulle passera för att funktionen skulle kunna fungera någotsånär. Vi visade upp funktionen för beställaren/kravställaren. Sedan byggde vi samma funktion en gång till – byggde ut, snyggade till, förbättrade både bakom ytan (programkoden) och framför ytan (användargränsnittet). Ibland en tredje och fjärde gång.

Att jobba iterativt är att ALLTID bygga samma funktion minst 2 iterationer – 2 gånger.

Faktiskt så påstod även någon att även den förhatliga Vattenfallsmetoden var iterativ från början. Meningen var att man skulle driva sitt projekt enligt Krav – design – implementation – test – integration – leverans och sedan köra samma projekt en gång till och då göra det rätt och snyggt. Kanske borde kolla upp källorna på detta, men har för mig att jag sett bilder på en loop – där man går tillbaka till början direkt efter slutet.

Idén med RUP var också att vara iterativ. Dvs definiera krav (use cases), design, progammera, testa under en fas, sedan gör samma sak en gång till. Tyvärr dränktes den idén i för mycket annan information, regler & dokumentation så att jag har sett få RUP-projekt som faktiskt jobbat iterativt, även om jag har hört talas om dem som faktiskt gjort det.

Scrum är enklare och studerar man metoden noga kan man se att tanken är att iterera, loopa, över funktioner. Det har tyvärr också ofta dränkts i idén att man bara ska leverera snabbt snabbt. Att leverera snabbt är inte huvudfokus i principerna i det agila manifestet. Ingenstans sägs att man ska leverera snabbt. Men man ska prioritera fungerande programvara framför pappersprodukter (oändliga dokument som inte går att använda).

En ”sprint” i Scrum är INTE en iteration. En sprint är rätt och slätt en time-box på t.ex 2 veckor (aldrig mer än 4). Efter 2 veckor ska teamet visa upp resultatet för sina intressenter. Och bara fungerande programvara. Dokumentation, tankar, idéer och planer är oväsentligt. Huruvida man faktiskt tar samma funktion och itererar över den i nästa sprint, sägs inget om i Scrum, även om metoden kan tvinga fram det beteendet. Man hinner inte på 2 veckor göra så mycket ”lull lull”. Man måste ofta gå tillbaka till samma funktion nästa eller senare sprintar för att göra den värdig att sälja/använda.

Man kan säga att en sprint i Scrum kan vara en projekt-iteration. Dvs man genomför samma projekt i många iterationer, tills det är tillräckligt bra. Första iterationen så har man gjort projektet (krav, test, utveckling, integration, leveransfärdigt) fast det kanske inte är tillräckligt bra – än, så man gör en iteration till över samma projekt så blir resultatet bättre.

Jag har inte sett många Scrum-projekt som sett på sprintar på det sättet. Även om tanken var att en sprint – skulle vara en iteration av ett projekt.

Sprint och iteration är alltså (oftast) två helt olika saker.

Du kan bygga en funktion under en sprint, och sen strunta i att bygga/förbättra den igen. Då har du inte itererat över den funktionen. Du har bara jobbat i en time-box, en sprint.

Inkrementell

”An increment is an increase of some amount, either fixed or variable. For example one’s salary may have a fixed annual increment of x%” (redigerat från wikipedia).   Om din lön ökar med en fast % varje år, så ökar den i inkrement.

Inkrement är alltså en utökning.

Jag tänker på en bakelse. Säg att du har en liten rund bit sockerkaka och fyller den med bär. Sedan tittar du på den och tycker den förtjänar lite grädde runtom. Du lägger till grädde. Det är ett inkrement. Bakelsen var redan klar att äta och njuta av med sockerkakan och bär, men med inkrementet grädde så har du utökat bakelsen till en lite större upplevelse. Sedan tittar du på bakelsen igen och bestämmer dig för att lägga på riven choklad runtom. Ytterligare en utökning, ett inkrement. Den var redan färdig som den var, men chokladen gav det lilla extra.  Som ett sista inkrement lägger du på hyvlad mandel.

Du hade en färdig bakelse från början med sockerkaka & bär. Bara sockerkakan hade  inte varit tillräckligt, det hade bara varit en sockerkaka. Efter den första inkrementet, utökade du den stegvis, inkrementellt, till en större finare bakelse.

Samma gäller funktioner i systemutveckling. Du bygger en funktion som är färdig som den är. Den går att använda. Sedan utökar du den med (små) inkrement, ett extra värde, ett extra inmatningsfält, extra information.

Exempel
Ett exempel på inkrementell funktionsutveckling var när vi skulle presentera kursinformation i ett utbildningssystem för studenter.

Det första inkrementet bestod bara i att visa upp kurskoden och namnet på kursen. Fullt fungerande.
Det andra inkrementet bestod i att visa upp ytterligare information, såsom kort beskrivning, hur många poäng kursen var, vilken institution som gav kursen.
Tredje inkrementet var att visa upp kurstiteln på engelska och vilka prov som ingick.
Etc.

Vid första inkrementet kunde vi inte släppa funktionen till studenter, den var för fattig på information. Däremot kunde vi visa upp den för vår beställare/kravställare/produktägare, så att han kunde se att det fungerar.
Efter 3:e inkrementet var funktionen redo att släppas till studenter – slutanvändaren.

Skillnaden mellan iteration och inkrement??

Inte helt lätt att avgöra. När man stegvis utökar (increment) – en färdig funktion, så gör man det genom att iterera – alltså återkomma till samma funktion (bakelse) flera gånger.

Inkrement = utökning
Iteration = upprepning

Solklart?

Skulle vara jätteintressant  om den som rättar era tentor vill kommentera den här artikeln, kanske har hen ett ännu bättre svar på skillnaden mellan iteration & inkrement?

Kram

Ulrika





”För att det är tradition…”

25 12 2012

Jag har alltid blivit så oerhört provocerad av detta påstående. Varför har vi julskinka på bordet? ”För det är tradition”, har jag mer än en gång hört genom åren.

Varför inte bara svara ”För att det är gott”, ”För att det ser fint ut”, ”För att det är roligt att griljera” eller någon annan, vilken som helst orsak.

Jag blir så oerhört provocerad av  kommentaren”För att det är tradition…” – oavsett om det gäller julskinka, åka till släkten, köpa julklappar eller något helt annat som inte alls har att göra med julen.

Det som gör mig så provocerad är att svaret är så.. hjärndött. Så total brist på reflektion, vilja, engagemang, tanke. Brist på respekt för sin egen och andras fattningsförmåga. Den mer eller mindre bildade person som gör något, och hävdar traditionen som orsak är inte ett uns bättre än alla dessa som genom historien, och fortfarande, hänvisar till ”att Bibeln säger så” för att förklara sina handlingar, åsikter eller yttranden.

Med argumentet ”att det står i Biblen” eller ”det är tradition” eller ”vi har alltid gjort så” kan man bortförklara de mest vidriga, eller bara korkade beteenden.

Jag tror att det som gör mig så provocerad är att jag vet att ingen häromkring är så oförstående att hen inte kan hitta en annan anledning till julskinkan än just traditionen. Och att jag ser personer göra saker som de verkligen inte gillar ”för att det är tradition”, särskilt runt jul. Orsaken ”för jag försöker lära mig en ny kultur” eller ”jag vill verkligen göra faster Stina glad och åka 100 mil i snöstorm med 4 snoriga ungar” är ju helt förståeliga och antagligen genomtänkta. ”För att det är tradition..” är det inte.

Att ha julskinka på bordet för att det är tradition, utan att ens kanske gilla det, är en dumhet som ingen behöver göra.  Om orsaken är ”för att faster Stina gillar det” är det ju en helt annan grej, självklart ska faster Stina få julskinka. Bra orsak!  Men ”för att det är tradition… ” tar på något sätt bort all intelligens hos personen som säger det.

Ungefär som att vi i säkert 10 års tid efter att någon person sa att det var konstigt att kalla ”chokladbollar” för ”negerbollar” hörde alldeles för många personer, även i film, som hävdade att ”vadå, vi har ju alltid kallat det så”. Samma totala brist på tanke, av människor som faktiskt gått i skolan.  ”Ja, men då så, då fortsätter vi kalla det för det då… ”

”I Bibeln står att homosexualitet är fel”. ”Möjligtvis, men tycker verkligen alla som tror på Gud det på riktigt..?”

Provocerande när hyfsat bildat folk inte använder sin tankeförmåga.

I kontorssammanhang kan man höra samma tema. ”Varför måste du fråga chefen om du får göra den här förstudien som DU anser rätt?” ”För att vi har alltid gjort på det här sättet”.

Kan du förklara varför?

Nu tror jag naturligtvis inte att de som läser denna text skulle få för sig att referera till Bibeln som orsak till dumma uppfattningar eller beteenden, eller ens ”det brukar vara så”. Säkerligen har du dock mer än en gång hört orsaksbeskrivning på jobbet vara ”för att det brukar va så”. Och i privata sammanhang hört annars kloka starka individer som gör märkliga saker runt julen ”för att det är tradition”.

Jag tror att när vi hör ”traditionen” eller ”det har alltid varit så” som argument till att göra saker man inte vill på jobbet eller på julen, så kan vi ändra detta genom att bara uppmnuntra den personen till att förklara sig. ”Ja, men hur skulle DU nu vilja göra?” ”Vad hindrar dig..” och inte nöja dig med ”traditionen” som svar.

En annan tradition som provocerar mig att hänvisa till är ”traditionell projektledning” eller ”traditionella projektverktyg”. Vadå traditionella? Provokationen består i att genom att hänvisa till traditionen så utesluts jag och alla andra som verkar idag från att bidra med kunskap. Även tankeförmågan hos den som yttrar ”att traditionellt har vi gjort så” utesluts. Om samma person i stället berättar vad som är bra med en viss metod eller modell, kommer vi andra säkert förstå och komma med på tåget.

Genom att hänvisa till traditionen anses man inte behöva förklara sig.

Traditionen har inget egenvärde. Punkt. Däremot kan vanor, sysselsättningar, metoder eller modeller ha ett stort värde oavsett hur gamla eller nya de är. Traditionen har inget med ålder att göra.

Brist på reflektion är brist på respekt för sig själv och sin omgivning. Och få saker är så skadligt för mänskligheten som brist på respekt, visst?

Vad vill DU göra under julhelgen? Och vad vill DU göra när du kommer tillbaka till jobbet?

God Föränderlig Jul och Nytt kunskapsutvecklande År!





Tips till konsultköpare

18 08 2012

Samma dag jag bestämde mig för att lämna konsulttillvaron ett tag så fick jag några nya insikter, kanske har det med perspektivet att göra. Så snart du kommer utanför det snurrande hjulet är det lättare att observera vad som händer i hjulet.

Något som för mig nu framstår väldigt tydligt är hur extremt mycket (arbets)tid som läggs i vårt IT-samhälle på rekrytering, eller snarare inköp, av tillfälliga konsulter. Både av konsultköpare (ofta verksamhets- eller IT-chefer), konsulterna själva (ofta högavlönade kunskapsarbetare) och konsultsäljare (ofta mycket kompetenta och högavlönade kunskapsarbetare).

Konsulting är den nya anställningsformen. Vad jag ser på svenska IT-relaterade avdelningar är att det inte är ovanligt med hälften anställda, hälften konsulter. Egentligen är det bra, en flexibel arbetskraft som kan röra på sig snabbt när det behövs.

Det som INTE är bra enligt min uppfattning är den enorma mängd tid som läggs på avancerade inköpsprocesser av ett stort antal människor för att ofta inte köpa alls, eller efter en lång och tidskrävande köpprocess, göra ett köp för mycket kort tid t.ex 3 månader.

Jag uppskattar mina tidigare kunder och potentiella kunder, de har varit ambitiösa och ärligt intresserade personer, som gör ett bra jobb. Det jag kritiserar nu är systemet för hur svenska organisationer ofta upphandlar konsulter. Av gammal vana, tradition eller bara en viss brist på analys av processen.

Det är inte sällan jag varit med om 3 månaders inköpsprocedur för ett 3 månaders konsultuppdrag. Samtal, intervjuer, mail, telefonkonferenser, cv-skrivande, prov-seminarier, uppföljning, intervjuer och lunchande med ännu fler (annars väldigt upptagna) chefer.

När jag slog ihop det totala antalet arbetstimmar som lagts ner av ett företag för mitt eventuella 3-6 månadersuppdrag, av ett 10-tal chefer + min egen och säljarens tid, fick jag ihop det till minst 40 timmar, en arbetsvecka av högkvalificerad arbetskraft.

Tänk hur många samtidiga köpprocesser som pågår just nu, även om det bara vore 10 samtidigt = 10*40 = 400 arbetstimmar som tas från något annat – mer värdeskapande arbete i våra organisationer?

Är det värt det?  

När beställaren efter några veckor kommit fram till att ”jo, det verkar bra vi kör på detta” och hörde av sig till säljaren för att göra upp, hade konsulten naturligtvis hunnit tacka ja till ett annat uppdrag. Och beställaren fick börja om processen med den 3:e potentiella konsulten. Hela köpprocessen var vid detta tillfälle uppe i ca 4 månaders kalendertid, eftersom en tidigare tillfrågad konsult också hunnit tacka ja till något annat medan beställaren konfererade.  Innan de hittat nästa potentiella konsult har kalendertiden överstigit tiden för uppdraget.

Är detta klokt??

Och jag har sett samma sak, gång på gång på gång.

En annan lika vanlig variant är:

Beställaren kontaktar oss (konsultföretaget) av personliga skäl, känner någon som rekommenderat någon etc. Vi åker dit med den rekommenderade personen, för en både lång resa och lång intervju där konsulten presenteras för olika personer, introduceras till beställarens organisation och utmaningar, en dialog startar och fortsätter på mail och telefon efter intervjun.

I detta fall är beställaren ganska snabb på att bestämma sig för att ”jo, det här verkar bra, vi vill gärna jobba med dig.” ”Så nu börjar vår budgetprocess. Vi hör av oss när den är klar”.  !!  Det fanns inte ens avsatt medel för att göra ett inköp!!  När budgetprocessen sedemera är klar och det verkar finnas ett ok på finansiering, ca 2 månader senare, är naturligtvis konsulten ute på annat uppdrag och kan inte tacka ja. Så beställaren, konsultköparen, får börja om köpprocessen. Denna gång förhoppningsvis med budgeten klar.

I detta fall, när jag lägger ihop timmarna, är vi ca 5 inblandade personer i köpprocessen, hos beställaren och hos leverantören. Högkvalificerade kunskapsarbetare som tillsammans lagt minst 30 arbetstimmar på en inköpsrutin som inte ens kunde leda till något, eftersom budgeten inte var säkrad.

Är det värt det?

Vad tycker du som konsultköpare? Kanske är det någon viktig del jag missat, som jag inte förstår.

Jag tror att hela denna procedur handlar om att köparen så gärna vill göra rätt. Det ÄR mycket pengar för de flesta att köpa en kosult för kanske 1000 kr/tim och uppåt. Därför vill köparen göra allt som står i dennes makt för att säkerställa att det är rätt person, rätt kompetens som kommer in. Så köparen ser till att skaffa förankring, genom att flera viktiga personer involveras, att det avsätts ordentligt med tid för intervjuer, presentationer och uppföljning. Kanske ett prov-uppdrag (seminarie-liknande aktiviteter som den tänkta konsulten förväntas hålla) etc. För om alla dessa undersökningar gjorts kommer rätt beslut fattas.

Viljan att göra rätt verkar ha en förmåga att gå överstyr.

Både hos köpare, konsulter och säljare.

Och när köpprocessen är klar, är konsulten redan upptagen på annan plats och oändligt många arbetstimmar har lagts på en köpprocess som inte leder någonstans.

Så här skulle konsultköpare kunna göra i stället, åtminstone vill jag agera så när jag står i köpläge:

  • Pengarna först! Money talks! Se till att du som beställare har en avsatt budget redan när du börjar, så att när du hittar rätt konsult kan slå till direkt utan väntan.
  • Genom detta kan förankringsprocessen handla om avsatta medel, snarare än person. Så när det är dags för personintervju – kan du sköta det själv med någon nära teammedlem.
  • Får du ett bra intryck av personen och hyfsat pålitliga meriter,  ge det en chans, med möjlighet till snabb utgång. Avtala fram snabbt inköp – snabbt avslut om personen visar sig vara fel. Våga riskera att du omöjligt kan ta reda på allt om personen i förhand. Väg tiden före mot värdet efter.
  • Om personen är rekommenderad av någon du litar på, eller du har hittat denna genom dina nätverk och kontakter, slå till direkt! Det kan visa sig vara fel, men vad är rekommendationer annars värt?
  • Bestäm i förhand hur mycket tid som får läggas totalt på köpprocessen av involverade personer internt. Fördela den där det ger mest värde. När den bestämda tiden är förbrukad, fatta ett beslut. Är du för osäker? Fatta beslutet nej då.

Konsulter är en fantastisk kraft för tillfälligt arbete, när du inte vill anställa. En mer medveten köpprocess kommer gagna både köparens organisation och samhället genom att kompetens används där den gör mest nytta.





2 dagars agil coachning av 150+ proffs för 2000 spänn

24 04 2012

Tycker du det är dyrt med agil coachning? Missa inte konferensen Agila Sverige nästa år, som just gick av stapeln i Stockholm. Där får du 2 dagars professionell coachning av 150-200 erfarna ledare, utvecklare, designers, testledare, projektledare, verksamhetschefer, IT-ansvariga, filosofer,  pedagoger, samhällsvetare mfl

Insikten kom till mig på vägen hem. Denna återkommande konferens, ordnad i enkelhetens namn, innebär oavsett om du är proffs eller rookie i området att du får 2 dagars personlig coaching av väldigt många agila proffs och möjligheter till att ta del av erfarenheter, nya och gamla kontakter, roliga historier, personliga samtal, rådgivning, underhållning, praktiska tips och filosofiska resonemang om kommunikation, design, system, teknik, politik, religion, verksamhetsutveckling, organisation, teamutveckling och allt annat nödvändigt för att vi ska kunna leverera det våra organisationer är till för – att skapa en kund – må den vara medborgare, medlem eller konsument.

Det är nu 5:e (?) året jag deltar och utbytet ökar. Fiskdammen har mognat till ett event av direkt, praktisk och filosofisk coachning.

Några ämnen som var uppe som jag lyckades fånga

– Form och funktion – är samma sak. Varför skilja på design och utveckling?
– Inkludera människor i ditt team istället för envist försöka assimilera. Bjud in!
– Tänk nästa steg när du funderar på att byta riktning – vad kommer efter ditt val nu?
– Metodöverflöd. Det finns en enorm mängd fantastiskt användbara metoder idag för att leverera nytta – Innovationgames, Lean Startup, Real Options, UX (User Experience Design)-områdets stora skara av metoder, Stop-the-Line, Kanban, A3-förbättringar, Toyota Kator, Enkla checklistor, Programming Anarchy… listan kan göras oändlig. Välj en – prova på i 30 dagar, utvärdera, förbättra och/eller välj en annan nästa 30 dagar.
– Det finns goda exempel på hur verkligt självorganiserande organisationer kan fungera, se t.ex Valves handbok för nyanställda även Länsstyrelsen Karlskrona omnämndes i det sammanhanget. Hade velat höra mer om
– Kommunikationsskuld. Den skuld du bygger upp genom att avstå från nödvändig kommunikation. Ungefär som teknisk skuld. Det du inte gör något åt idag börjar du betala ränta på, skulden växer tills dess du tar i tag och börjar betala av skulden. Hur har du det med kommunikationen med dina leverantörer eller beställare egentligen..?

Agila Sverige är ett smörgåsbord av tillfällen till coachning och lärande.

Nya boktips från pedagogiska mästaren Tobias Fors – The Power of Learning och Thinking fast and slow

Om man upprepar något tillräckligt många gånger blir det sant. Några saker behöver upprepas och påminnas om många gånger, bl.a perceptuell blindness, testa själv på

Awareness Test: Basketball players

Har du verkligen koll på allt?

Och det ständiga upprepandet av mantrat:

”Be inte om tillåtelse, be om ursäkt efteråt”

kommer snart ge resultat i våra organisationer – förväntar mig större turbulens och större förbättringar på arbetsplatserna för kunskapsarbetare närmsta åren..

Och sist men inte minst, den ständigt och självklara upprepandet på denna återkommande konferens – frågan

VARFÖR?

Det resonemanget tror och hoppas jag blir nästa års fördjupning.

Tack till arrangörernas idealistiska och aldrig svikande engagemang för att se till att vi har ett forum som utan att kosta skjortan kan ta oss ytterligare ett litet steg framåt i evolutionen av våra system.

Snygga bilder på några av dessa 150+ coacher finns här…  fotat av.. vem var det? Joakim S?

Foton Agila Sverige Dag 2
Foton Agila Sverige Dag 1