Det här blir, tror jag, ett avsteg från mitt vanliga agilevangiliserande. Istället tänker jag summera lite tankar om den civiliserade människans relation till robotar.

Sedan en tid tillbaka har jag hört flera av mina vänner prata varmt om sina små dammsugarrobotar (Roomba från IRobot). De klarar trösklar, hittar till sin laddningsstation när den behöver ladda upp sig och kan dammsuga när ingen är hemma. Jag kände att det nog är en klassisk robottillämpning. Den befriar oss från en av veckans tråkigaste sysslor så att vi får mer tid för varandra.

Samtidigt har jag förundrats över den städmani som följt i dess spår, det verkar som att det finns ett extra intresse av att städa nu när det är en robot som utför sysslan. Först tolkade jag det som att man kanske alltid velat ha rent och fint omkring sig men att man hade saknat tiden för att leva upp till detta ideal, men nu har jag svängt över till en annan tolkning. Jag tror att dessa robotars ägare vill spendera tid med sin robot. Det verkar finnas en underliggande kärlek till roboten. Tydligast blir det när man hör dem säga: ”Idag hittade jag min Roomba intrasslad i en hög av sladdar klagandes på tyska, franska och engelska” eller: ”Igår såg jag hur Roomba närmade sig trappen, blev rädd och gav ifrån sig ett pip”. Eller en annan vän som nästan kärleksfullt deklarerade att han skulle Roomba-säkra sitt hem.

Kanske är det inte så konstigt att man utvecklar känslor för ett ting som lojalt ställer upp på att dammsuga när ingen är hemma?

Som av en händelse har jag sett ett antal TED-tal som handlade om hur våra liv kommer att förändras av robotar och påfallande många robotidéer verkar tala till vår förmåga till empati med dem istället för tvärtom. En av ideérna var en robot som gör allt det där som du saknar hos en partner när du separerat efter ett långt förhållande, tar täcket på natten, gnäller och tjatar på dagen… (talet på TED det jag refererar till är drygt 14 minuter in på talet).

Dessutom slog det mig att det här är redan ”old news”, vem minns inte tamagotchin? Tamagotchin som ter sig väldigt omodern i åsynen av den gulliga leksaksdinosaurien Pleo som är föremål för ett annat TED-tal.

Faktum är att även Roomba från IRobot har presenterats på TED och där har de påfallande intressanta klipp om hur vi kan komma att interagera med robotar baserat på våra emotionella kvaliteter.

Roboten kanske blir din ”low-maintenance-friend” när du inte har tid för riktiga vänner längre. Jag som trodde att vi skulle skaffa robotar för att få mer tid för varandra…

Annonser

Sluta chansa

november 8, 2008

Det finns en ihärdig fördom runt lättrörliga metoder som säger att lättrörliga metoder är till för de slarviga. De som inte orkar tänka efter först, de som inte gillar att ta fram en genomtänkt systemdesign, de som inte vill dokumentera först utan bara slarva fram något utan att tänka efter först.

Även om det finns ett litet, litet korn sanning i det ovanstående så tänkte jag rikta ljuset mot de stora missförstånden istället.

Agila metoder ser gärna att man tänker till innan man börjar arbetet, men inte på bekostnad av att tänkandet under och efter arbetet. Med den komplexa problematik som vi ställs inför under ett utvecklingsarbete kan man inte kosta på sig ”lyxen” att bestämma sig återkalleligt för någonting innan implementationsarbetet är igång. Vi måste utnyttja all information vi har för att kontinuerligt fatta så bra beslut som vi kan.

Gårdagens eller dagens?

Tidiga beslut skänker en viss trygghet, men den tryggheten är bedräglig. Ofta kan beslut som fattats tidigt visa sina baksidor sent i projektarbetet och då måste vi vara förberedda på att omvärdera besutet. Har vi då istället byggt upp en projektkultur som säger: Först kommer den smarta gruppen att tänka, sedan ger de oss en design och efter det implementerar vi den, ignorerar man den lärdom som man förvärvar under projektarbetet och baserar då lösningen på gårdagens kunskap istället för dagens.

Man kan fortfarande säga att ”vi använder MySQL” eller ”vi implementerar det i Ruby” dag ett men man kan försöka fundera på hur man förhåller sig så neutral som möjligt trots de besluten. Vi kanske inte ska kasta oss över de specifika mysql-funktionerna innan vi verkligen behöver dem. Kanske ska vi välja JRuby för att kunna hålla oss mer öppna mot Java-världen?

Så det är inte en benägenhet att slarva som driver oss till att inte göra en alltför genomarbetad förstudie, det är vetskapen om att vi imorgon kommer att ha så mycket bättre förutsättningar för att fatta bra beslut.

Traditionellt har vi föredragit att dra till med en ”best guess” och kallat den en plan för att sedan bli mäkta irriterade när denna plan inte håller. Vi agila förespråkare säger: Sluta chansa, låt oss fatta de beslut som vi är kapabla att fatta för tillfället och vara förberedda på att omvärdera när vi vet bättre.

