Kravanalytiker 4: Inifrån-och-ut

2010 augusti 27
av Glenn

I vår interna kurs för kravanalytiker betonar vi det kommunikativa; hur man förstår brukarnas behov och formulerar dem så att leverantören begriper. Detta handlar om kommunikation, närmare bestämt om att lyssna. Att lyssna är tydligen väldigt svårt eftersom folk gör det så dåligt. Här finns enligt min erfarenhet ett hinder som måste bort: eget perspektiv, eller inifrån-och-ut.

Inifrån-och-ut, det stora hindret mot lyssnande, är att lyssnaren fixerar det egna perspektivet och låter det styra varje tanke: jag i centrum, min världsbild, min agenda. De flesta är omedvetna om att de har den här ovanan. Men hindret måste bort; lyssnaren måste lära sig lämna sitt perspektiv, tysta sitt inre surr och i stället arbeta utifrån-och-in.

Utifrån-och-in, lösningen på det bristande lyssnandet, är att gå över i den andres värld. Min husfilosof Emmanuel Lévinas gör en underbar beskrivning av detta i sin analys av ”den Andre”. Jag kommer tillbaka med mer teori om lyssnande och att ta den Andres perspektiv i nästa inlägg. Nu vill jag rikta din uppmärksamhet mot tre exempel på hur inifrån-och-ut praktiseras så att du känner igen problemet:

  • Västtrafiks nya biljettsystem där den publika kommunikationen bygger på de två begreppen ”områdesladdning” och ”kontoladdning”. Inifrån-och-ut, administratörerna på Västtrafik vet exakt vad orden betyder eftersom deras världsbild (det nya systemet) bygger på dessa två begrepp. Men hur tänker en resenär, Västtrafik?  Göteborgsposten har skrivit spaltkilometer om förvirringen i västra Sveriges kollektivtrafik.
  • I sina kontakter med Telia måste man välja telefoni eller bredband, separata enheter utan större samspel. Varför? För att teleoperatören internt har organiserat sig så. Inifrån-och-ut, bredband och telefoni är två olika tekniska fenomen, det vet varje Telian. Men jag som abonnent har flera gånger haft ärenden jag inte kunnat klassa som det ena eller det andra, jag tänker inte så om min kommunikation hemma.
  • Skola och fritids, skolan är noga med den uppdelningen. Två enheter som skickar lappar hem, två blanketter med barnets personuppgifter som ska lämnas, två sjuk- och friskanmälningar som ska ringas in. Inifrån-och-ut, skolans administration delar skola och fritids i sina excel-ark. Och professionerna är hårt skilda, antingen lärare eller fritidsledare. Men för oss föräldrar är det ju ett barn, ett lärande, en social utveckling, en dag i skolan.

Ju mer jag tänker på områdesladdning och kontoladdning desto mer ser jag av det. Se dig runt du också och reflektera över hur utifrån-och-in i stället kunde se ut. Jag återkommer om det.

Aptillon, nya kollegor i branschen

2010 augusti 24
taggar: ,
av Joakim

En nyhet från den pågående Best Practices-konferensen i Washington DC:

Några riktigt tunga namn i SharePoint-communityt har gått samman och bildat konsultfirman Aptillon. 1 (av världens totalt 4)  Microsoft Certified Master på 2010, 7st SharePoint MVPs, där den med kortast tid haft titeln i tre år, får betraktas som en bra laguppställning.

Kravanalytiker 3: Vad, inte hur

2010 augusti 23

Första sidan i SvD Näringsliv härom dagen hade ”Här är SAS kravlista” som rubrik. Artikeln handlade om kraven på nästa vd efter Mats Jansson vars avgång just tillkännagivits. Nu ska vi se, tänkte jag när jag såg ordet kravlista, om vi kan få lite funktionskrav på vad nya vd:n ska utföra. Fast det var bara en lista med egenskaper, det stod ”förhandlare”, ”hög arbetskapacitet”, ”försäljare” och liknande. Listan bestod av hur i stället för vad vilket är vanligt i kravsammanhang.

