Jag hade en chef för en tid sedan som stolt förklarade för mig att anställda vill ha en chef som säger nej. Jag är helt säker på att han hade vissa belägg för sitt påstående, men jag är lika säker på att det finns en mer nyanserad formulering som ligger ännu närmre sanningen. Personligen vill jag ha en chef som skapar goda förutsättningar för de anställda att själva förstå hur de ska tackla de problem som de ställs inför. Jag kallar det ”management från sidan”.

En chef, eller gruppledare, ska se sig som en ledsagare som har en god idé av vilket klimat han vill skapa på arbetsplatsen och sedan gör allt för att det klimatet ska uppstå genom de anställdas engagemang. Problem som uppstår i organisationen ska inte gömmas undan i något styrelserum, det ska upp på den största whiteboard man har och sedan ska alla känna att de har rätt att bidra till en lösning av problemet. Likadant med företagets framtidsvisioner. Som ledsagare kan man visa på framkomliga vägar men man behöver inte se till att alla ”rättar sig i ledet”, ofta kan kunskaperna hos kollektivet hitta en ännu mer framkomlig väg som ger samma resultat och då ska de inte hindras från att få välja den vägen.

Jag känner mig manad att ge alla ni chefer därute (som tyvärr aldrig kommer läsa detta…) en lista på vad ni borde tänka på:

  • Lita på dina anställda – de vill också känna sig engagerade.
  • Var öppen med organisationens problem om du vill ha dem lösta.
  • Även ”fotfolk” förstår problem som ett företag ställs inför.
  • Att lösa problem är roligt, du kommer att ha många frivilliga medhjälpare.
  • Att låta de anställda vara med och besluta om vad som är företagets största problem kommer vara intressant både för dig och de anställda.
  • Förståelsen mellan arbetsgivare och anställd kommer att öka och, rentav, bli god.
  • Var inte rädd att säga vad du tycker men se till att du inte underkänner någon annans åsikt. De vet att du har sista ordet – du behöver inte hävda dig på den punkten.
  • Se till att du förstår de synpunkter som kommer in – vissa åsikter kan te sig helt galna, men de är också de mest intressanta. Kanske kan ni, tillsammans, förädla dem.
  • Eftersom ni troligen inte arbetat såhär tidigare så får du tänka på att det kan ta lite tid för dina anställda att vänja sig vid det nya arbetssättet.

Slutligen – försök att inte vara en semafor-chef, föreställ dig istället att du står vid sidan om organisationen och iaktar lite som en lugn fotbollstränare. Finn glädje i att coacha dina anställda när du tror att det är välkommet och när du tror att du har något att bidra med, men det är de som ska lösa problmen och de måste få den information de behöver för att kunna hitta den bästa lösningen.

Annonser

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.

Wilmer-X hade fel

september 21, 2006

”Du kan glömma dina ensamma stunder – du kan lita på teknikens under!”

Jag var fortfarande en gänglig pubertal kille. Internet var fortfarande något som de amerikanska universiteten och den amerikanska militären nyttjade för att dela forskningsresultat. Årets julklapp var en bakmaskin.
För att vara modest kan man säga att Wilmer-X’s Teknikens Under från 1988 var aningen före sin tid. Redan då fascinerades jag av den märkliga texten, givetvis helt ovetandes om att den ca. 15 år senare skulle komma att förverkligas.

Jag tror att det var år 2001 som jag för första gången träffade en kompis som presenterade sin nya kärlek som han hade ”träffat på Internet”. Jag minns att det var lite omtumlande – lite som när en nära vän berättar att han/hon är homosexuell eller att hon väntar barn. Man ville ju inte verka intolerant eller oförstående så det vara bara att svälja ner sina förstockade fördomar och hälsa glatt på den nya bekantskapen.

Vanligtvis tycker jag att mina fördomar är ganska lättmotade och efter lite provokation brukar de ge med sig, men när det gäller dejting på internet så har någonting i mig stannat kvar trots att det nu blivit så allmänt accepterat. Varför känns det så instinktivt fel?
För att göra upp med den känslan satt jag mig för en tid sedan och började gräva i mina värderingar för att se vad det var som krockade. Kärlek är ju något som jag unnar alla och jag har ju endast sällan varit en bakåtsträvare när det gäller tekniska framsteg, men ändå var det just tekniken som jag hängde upp mig på.

Jag tänker på alla de fjuniga dot-com-konsulter som satt på spray och lappade ihop ännu en av alla dessa halvtaskiga jsp-baserade webbplatser fyllda till bredden med gif-bilder. Vad visste de om samhällsbyggnad? Var de medvetna om att de skulle påverka hur hundratusentals svenskar valde vilka de ska dela sina liv med? Hade de gjort någon samhällsanalys som resulterade i ”Sveriges invånare kommer att finna mycken glädje i att kunna välja ut en partner med ett par datorer som mellanhänder.”?

Min erfarenhet av systemutveckling säger mig att vi IT-arbetare har blivit den nya tidens samhällsbyggare, men vi vet inte och vi bryr oss inte så värst mycket om vilket samhälle vi håller på att bygga upp. Kanske ska vi heller inte ta på oss det betungade ansvaret, men det saknas övergripande visioner om hur vi vill och inte vill använda oss av ny teknik.
Många må uppskatta att träffa partners över internet och så länge det leder till kärleksfulla relationer mellan personer så är jag inte den som ska fördöma det, men jag kan inte låta bli att fundera om det inte är så att det verkliga problemet med att träffa en partner är att vi har slutat att umgås. Vill vi ändå inte hellre träffa folk i ett naturligt sammanhang där vi nyfiket kan betrakta hur den tilltänkta interagerar med andra människor och kanske låta det pirra lite i magen när vi märker att hon har lagt märke till oss, några förstulna blickar, ett nervöst ”Hej…” och den nästan rituala jakten på ett lämpligt tillfälle att närma oss henne och kanske, om vi då vågar, med bultande hjärta, be om en träff.

Som motkraft till den nya, isolerande samhällsstrukturen föreslår jag att folk som vill träffa någon ska göra just det – utan mellanhänder – börja på improvisationsteater, börja sjunga i kör, starta en bokcirkel, bjud hem folk som du inte träffar så ofta på middag! Alla älskar vi att umgås, ändå umgås vi allt för lite och allt mindre.

Glöm Wilmer-X, de hade fel. Lita till dig själv och dina mänskliga under istället.