Skäms på dig hjälte!

november 3, 2008

Många är de gånger då jag har bevittnat hjältar i arbetssituationer. Folk som burit hela projekt på sina axlar. Folk att lita på, som får saker gjorda. De är projektledaranas gunstlingar. De hyllas som räddare i nöden och som värdefulla projektmedlemmar.
Det finns dock en baksida med dessa hjältedåd. De är det yttersta beviset på att du har en dålig dynamik i gruppen. För att bli en hjälte måste du nästan vara dålig på att samarbeta. Hade du varit bra på att samarbeta hade du snabbt lyft din omgivning till en nivå där du kanske inte varit en så tydlig hjälte. Däremot hade du varit orsaken till att ett högeffektivt team skapats.

Varje gång man ser en hjälte ska man fundera på vad som skulle kunna få denne hjälte att börja samarbeta. Varje gång du själv känner dig som en hjälte borde du fundera på vad du gjorde för fel.

Man bör vara tacksam för att man har duktiga medarbetare, men man ska skämmas om man är beroende av dem liksom de ska skämmas för att de inte samarbetar.

Att bilda de bildade

september 8, 2008

Vi behöver ett nytt sätt att se på högre utbildning av redan bildade systemutvecklare. Idag förutsätter vi att det alltid finns någon som kan skedmata oss med sin kompetens. Det är en strategi som främst är gångbar för oerfarna systemutvecklare, men när man som mer erfaren systemutvecklare ska fortbilda sig så är man, i hög grad, hänvisad till solitära självstudier.

Det finns uppenbara nackdelar med den här strategin.

Jag har tänkt göra ett, måhända fåfängt, försök att formulera en ny strategi, främst riktad mot högre utbildning av redan hantverksskickliga systemutvecklare. De idéer som jag formulerat, tillsammans med ett par av mina systemutvecklarvänner, bygger i mångt och mycket på konferensformen Open Space. Som så många andra framgångsrika strategier så bygger utbildningsformen på att:

  • Maximera samarbetet
  • Öka utbytet mellan olika kompetenser
  • Minska overhead-kostnaderna
  • Möjliggöra anpassning till snabb förändring

Först tänker jag redogöra för grundupplägget för utbildningsformen, sedan tänkte jag redovisa en samling vanor som jag tror kan komma att beskrivas som frivilliga ”best practices”. Sist tänker jag argumentera för hur formen löser de problem som idag finns med högre vidareutbildning av systemutvecklare.

Ett nytt upplägg

En utbildning modereras av en eller flera moderator(er).

Gruppen av deltagare får först en snabb förevisning om formatet på utbildningen.

Varje medlem i gruppen får sedan chansen att föreslå ett eller flera ämnen som man vill ta upp. Dessa ämnen presenteras inför gruppen och representeras av indexkort eller likn. på en tillgänglig vägg.

Sedan anmäler man sig till det ämnet som man helst vill arbeta med under den närmsta sessionen. Ämnen godkänns genom den acceptans som ämnet får när deltagare anmäler sitt intresse.

Den sista delen av sessionen håller varje grupp en kort presentation inför samtliga deltagare där man formulerar vad man lärt sig under sessionen.

Faciliterarnas roll är att se till att ingen grupp hindras av tekniska problem eller av att man inte begripit formen för utbildningen.

Rekommenderade vanor

Här följer ett par vanor som kan tjäna som insipration till den som utformar kurstillfällen.

Ämnesformuleringar

När man formulerar ett ämne så ska man formulera ämnen som man kan tänka sig att själv bidra aktivt till i imperativ (ex. ”Att skriva förvaltningsbara testfall.”). Om det istället är så att man har väldigt begränsade kunskaper i ämnet så kan man formulera sig som en fråga (ex. ”Hur skriver man förvaltningsbara testfall?”)

Gruppstorlekar

Om ämnet kräver programmering så bör inte större grupper än tre personer tillåtas. Bättre är då att dela upp de, exempelvis, 5 personerna i en grupp om tre och en om två personer. Sedan finns det ju inget som hindrar dem från att samarbeta nära mellan undergrupperna. Diskussionsämnen påverkas inte i samma grad, men det kan vara värt att även försöka hålla de grupperna mindre än sex deltagare så att alla känner att man hinner bidra och delta.

Sessionslängd

Man bör hinna med minst 5 sessioner på en dag där varje session tar ca. 90 minuter varav de sista 15 minuterna går till att presentera vad man gjort.

Tema

Inför en utbildning kan det vara bra att göra en grovsortering genom att slå fast ett tema ex. ”agil systemutveckling” eller ”systemintegration”.

Kalendarium

Utbildningstillfällen bör ges med förutsägbara intervall så att man kan som deltagare kan välja att förvarna sina uppdragsgivare om frånvaro.

Utrustning

