Funderingar och fantasier

Inom IT-sektorn är ordet “standard” positivt laddat. Sker utvecklingen med en förutbestämd standard finns igenkännelse. Sättet som problem löses på känns igen. Underhållet av programvaran blir helt enkelt lättare. När programmeraren väl tagit sig in i standarden så går det fortare att orientera sig i andra program som följer samma standard. Jag vill dock vända på myntet. Ur min erfarenhet plockar jag fram några exempel på standardtänkets baksida.

Första exemplet är när det stora företaget köper och tar över en programvara. Här ser de ansvariga för standardiseringsarbetet sin chans. Ett stort projekt måste till. Föremålet för standardiseringen är den nyinköpta programvaran. Intresset rör varken ökad funktionalitet eller ens förbättringar av programvaran på de punkter där kodbasen är av sämre kvalitet. Istället är det namn på program, tabeller och kolumner som ska ändras enligt gängse standard. Det stora projekt kan endast förklaras genom standardiseringsivrarnas starka ställning. Beslutet när de fick loss de nödvändiga miljonbeloppen visar deras position i organisationen. Det jag vill peka på i detta fall är att det övergripande målet “lättare igenkännande” inte löstes. Underhållet låg fortfarande kvar hos de som ursprungligen utvecklat programvaran. Ändringen av namnstandarden underlättade inte underhållsarbetet utan försvårades.

Mitt andra exempel hämtar jag från det stora affärssystemet. Inför utvecklingsarbetet tas en standard fram. Redan när den lanseras visar den stora brister i sättet att strukturera programvara. Trots detta har denna standard under en lång rad av år varit helig. Programmeringsspråket utvecklas men standarden bevakas och tillåts inte utvecklas. Det har gått så lång att denna standard konverterats från ett procedurspråk till ett objektorienterat språk. Programmen har i det närmaste blivit omöjlig att underhålla. Bakom konvertering låg marknadsmässiga motiv. Först på plan med det nya objektorienterade språket. I detta fall vill jag framhålla att låsningen av standarden över tiden medfört att utvecklingen strypts. Fördelar som programmeringsspråkets utveckling eller bytet till objektorienterat språk har inte tagits tillvara.

Inom en organisation har grupper sina särintressen. I det första fallet lades åtskilliga timmar på en process som inte skapade något värde. Medan det andra fallet visar att utvecklarnas röst negligeras helt. Utveckling har förhindrats.

Enligt min mening har vi på min arbetsplats problem med organisationen av arbetet. Ett sådant symtom är sammanblandning av implementationsprojekt och utvecklingsprojekt. Eftersom det ställs helt olika kunskapsmässiga krav får det allvarliga konsekvenser. Dessutom måste kunden redan i säljfasen göras uppmärksam på skillnaden. Kundens roll i de olika projekten är helt olika.

Vid implementationsprojekt eller som jag vill kalla de push-project behövs naturligtvis applikationskunnande. Kunskap om programvaran som implementeras ska överföras till kunden. Pedagogisk kunnande är en annan viktig faktor. Applikationen ska också installeras och konfigureras. Här behövs kunskap om den tekniska miljön liksom djupare förståelse av applikationen. Kunden får sätta sig på skolbänken och ta till sig applikationen. De blir en mottagare. Det är därför jag kallar det push-project.

De faktorer säljet arbetar med är tydliga. Fast funktionalitet säljs till fast pris. Då implementationer gjorts förut kan leveranstider spikas på ett tidigt stadium. Planering av implementationen kan ske då alla faktorer är kända.

Utvecklingsprojekt vill jag kalla pull-project. Här är förhållande helt annorlunda. Kunden har här en helt annan roll. I denna typ av projekt är det kunden som styr i form av vad som ska göras och bestämma ordningsföljden. De tar fram “use-case” och placerar dessa i prioritetsordning. Vår roll blir att med hjälp av utvecklingskunnande och i dialog med kunden ta fram en fungerande programvara till ett bra pris prestanda förhållande.

Här ställs säljet inför helt andra krav. Här kan priset och/eller leveranstid hållas fast medan funktionalitet är en variabel. Det är ju prioritetslistan som växer fram och förändras under arbetes gång.

På min arbetsplats har det skett en sammanblandningen av dessa projekttyperna. Då de ställer olika kunskapskrav hamnar arbetsuppgifterna på fel bord. Symptom på detta är att applikationskunniga hamnar i utvecklingsprojekt och utvecklare ska certifieras på programvara. Frågan jag ställer mig är hur detta har varit möjligt? Är det dags för en genomgång av vilka processer som finns i vårt företag?

I det företag där jag jobbar har många hört historien när några punkter skrivs ner på en servett och överlämnas till en nyanställd med kommentaren “Åk upp till vår kund och fixa detta”. Det kan berättas ur perspektivet som påvisar brister i introduktionen av nyanställda. Men det kan också ses utifrån tron på den nyanställdes förmåga. Till historien hör naturligtvis att problemet blev löst till kundens belåtenhet och att de har varit oss trogna i många år.

Detta ska kontrasteras mot det som på senare tid börjat bli allt vanligare. När vi ställs inför nya uppgifter blir kommentarerna “Orkar vi verkligen med det” “Ska vi hålla på med det här” “Ska vi inte låta någon annan ta hand om detta” och “Vi kan ta in underkonsulter som sköter detta.”

Två inställningar från samma företag. Låt vara med ett antal år emellan men det visar på en viktig förändring. Vad har det blivit av tron på vår egen förmåga? Förr backade vi inte för nya uppgifter. Saknades kunskapen sågs det som en utmaning! Vi var ett företag där lärande var en möjlighet. Nu håller denna tro på att vittra sönder. Var har den tagit vägen?

I jakten på förståelse har jag stött på rubriker som “det lärande företaget”. Många länkar leder till Peter Senge och hans bok “Den femte disciplinen”. Den fångande mitt intresse och finns på mitt läsebord. I boken samlar han sina tankegångar under följande fem begrepp.

Systemtänkande
Personligt mästerskap
Tankemodeller
Gemensamma visioner
Teamlärande

Systemtänkande är den övergripande disciplinen. För att förstå problematik måste man utgå från helheten. Istället för orsak verkan vill Senge peka på sambanden med förstärkande/motverkande eller balanserande krafter. Översätter jag detta till mina vardagsförhållanden så skulle den kunna tolkas på följande sätt. I vårt företag finns fortfarande initiativ för att kunna kalla sig ett lärande företag. Men i många fall tas inte initiativen tillvara genom att understödja och komplettera dessa utan istället framträder motverkande krafter som försöker ta död på dessa initiativ. Vilka tankemodeller ligger bakom detta? Är det positionstänkande? Initiativen kommer helt enkelt från fel håll utifrån den hierarkiska strukturen som utvecklats. Här ger boken ingen vägledning.

Senge berör visioner. Om visioner ska kunna anammas av alla så kan inte visionerna eller om man så vill färdriktningen av företaget tas fram i slutna ledninggruppsrum och delges på informationsmöten. Ska visionerna bli en verklig kraft i företaget så måste de växa fram i en gemensam dialog. Visst kan visionerna tryckas neråt i företagets struktur men då blir det enligt Senge något som han kallar samtycke men inget äkta engagemang för visionerna. Vilket är en viktig faktor i det lärande företaget.

I databranschen som är en bransch som förändrats och förändras snabbt måste företagen kunna ta till sig ny kunskap. Jag avslutar med ett påstående. Företagen på denna marknad måste tillhöra gruppen “Lärande företag” för att hålla sig konkurrensmässiga.