Men användarkrav ska specificera vad, inte hur. De ska beskriva vad funktionen, systemet, lösningen ska utföra för sina brukare, inte vilka tekniska egenskaper den ska ha (det görs senare i systemspecifikationen).

Låt oss leka fram ett par kravexempel utifrån utmaningarna, kostnader och 35 fackföreningar, som nästa vd har enligt SvD (notera även kravsyntaxen):

  • Vd ska säkerställa kostnadskontroll så att x-marginalen är y % på årsbasis
  • Arbetstagarorganisationerna ska kunna nå någon i koncernledningen på telefon inom 30 minuter

Till dessa funktionskrav finns flera lösningar som inte nödvändigtvis kräver en vd med egenskapen ”generalist”. Är ni med? Att gå på lösningen innan problemet är definierat, att göra hur före vad, är ett notoriskt felsteg av människor som formulerar krav (titta på valmanifesten som just nu duggar tätt där vi får många lösningar men få problembeskrivningar).

Varför gör folk så här? Är det för att stänga ute andras lösningsidéer? Är det för att de inte har lärt sig tänka problemdrivet? Eller för att de har en föreställning om att det finns en enda bästa lösning? Vad tror du själv? Kommentera gärna.

Njut av polisens klarspråk

2010 augusti 17

Så ska en rapport skrivas. Professorn i rättsvetenskap Dennis Töllborg skåpar i rapporten ut polisens interna utredningar efter noter och han gör det mesta rätt när han i konsultrollen delrapporterar sitt uppdrag: tar ställning med värdeord, skriver i jag-form, backar upp med fakta, använder metaforer, gör enkla illustrationer. Svårare än så här är det inte, folks.

Varför ser vi då så sällan konsultrapporter med den här tydligheten? Mm, det är ju lätt för honom som är professor, säger någon. Jaså hur då? När du som konsult skriver en rapport förväntar sig ju uppdragsgivaren både att du är och agerar som expert – ingen skillnad mot professorn. Och, förresten, vad är alternativet? Jo slätstruken rapporttext, lång, opersonlig, abstrakt med passiva verb och substantiveringar. Men vilken sorts rapport tror du kunden vill ha?

Dennis Töllborg har integritet; han är hel. Han tar en risk med sitt raka sätt och det vet han. Men han bygger under sin kritik och han står för det. Så vad är det han riskerar? Är det att inte få fler uppdrag för polisen, att bli avslöjad som bluffare eller att bli ifrågasatt av chefen? Bryr han sig?

Dessutom, kanske viktigast, är hans rapport lättläst. Titeln? Polismyndigheten i Västra Götaland: En man i grön hatt

Certifierad på SharePoint 2010

2010 augusti 3
av Joakim

Idag hade jag fått två brev från Prometric, det var resultaten av beta-certifieringstesterna jag gjorde före sommaren. En god nyhet och en försmädlig kan man kalla det. PRO-certifieringen hade jag klarat, men TS-certifieringen missade jag med knapp marginal.

Nåja, jag kan i.a.f. titulera mig certifierad för Designing and Developing Microsoft SharePoint 2010 Applications, och det är ju inte det sämsta. Kul erfarenhet att ha klarat det redan i certifieringens beta-fas också.

21SCRUM, Scrumverktyg i SharePoint

2010 augusti 2
av Joakim

Jag har tidigare bloggat om Andrew Woodwards Project Aberdovey, och nu har projektet resulterat i en färdig produkt med namnet 21SCRUM.

Det är en SharePoint 2010 sandboxed solution som tillhandahåller ett prydligt interface för att se burndown, planera sprints och storyboard där man via dran’n'dropp kan starta stories, sätta de som completed osv.

Det finns en trialversion att ladda ner, produkten kostar $150 för en sitecollection-licens.