Deltagaren ska själva ta med en bärbar dator alternativt, med god framförhållning, avisera att han/hon behöver låna dator för dagen.

Faciliteraren ska tillhandahålla trådlöst och trådat nätverk med internetanslutning.

Faciliteraren ska hålla med blädderblock, whiteboards, indexkort, post-its och lämpliga filtpennor.

Lokaler

Om akustiken är olämplig så bör flera rum tillhandahållas så att grupperna inte stör varandra.

Motivering till upplägget

Kunskapsnvåerna Shu, Ha, Ri lär oss att vi med stigande grad av bildning får en ny attityd till vårt kunnande och även nya förutsättningar för vårt lärande. Ett utbildningsformat som fungerar för en nybörjare fungerar inte nödvändigtvis för någon som redan hunnit fördjupa sig i ämnet och tvärtom.

Kollektivt ägarskap

Som redan bildad kan tid för reflektion tillsammans med andra bildade vara effektivt. Som nybörjare kan det mest verka förvirrande, då vill man istället ha handfasta recept på framgång. Dessutom har man som mer avancerad utvecklare börjat tillämpa egna vanor som kan vara intressant att få återkoppling på tillsammans med andra lika avancerade yrkesutövare. Det motiverar varför man inte ska ha lärarledd undervisning. Vi vill alla bidra och lära oss av varandra och när vi redan har tiotalet erfarna utvecklare samlade så är det slöseri att bara förlita sig på en eller två av dem.

Öppen agenda

Som engagerad utvecklare får man ständigt stimulans att prova nya verktyg, ansatser och attityder till att angripa välkända problem. Det som saknas är den där avsatta tiden då man i lugn och ro kan koncentrera sig på att leva ut de nya idéerna. Jag vill att den nya utbildningsformen ska fånga upp de aktuella intressen som man går omkring med. Därför är det av stor vikt att man har en öppen agenda för utbildningen. Vi vill bli av med attityden att läraren vet bättre vad du behöver lära dig än du själv.

Pris/prestanda

Kurser idag är tämligen dyra. Det är inte ovanligt att man får betala 10.000:- för en  endagsutbildning. För IT-konsulter som har en alternativinkomst på 1000:-/tim ger det en totalkostnad på ca. 18.000:-. En, inte obetydlig, del av det man betalar för är lärarens förberedelsetid. Med detta nya format krävs i stort sett ingen förberedelsetid alls. I princip borde man kunna komma ner i en kostnad på ca. 3000:-/deltagare och dag (11.000:- inklusive inkomstbortfallet) för en grupp om ca. 15 personer. Med en sådan kostnad är det rimligt att kunna ha råd med en tvådagarsutbildning minst två gånger om året.

Framtidssäker

Att kunna förändra kursen snabbt är en viktig framgångsfaktor. Genom att kursen utformas på plats och med hjälp av alla deltagares kunnande kan man garantera att kursen ständigt uppdateras med de senaste idéerna.

Noterbart

Kanske lite förmätet att tacka de som inspirerat till en blogpost men jag känner att jag vill sända ett stort tack till Peter Krantz och Niklas Lindström som förstod mitt hypomaniska tillstånd och snabbt avbröt sina respektive arbetsuppgifter för att ta en fika på Drottninggatan bara för att höra mig redogöra lite osammanhängade för min idé. Ett stort tack även till Joakim Holm som nästan missade sin tvättid för att ta sig tid att ge återkoppling på idén.

Till er tre: er respons var, som vanligt, klarsynt och mycket givande. Utan er hade min idé fortfarande varit luddig och ogripbar som ett cumulusmoln.

Tack även till Mats Oldin som var den som ställde mig frågan hur man ska utforma en utbildning som inte löper risken att bli inaktuell en månad efter att den tagits fram.

För en tid sedan träffade jag en gammal skolkamrat på väg hem från jobbet. Det slog mig då att, sist jag träffade honom, formulerade han en så sympatisk syn på samhällsekonomiska system. Nu ska jag väl genast infoga att jag inte är speciellt bevandrad i idéhistoria så det behöver ju inte nödvändigtvis vara han själv som är upphovsmannen, men för mig var det en ”ögon-öppnare”. Till dess hade jag mest fått höra för och mot plan- och marknadsekonomiska system och mest insett att det hela är en fråga om mänskliga värderingar. Så som min vän formulerade det så kan ett samhälle värderas utifrån hur mycket samarbete respektive motarbete som finns inom samhällsstrukturerna. Sålunda kan man exempelvis säga att marknadsekonomins tendens till att skapa konkurrens är dess svaghet. Det är ett resursslöseri att motarbeta varandra på det viset. Samtidigt kan man i planekonomin se att korruption är en typ av motarbete där en person inte ser till samhällets bästa utan sätter sin egen privata ekonomi först.

Jag ser klara paralleller till hur olika utvecklingsmetoder kan bedömas. Det har blivit mycket populärt att prata om projekt som agila (lättrörliga) kontra traditionella a’la vattenfall. Kanske är det ännu mer intressant att bedöma dem efter hur mycket samarbete respektive motarbete de stipulerar?

Inom lättrörliga metoder ligger stor fokus på att kommunicera väl och på ett begripligt vis (informell verbal kommunikation, enhetliga språk där kundens egna termer används och koncisa dokument där de behövs), traditionella metoder har en artefakttyngd värdering där, lite hårddraget, inget finns som inte är dokumenterat i ett godkänt dokument. Här har vi verbal kommunikation mot dokumentation. Den verbala kommunikationen förutsätter samarbete – ni måste finnas på samma plats vid samma tidpunkt. Dokumentationen låter det vara öppet. Visserligen finns det inget som hindrar att du skriver ett dokument till någon som står bredvid dig eller att ni t.o.m. skriver det tillsammans, men det är ofta mer frestande att skriva sina dokument ensam och skicka dokument över e-mail och låta den andra parten få läsa dokumentet ”i lugn och ro”.

I traditionella projekt har man en tydlig rollfördelning där man har distinkt olika ansvar. Det finns, projektledare, beställare, utvecklare, arkitekter, testare och ibland även varianter på ovanstående med prefix såsom ”senior” eller ”junior”.

Man hamnar då i situationer där vissa uppenbara brister i organisationen kan vara ”någon annans problem”. Istället för att inse att alla problem som organisationen har är hela organisationens problem.

En av de mest kritiserade vanorna inom lättrörliga utvecklingsmetoder är vanan av att jobba i par om två. Logiken bakom det är att det aldrig finns bara en som kan någonting och att mindre erfarna utvecklare för lära sig en massa praktiska knep av mer erfarna utvecklare. Mot det står givetvis den fördyrande omständigheten att ha två personer som utför samma arbete – till synes utan någon hastighetsökning. Den kritiken är dock inte helt berättigad eftersom kvaliteten på det producerade blir högre och det, annars obligatoriska, efterarbetet med buggrättning begränsas; samtidigt som man har investerat i en försäkring som ger dig möjligheten att, med kort varsel, förlora en projektmedarbetare utan att projektets hastighet rubbas nämnvärt.

Jag har ofta konfronterats med personer som, när de stirrat nederlaget i vitögat, gjort allt för att skjuta över problemet till ett annat bord utan att ha försökt rätta till skadan. Nyligen var det en som försökte skjuta över en hög smuts på mig. Jag frågade honom vad han förväntade sig skulle hända nu när han tog avstånd från problemet i förvissningen om att han inte skulle få skit för det. Svaret var fascinerade frankt: – Ja, alltså, jag förstår att du inte har möjlighet att fixa de här problemen, men jag vill ju ha ryggen fri, så att säga…

Då frågade jag honom om han trodde att någon konstellation på företaget tillsammans var kapabla att lösa problemen och, jo det trodde han nog. Jaha, men då är det väl bättre att vi försöker samla den skaran för att se om vi kan komma tillrätta med det hela. Jag påpekade också att det här med att skylla ifrån sig kan han väl vänta med till dess slaget är förlorat, jag menar mitt under ett projekt är det ju mest en form av sabotage. Hans minspel ändrades något och han verkade nästan roat försöka förstå vad jag höll på med.

Jag försökte samarbeta. Kontroversiellt, måhända, men vansinnigt effektivt. Tyvärr kan jag inte säga att problemen är lösta än, men nu jobbar man i alla fall kreativt på att lösa dem.

Istället för att fundera över vad som är lättrörligt eller inte så kan man ta avstamp i att arbetsmetoder ska främja samarbete. Det kollektiva engagemanget och den kollektiva ansvarskänslan leder till ett produktivt arbetsklimat.

En god vän till mig, som är musiker, hade en gång en flickvän, även hon musiker, som hade blivit duktigare än honom på deras gemensamma huvudinstrument.

Inget konstigt i det (förutom att min vän är så musikaliskt avancerad att han sällan träffar på personer som är odiskutabelt bättre än han är). Jag pratade med honom om det och undrade hur han förhöll sig till det. Han kände att det var helt okomplicerat men han hade gjort en intressant iakttagelse som för honom besvarade frågan – varför har hon blivit bättre än jag?

Det visade sig att hon, i tidiga år hade bestämt sig för vilken nivå hon skulle hålla – lite som att sätta sin lägstanivå. Hon bestämde sig för att den nivån skulle hållas oavsett om det i publiken bara satt två nittioåringar med tjutande hörapparater eller om hon spelade solo inför ett fullsatt Berwaldhallen. Det gjorde att hon aldrig gick till ett jobb utan att känna att hon var väl förberedd på att göra ett riktigt bra arbete och därför heller aldrig blev påkommen med att ha gjort någon spelning på slentrian. Givetvis medförde det att hon oftast överträffade de förväntningar som hennes uppdragsgivare hade haft och sakta men säkert plöjde hon en framgångsrik karriär i frilansmyllan.