Att som IT-konsult göra en pudel

2010 juli 24

Ett femtiotal Altran-konsulter har gått vår internkurs i improvisationsteknik och fler lär gå under hösten. Varför? Enligt dem själva är det en rolig aktivitet, ett nyttigt avbrott mot tekniken och personligt utvecklande.

Improvisationsteknik går ut på att använda det som först dyker upp i skallen utan att tänka. Den bärande principen är att vi undermedvetet alltid har bra idéer och uppslag och att vi ska lita på deras kvalitet.

För att improvisera bra behöver man därför ha hög tillit till sig själv, bara en sån sak, och det går att träna upp. En spontan person litar till sina instinkter och uttrycker dem utan censur. Samtidigt fordras koncentrationsförmåga vilket kan verka motsägelsefullt – koncentration och spontanitet, hur går det ihop? Jo koncentration, inte på det intellektuella rationella utan på det intuitiva emotionella, och samtidigt en total närvaro i ögonblicket.

Detta kan vara brukbart till exempel när man får kritik som konsult, oavsett det gäller berättigad eller ogrundad kritik. I medievärlden finns begreppet pudel som många tror de behärskar men få verkligen klarar. Problemet är nämligen att man inte kan ljuga när man gör en pudel. Det är här improvisationstekniken kommer in för den bygger alltid på sanningen.

Som konsulter ska vi ibland göra en pudel när vi får kritik. En pudel, helt kort, är tre saker:

  1. Medge misstaget. Förvånansvärt många snubblar redan här genom att förneka att det har hänt. Gör inte det, den som kritiserar dig anser ju att det har hänt och är det din kund spelar det liten roll vad du tycker. Medge alltså att det har hänt.
  2. Ta ansvar, det vill säga bekräfta att du har en skuld i det inträffade. Gör detta oförställt för då slappnar din motpart av och ni kan gå till steg 3 där själva lösningen finns. Detta gäller oavsett kritiken har eller saknar grund.
  3. Visa på en väg framåt, det vill säga berätta vad du tänker göra för att rätta till saken och för att undvika att det händer igen (i pudeln ingår inte att du sen faktiskt gör det du lovat men som konsult inser du att din trovärdighet hänger på det).

Vi såg ett  sorgligt pudelförsök när Beatrice Ask i ett möte hade sagt att misstänkta sexköpare skulle få hem särskilt färgade kuvert i brevlådan. Efter viss bearbetning av pressen (en ljudinspelning hade läckts) gjorde hon pudelns steg 1, hon medgav sitt påstående. Men sen föll hon tungt när hon med irriterad röst bagatelliserade påståendet och otåligt viftade bort frågan om sin skuld.

Suck, Beatrice, i det läget spelar det ingen roll att du är arg på att pressen hänger ut dig för småsaker. Du hade behövt improvisationsförmåga (och pudelkunskap) för att enkelt och snabbt ta på dig skulden och improvisera fram en charmig berättelse om din frispråkiga lite slarviga personlighet. Sen hade fältet varit öppet att prata om hur du i framtiden tänker agera för att bättre kunna uttrycka din intensiva (och legitima) önskan att skapa system där sexbrottslingar får vad de tål. Ursäkt gjord och kärnbudskap framfört, hur svårt kan detta vara undrar jag.

Vi tränade pudlar vid vår senaste kurs i improvisationsteknik på Malmökontoret. Svårt men nyttigt.

Kravanalytiker 2

2010 juli 4

Kravanalytiker är översättare, det skrev jag i förra inlägget. En översättare lyssnar först, tänker sen och formulerar sig slutligen så att den andra parten förstår vad den första menade.

Förra inlägget handlade om första ledet, lyssnandet. Andra ledet, tänkandet, utvecklas bäst tillsammans med andra i en styrd gruppreflektion, vilket vi gör i kursen. Men för tredje ledet skriva krav vill jag här säga en avgörande sak: syntax.