Den hängivenheten är fortfarande ganska vanlig bland musiker men bland oss som arbetar som IT-konsulter är den inte alls lika självklar. För många är jobbet som IT-konsult, ”bara ett jobb”. Ett jobb som är tämligen omväxlande och som, i bästa fall, inte tar mycket mer än de 38 timmar i veckan som man helst jobbar. Ett jobb där man blir tillsagd att lösa diverse problem och när man löser dem får man en klapp på axeln och då kan man unna sig en extra lång fikapaus eller en tidig hemgång.

Med den attityden får man dock räkna med att se sig akterseglad. För det finns IT-konsulter som har samma attityd till sin lägstanivå som vissa musiker. IT-konsulter som är dedicerade till att hela tiden överträffa omgivningens förväntningar. Den här kolumnen är ämnad åt er som bestämt er för att ständigt bli bättre. Jag har träffat många av er genom åren och här kommer mina iakttagelser av er.

  • När du får en uppgift funderar du alltid på hur du kan leverera något bättre inom utsatt tid.
  • När du ser brister eller behov i organisationen föreslår du hur man kan komma tillrätta med den situationen.
  • Du ser hela tiden till att din kund blir uppmärksam på hur IT-stöd kan ge verksamheten slagkraft mot dess konkurrenter, alternativt (för icke konkurrensutsatta verksamheter) leda till besparingar i tid och/eller pengar.
  • Du håller dig uppdaterad om allt som angår dig och din roll som systemutvecklare.
  • Du skapar mervärde genom att lära dig mer om sådant som de flesta IT-konsulter inte kan, exempelvis: user experience design, intellectual property rights, arbetsmetoder, kommunikation, team building.
  • Du låter alltid din kreativitet överglänsa din kritik över sådant som fortfarande är dåligt. Det är alltså bättre att säga ”Titta vad mycket enklare det blir om man använder det här verktyget för att dela information”. Istället för att säga ”Jag vägrar att skriva word-dokument eftersom de har så dåligt team-stöd”.
  • Du beaktar alltid din uppdragsgivares invändningar mot dina angreppssätt – de leder vägen mot ett ännu bättre sätt att arbeta på.
  • Du vårdar ditt CV, tar inte uppdrag som leder i en riktning som inte ligger i fas med vad du vill syssla med.
  • Du håller dig uppmärksam på att man som konsult inte får glömma att man har två arbetsgivare som man ska upprätta en god relation till och du ser till att överträffa förväntningarna hos båda dina arbetsgivare.

Till alla er som känner er träffade – jag älskar att jobba med er! 🙂

Ambitioner är slöseri

februari 20, 2007

Att göra storskalig projektplanering är en favoritsysselsättning bland projektledare. I synnerhet inom större organisationer tar man gärna till en storskalig planering. Problemet med det är att eftersom planeringen är så storskalig väljer man att förenkla världsbilden genom att dela in planen i övergripande faser så att aktiviteterna ska synas i den stora skalan.

Det är frestande att börja med att konstatera att man ska ha en förstudie på 4 veckor sedan har man en designfas på 6 veckor, därpå följer en implementationsfas om 10 veckor och sedan givetvis test (kanske 5 veckor) och slutligen en acceptanstest från kunden om ca. en månad. Allt ser på pappret plötsligt välordnat och fint ut. Genast börjar man arbetet med att resurssätta – ett fint ord som eventuellt bara används inom IT-projekt – man kontaktar konsultleverantörer och för att slimma kostnaderna ser till att folk ska ansluta till projektet exakt efter den plan som man har fastslagit. Exempelvis kommer testarna in efter 20 veckor och jobbar i 5v. Ett par utvecklare behåller man under testarbetet eftersom man vet av erfarenhet att det alltid finns lite buggar att ta hand om då.

In kommer sedan ett gäng duktiga utvecklare som ska vara effektiva och ”köra agilt” (agile software development). De lyckas hyfsat och projektet följer, lustigt nog, den från början utstakade projektplanen.

Men så händer något oväntat. Kunden kan, p.g.a. sin egen administration inte ta emot leveransen enligt plan utan ber leverantören att leverera två månader senare. Lyx! 8 veckor till att leverera kundnytta på!
Här visar dock den, ambitiösa, övergripande planeringen sin svaghet. Resurssättningen var avpassad för en fasindelad utvecklingsplan, den kan man inte bara ändra i. Den givna lösningen att låta utvecklingen fortsätta ett par veckor till fungerar inte eftersom de som ska testa redan är resurssatta för ett annat projekt.

Lösningen på problemet är lika enkel som genial, projektadministratörerna get slaget förlorat och konstaterar att: Vi levererar enligt plan och sedan får ”linjen” driva arbetet vidare.

Vad är det som gör att ”linjen” (linjeverksamheten) mer framgångsrikt kan hantera en sådan situation? Undrar vän av ordning.

Svaret ligger i kontinuerlig (om-)planering. I en linjeverksamhet måste man ha förmågan att ständigt manövrera runt oförutsedda händelser och med kort varsel kunna släppa en ny version av produkten som man underhåller. Därför har linjeverksamheter ofta bättre utvecklade leveransprocedurer som gör att man snabbt och enkelt kan driftsätta det bästa man har. Fungerande kod gör ingen nytta genom att enbart stillatigande placeras versionshanteringssystemet, den ska driftsättas och skapa avsedd nytta.

En rimlig frågeställning, varför behövde inte linjeverksamheten ett test-team? Jo, för att testbehovet är kontinuerligt och alla tekniker i en linjeverksamhet måste kunna ta ansvar för att det som driftsätts är genomtestat. Det driver också utvecklingen av snabba, automatiserade tester som låter människor göra det de är bra på (komplex, adaptiv planering och implementering) respektive låter maskinerna göra det de är bra på (repetetivt, förutsägbart beteende). Det sista resonemanget fungerar eftersom tekniker i regel är bra på att undvika ett aldrig sinande enformigt arbete genom välja att skriva en applikation som utför det arbetet åt dem.

Min vädjan till dagens projektplanerare blir – se på er linjeverksamhet och lär. Ni är inte bättre än dem, de är bättre än er.

Bakgrund

Systemutveckling har alltid betecknats som ett risktagande, vi vet inte innan vi börjar hur lyckat resultatet ska bli och vi vet inte vad det kommer att kosta eller när det kommer att vara klart. Vi vet inte heller från och med när vi kommer att kunna tjäna pengar på det och oftast inte heller hur mycket pengar vi kommer att tjäna eller förlora.

Naturligtvis är inte ovanstående förutsättningar rimliga i en värld som styrs av väldigt nervösa ekonomiska intressen som helst fokuserar på kortsiktiga vinster.

Det är också därför som man, sedan en lång tid tillbaka, försökt rita om verkligheten så att den blir lite mindre krass för de som vill investera i systemutveckling. Riktlinjen har under många år varit standardlösningar. En standardlösning är typiskt baserad på en ”färdig” applikation som på ett övergripande vis löst de huvudsakliga problem som du förväntas ha inom ett visst omåde (exempelvis inom fakturering). Det enda du ska behöva göra för att anpassa standardlösningen till dina specifika behov är att konfigurera applikationen med ett par begripliga parametrar.

Det är en förförisk tanke och man kan ju förstå att den öppnade dörren till en uppsjö av hel- och halvfabrikat som har sålts för dyra pengar till företag som velat riskminimera deras systemutveckling.

Semantiken

Själva ordet standardlösning behöver nog dissikeras innan vi fortsätter. Den första delen standard är ju en viktig del av ordet – en standard ger liksom en massa goda associationer av något som fungerar överallt och som är tillförlitligt över tid. Dessutom förväntar man sig att det är så eftersom det finns någon form att ickekommersiell instans som utvecklar standarden och som kan godkänna implementationer av standarden, och kanske t.o.m. förse godkända implementationer med något sorts sigill som tydligt kommunicerar till köparen vilken version av standarden som är implementerad. Enligt den engelska versionen av wikipedia förklaras standard såhär :

”Common use of the word standard implies that it is a universally agreed upon set of guidelines for interoperability.”

Tillbaka i standardlösningen måste vi tyvärr konstatera att standard i just standardlösning inte är riktigt lika standard som standard. Istället betyder det här en lösning som, tillverkaren menar att, inte bara du kan använda. Ok, det är ju lite annorlunda, men det finns ju fortfarande en del kvar i ordet och en färdig lösning på ett problem är ju trots allt väldigt bra, även om det inte är en standard.

Har du ett standardföretag?

Här kommer vi in på hur vi använder standardlösningar. Jag nämnde tidigare att du förväntas göra enkla anpassningar av standardlösningen för att den ska fungera i just din organisation. Ofta är det dock inte nog. Som organisation har du ju ett intresse av att representera dina specifika konkurrensfördelar i ditt IT-system och de är ju av hävd inte standardlösningar.

En kollega till mig illustrerade ett sådant problem för bara någon vecka sedan. Han sitter hos en kund (mycket stort svenskt företag med gedigen IT-erfarenhet) där de har använt SAPs CRM lösning vilket är en stor standardlösning för att upprätthålla kundrelationer, i princip kan man säga att det är ett kundregister där man kan upprätta rabatter, köra kampanjer, registrera användarens språkliga preferenser bland mycket annat. Han vittnade om att de hade gjort så många specialanpassningar av standardlösningen att de inte längre kunde uppgradera standardlösningen till de nya versioner som släpps av den. De har dessutom bara ett ytterst begränsat utbyte av den support som de kan få av leverantören (SAP) eftersom de har valt att låta IT-systemet anpassa sig till organisationen… men vänta nu – vad är det för fel i att göra det?