IT-folk vet att syntax är viktigt. Användarkrav ska vara formulerade så här, utan undantag: subjekt-funktion-kriterium. Vi tar ett exempel: Hyresgästen ska kunna boka tvättid från sin lägenhet på 30 sekunder. Subjektet är hyresgästen. Funktionen är boka tvättid från lägenheten. Kriteriet är tidsgränsen.

Alla dessa tre komponenter i användarkrav måste vara med. Här är varför:

  • Subjektet visar att det finns någon som har det här behovet, vilket tvingar utföraren att tänka på användaren som får en konkret närvaro.
  • Funktionen visar vad användaren behöver – det visar vad, inte hur. IT-människor, vana att tänka teknik, hoppar ofta över vad:et och går direkt på hur:et där de känner sig hemma, en vanlig brist i kravarbete. Så komponenten funktion i användarkravet säkerställer fokus på vad det är användaren behöver.
  • Kriteriet, när det är genomtänkt, driver utföraren att tänka utanför lådan. I exemplet med tvättid är 30 sekunder så kort tid att utföraren måste vara innovativ och hårt fokuserad på usability.

Ett annat exempel på användarkrav: Delfinen ska hoppa över en ribba 2,2 m över vattenytan vid dressörens signal. Fundera lite på det här kravet: Vilken är dess funktion? Vilka andra intressenter finns runt systemet? Vad skulle hända om kriteriet var annorlunda?

Visst, det här är en utmaning mot hur många tänker om kravarbete. Men IT är både teknik och människor och människan får notoriskt för lite plats. Fråga några människor själv, användare alltså, hur väl it-systemen de har löser deras problem.

2010 juni 30
av Joakim

Jaha, så jag gjorde även betaversionen av TS-certifieringen för SharePoint 2010-utvecklare. Som jag anade så var det testet mer detaljerat, med kodexempel där man skulle välja rätt stycken att sätta in på rätt plats osv.

Det togs upp en del nytt, men också en hel del gammalt. Jag tycker det kändes som att en erfaren SharePointutvecklare nästan skulle kunna klara provet på sina 2007-kunskaper, sådan var fördelningen mellan frågor på nytt och gammalt stoff. Fast när man gör ett riktigt prov med bara en delmängd av frågorna på betatestet så kan det ju hända att man får en större andel frågor på nya områden.

Det verkar som om releasedate för de riktiga testen blir 12:e juli. Vad jag bygger det på är att jag fick ett erbjudande om en free voucher för att göra en av de riktiga certifieringarna då de kommer. Jag valde att göra ett försöka på TS-nivån av ITPro-certifieringarna, och nu fick jag ett besked om att jag fått en voucher och att dessa distribueras när de riktiga testen släppts, efter 12:e juli.

Designing and developing SharePoint 2010 applications

2010 juni 9

Så har jag första av de två beta exams på SharePoint 2010 jag tänkt göra avklarad. P.g.a. begränsade tidsslottar att göra proven på fick jag göra PRO-certifieringen före TS-certifieringen.

Min upplevelse är att certifieringen var ganska enkel vad gäller svårighetsgraden, det var dock mååånga frågor. Mer kan jag nog inte skriva p.g.a. NDA. :)

Nu är det upp till 8 veckors väntan innan de utvärderat beta-testerna innan jag får reda på resultat. Som sagt var frågorna ganska enkla, men eftersom de var många och jag inte är riktigt bekant med alla begrepp än(alltså t.ex. vad funktionaliteten som gör att man kan begränsa antalet resultat som returneras vid en query mot en lista egentligen heter), så räknar jag inte med att ha klarat den.

Nu är det TS-provet på torsdag. Det blir förmodligen svårare, för jag anar att det är mer detaljerat. Eftersom denna i princip enbart behandlade designbeslut så måste den andra inbegripa själva hantverket, kodandet.