SAP (och många andra leverantörer med dem) hävdar, sensationellt nog, att det är bättre att anpassa organisationen efter deras standardlösningar än tvärtom.

I och med det påståendet tycker jag att de har skjutit sig själva i foten – det klingar väl med att det inte är en standardlösning för alla företag, det är snarare en lösning (utan standard) för en speciell sorts företag som inte har några visioner om att skaffa sig konkurrensfördelar inom de områden där lösningen ska användas.

Unika lösningar

Det finns massor av fungerande standarder i branschen (HTTP, SQL, TCP/IP, JEE), de är kanske inte standardlösningar men de tjänar just de syften som en standard ska och nu när jag presenterar fördelarna med utveckling utan standardlösningar så betänk att de fortfarande vilar på en stabil grund av riktiga standarder som bottenplatta.

Jag har själv varit med i ett par stora projekt där vi utvecklat helt ny programvara och där har den utgjort symbolen för företagets innovationskraft och originalitet. Dessutom är det, i förhållande till den tämligen blygsamma investeringen, en fantastisk dörröppnare hos kunder att säga: ”Vi har en unik lösning som ni inte kan hitta någon annanstans.”

Den tidigare åsikten om att utveckling av specialiserad mjukvara är mer riskfylld än anpassandet av standardlösningar är till stora delar en myt. Projekt med standradlösningar ha visat sig vara dyra, svåra att budgetera, konsultintensiva och ha stora brister i flexibilitet. Dessutom finns problemet att man bygger upp specifik kompetens runt en eller flera proprietära produkter. Sådan kompetens är sällan användbar i andra sammanhang. Idag är vi dessutom mycket bättre på att utveckla unika lösningar av utmärkt kvalitet som levereras på utsatt tid och enligt budget, baserade på riktiga standarder som inte inkräktar på ditt företags integritet.

Så slutligen, tillbaka till det första problemet, hur gör vi med de orimliga riskerna om standardlösningar inte är svaret?

En sådan uppsättning risker som mjukvaruutveckling medför kan inte elimineras, den måste hållas under uppsyn. Det kan vi bara göra genom att upprätta en rak och ärlig kommunikation mellan beställare och leverantör. Beställaren ska regelbundet ges chansen att styra projektet i den riktning som de tror är mest fördelaktig för dem sedan leverantören klart redogjort för vad det lyckats åstadkomma under den senaste utvecklingsperioden. Mellan de kontrollpunkterna ska leverantören ges ro att leverera ett inkrement som är prioriterat av beställaren.

Beställaren måste kontinuerligt hålla koll på deras Return On Investment (ROI), skulle det vara så att man inte kan räkna hem sina investeringar inom rimlig tid så måste man avbryta investeringen direkt så att pengar inte spenderas i onödan.

Bakgrund

Mången gång har jag suttit på företagsmöten och hört orden
– ”Vi har lite dålig beläggning just nu, men pajpen (sv. röret) är rekordstor, så vi räknar med att det kommer att bi bättre inom kort.”

Pajpen? Ja, det kan närmast förklaras som en topologisk definition av den samling säljansträngningar som en säljkår har på sitt samvete. Själva ordet kommer av engelskans pipe el. pipeline som kan översättas rör och gas- eller oljeledning.

En smula sund skepticism…

Jag har alltid tyckt att den slutsatsen att ”en stor pajp leder till många framtida affärer” är lite förhastad – är det verkligen så att pajpen fungerar som ett vanligt rör där det man stoppar in kommer ut i samma ordning på andra sidan (i alla fall om det man stoppar in är större än radien på röret)?

Skulle det vara sant så blir det lite märkligt när man beskriver vissa element i pajpen som ”kalla” och andra som ”heta”. ”Kalla” objekt väntar man sig egentligen aldrig att de ska lämna pajpen, de förblir där så länge att man till slut undlåter att prata om dem – lite som en gammal möbel på landet som man inte använder, men som har hittat sin plats och smälter så bra in i omgivningen att man glömmer bort att den finns där.

Vi kan konstatera att allt som vi stoppar in i pajpen inte kommer ut ur pajpen – och, i den mån de verkligen gör det, sannerligen inte i rätt ordning.

Hamnar allt i pajpen då? Jag menar det är ju ointressant att använda en liknelse som bara täcker in en del av de affärer som verksamheten hanterar. Nja, riktigt så är det ju inte – om en kund ringer till en säljare och ger uttryck för ett verkligt behov såsom: – ”Ge mig två konsulter så fort som möjligt – helst igår!”. Då kan man inte riktigt säga att den affären har gått genom pajpen, den har liksom tagit en mer levande form och självt skuttat fram i fokus utan inflytande av den säljkår som med sina slipade power point-ansträngningar ska få kunder att inse att ”Ska jag köpa konsulttimmar – så är det av honom jag ska köpa dem!”.

Vi kan konstatera att inte alla affärer hamnar i pajpen.

Vanliga rör har ju en viss kapacitet – har pajpen någon kapacitet? Nja, här är det ganska tydligt att det finns någon sorts kapacitetsbegränsning vad gäler hur många olika affärer man kan stoppa in i pajpen under en viss tidsrymd – det ställer ju trots allt vissa krav på en säljorganisation att kontakta potentiella kunder så att de inte omedelbart avfärdar inviten. Däremot brukar ju pajpen ofta mätas i pengar (kilo kronor är ju ett populärt mått, ofta förkortat ”K” med engelsk uttal) och det verkar inte finnas någon begränsning vad gäller hur stora affärer man stoppar in i pajpen.

Vi kan konstatera att pajpen har en maximal ingångskapacitet, men väl inne finns det oändliga vidder till skillnad från ett ordinärt rör.

Låt oss försöka lära känna röret via de omslutna objekten. Tydligt är ju att de är någon form av säljansträngning som inte har resulterat än och det är rimligt att kunden inte har något verksamhetskritiskt behov av att realisera den affären. Alltså försläjningsansträngningar som stött på patrull. Vissa ansträngningar leder till helt ”döda” uppslag – andra till uppslag som gått in i ett skendött tillstånd, men där man har förhoppningar om att de, med rätt stimuli, kan kvickna till.
Summering

För att summera iaktagelser – pajpen är en plats dit affärer som ej har livskraft nog att utvecklas på egen hand får vila i tysta rum under oroat vaksamma blickar av power point-läkarna som hoppas att de ska slippa dumpa affären i det svarta hål som bildats, i bårhusets källare, av alla oavslutade affärer som klumpat ihop sig till en oigenkännlig massa av misslyckanden.

Nästa gång någon försöker trösta dig med att ”Pajpen är rekordstor!” – var på din vakt, du har troligen bara en överdimensionerad säljkår som inte lyckas sälja levande projekt baserad på verkliga behov.

En myndighet som vill köpa en IT-lösning har, redan innan projektet börjat, hamnat i knipa.

Fienden heter ”offentlig upphandling”. Lagen om offentlig upphandling har anpassats för upphandlingar av konkreta varor och tjänster som exempelvis att:

  • …asfaltera tjugo mil motorväg
  • …sköta renhållningen på södermalm.
  • …mäta grundvattennivåer i någon halländsk ås.

De ovanstående aktiviteterna har inte mycket gemensamt med mjukvaruutveckling, de är alla tämligen förutsägbara aktiviteter med ett tämligen lättdefinierat mål. Alla som svarar på en offentlig upphandling måste täcka in hela den definierade målbilden. Om en leverantör missar att svara ”Ja” på ett av kraven kan en konkurerande leverantör, vid förlust, överklaga beslutet med hänvisning till att hela kravlistan inte var täckt av den vinnande leverantören.

För en myndighet som vill ha en bro fungerar detta ganska bra – visserligen kan en bro vara knepig att konstruera, men den är enkel att beskriva med geometriska mått, trafikgenomströmningskapacitet och hållbarhet. Mjukvara med tusentals funktioner låter sig inte, framgångsrikt, beskrivas på det viset. Där har IKIWISI (I’ll Know It When I See It) visat sig vara en mer framkomlig väg. Beställaren ska alltså ha möjlighet att följa utvecklingen på nära håll och korrigera riktningen på projektet när det anses nödvändigt.

Tyvärr har ingen alternativ lag stiftats för att underlätta mydigheters upphandling av mjukvarutjänster. Det betyder att myndigheterna har fastnat i en projektplanering för mjukvaruprojekt som om och om igen har visat sina svagheter i form av dålig ekonomi och dålig träffsäkerhet i resultat (m.a.o. man leverar inte en lösning på det avsedda problemet).

Men det här var inte menat som en klagosång – det finns öppningar som har börjat användas.

Som myndighet har man möjligheten att driva interna projekt, utan offentlig upphandling. Enda kravet är att myndigheten själv tar leveransansvaret och det finns inget hinder för att ta in en extern leverantör av själva konstruktionsarbetet på konsultbasis. Fördelen med det här angreppssättet är att man inte behöver slänga en massa tid på att skapa en enorm kravspecifikation inför en upphandling och man har möjligheten att utvärdera leverantörer under projektets gång (om en leverantör underpresterar så byter man bara). Man har t.o.m. möjligheten att byta ut enskilda konsulter som man inte tycker levererar i paritet med vad de kostar.

Främsta fördelen är dock den som jag nämnde tidigare, man har möjligheten att se hur produkten evolverar och kontinuerligt styra projektet mot ett mål som ger verksamhetsnytta.

Myndigheter som ser framför sig att de ska beställa mjukvara bör skaffa sig projektledarkompetens, ta hem projekten och skaffa sig ett gott samarbete med en högpresterande grupp systemutvecklare.

Låt inte våra skattepengar gå till dyra högriskprojekt – definiera istället den nya tidens lättrörliga myndigheter.