När få förstår det nya tas märkliga beslut

Inom IT-branschen har det vid många tillfällen funnits saker som av någon anledning blivit hajpade. Det har ofta handlat om ny teknik eller nya sätt att använda teknik men ibland om hård- eller mjukvara, SaaS-produkter, tjänster, organisationsmodeller, processer eller metoder.

När jag skriver att något blir hajpat så menar jag att en eller flera av de här sakerna händer:

• Det blir väldigt omskrivet; många böcker eller artiklar i ämnet dyker upp.
• Många vill arbeta med det eller säger sig ha kunskap om det.
• Löner inom området stiger fort.
• Roller, titlar och ansvar inom området förändras fort och förvirring uppstår.
• Det drar till sig mycket investeringar och driver också mycket kostnader.
• Det ges mycket utrymme på konferenser.
• Det dyker upp i alla möjliga diskussioner.
• Det framställs i okritisk dager eller på ett alltför förenklat sätt.
• Det presenteras som viktigt eller till och med avgörande att införa/köpa/påbörja/bedriva utan bra diskussion, tydliga mål eller empiriska bevis.
• Det presenteras som lösningen på märkligt många problem.
• Det diskuteras eller används utan att risker, baksidor eller kostnader tas upp i tillräcklig grad.
• Det skapas separata arbetsgrupper eller team som ska arbeta med det.

Ett par år senare brukar saker lugna ner sig. Det som tidigare hanterades okritiskt och drev stora kostnader utan att nödvändigtvis ge de utlovade fördelarna hanteras istället som en del av vardagen eftersom fler är insatta och har byggt empirisk erfarenhet. Antagligen har något nytt seglat upp och tar mer utrymme i diskussionen också.

Ofta har saker som hajpats under en tidig fas sedan gått till att bli framgångsrikt, självklart eller uppskattat. Det jag vill ta upp här är därför inte att det skulle vara fel på det som hajpas, utan om hur vi hanterar det hajpade när det är en nyhet eller befinner sig i en tidig och kanske omogen fas.

Några exempel

Utan att göra några jämförelser i övrigt eller påstå att någon gjort fel så tänkte jag ta upp några ganska tydliga exempel. Jag har själv varit involverad i flera av de saker jag tar upp. Listan kan göras mycket lång och den är långt ifrån komplett. Den börjar inte från början och saker står inte i någon särskild ordning.

Databaser

Alla ’behövde’ en. ”Tänk vad bra om vi har all information på ett ställe så att vi lättare kan hitta saker.”
Stora pengar satsades och nyttan dröjde ibland lite väl länge, men oj vad fantastiskt det verkade.
Sedan var det så svårt att hantera dem att särskilda experter och särskilda verktyg behövdes.
Experterna tjänade massor med pengar och få förstod vad de giorde.
Få kunde något om det. De som kunde något sattes ofta i egna arbetsgrupper och hade höga löner.
Ett särskilt programmeringsspråk skapades för att många ville kunna dra nytta av databaserna utan att behöva vara experter. Vem som helst skulle relativt enkelt kunna få ut information. Det gick inte särskilt bra, det blev bara ännu ett område där det behövdes experter. Många stora organisationer lider idag fortfarande av att de gjorde sig beroende av det programmeringsspråket.
Vissa produkter som ingen minns idag var helt dominerande och kostade fantasisummor och vissa skapare av sådana produkter blev väldigt rika.

Idag är databaser sedan länge en självklarhet som många kan en del om. Specialister finns fortfarande, men krav på sådana kunskaper ingår i många andra roller utan att det pratas så mycket om det.

Webbsajter och webbportaler

Alla skulle ha en webbsajt, både privatpersoner och företag.
De flesta kunde ingenting alls, så de som kunde något alls kallades experter.
Privatpersoner la upp bilder på sina husdjur.
Mindre och mellanstora företag la upp en mailadress till säljaren.
Posten och Telia plöjde ner miljardbelopp i projekt som Torget och Passagen. Båda lades ner tidigt.
Den stora nyttan dröjde ett tag till.

Nu är de flesta portaler borta men resten är självklarheter.

Appar

”Vi borde nog ha en.” sa företagen.
I början las inte så mycket tankemöda på vad apparna egentligen skulle göra, så en del av dem blev bara förlängningar av företagens webbsidor.
Särskilda team skapades – om det ens gick att få tag i flera personer som kunde något om det.
Massor av appar utan vettigt syfte skapades. Det vara bara coolt att de ens fanns och gick att starta och titta på.
De som kunde något om det kunde begära höga löner.
Många av de som inte kunde något om det kan nu en hel del och teamstrukturerna har luckrats upp igen.
Idag diskuteras det inte i samma exalterade tonfall. Ofta ses det som rena självklarheter.
Kraven på nytta och funktion har höjts kraftigt.
Användarna tankas på privat information och betalar. Ibland ovetandes.
Säkerheten var länge kraftigt eftersatt. Eftersom de flesta använder många appar men vet ganska lite om det är det en självklar väg för intrång och spionage.

…men appar som idé är en självklarhet sedan länge.

Agila metoder

Massor av hajp och lika mycket skepsism.
Alla borde använda det sade vissa. Ännu fler höll inte med. Diskussionen blev ibland infekterad och bedrevs ofta utan kunskaper eller fakta.
Många skulle utbildas i det. De som utbildade kunde ofta en del om ämnet men visste lika ofta rätt lite om vad agila metoder skulle ersätta och varför.
Samtidigt dök det upp många som faktiskt inte vissste så mycket om agila mnetoder men som ändå gärna pratade om hur andra borde göra.
De verkligt erfarna eller skickliga inom det här ämnet drabbades av att många utan erfarenhet dök upp med samma titlar och mest pratade. Därför fortsatte vissa företag att säga saker som att ’ det där med agilt är mest en massa tyckande’.
I pressen fanns många historier om framgångar och överallt gavs löften om stora positiva effekter.
Mycket blev faktistkt bättre, mycket fungerade bra och många blev hjälpta. Dock inte allt eller överallt.
En orolig chef bad mig om råd efter att ha fått höra att ’bara vi inför agila metoder så behövs inget annat’.
Flera företag och individer byggde sina varumärken kring det. Ett mycket känt företag pratade mycket om vad de skulle vilja lyckas med men de flesta trodde att de redan gjort det.
Många konsultföretag som inte nödvändigtvis hade så mycket erfarenhet av systemutveckling eller metoder kring det var plötsligt experter och sålde dyra certifieringar, konsulttid och utbildningar.

Massor av saker sägs nu vara en del av ’det agila’ – såpass många att begreppet blivit urvattnat. Ordet ’agilt’ dyker upp nästan överallt. Alla säger sig arbeta agilt men hur sant det är varierar.

…men ute i teamen är agila metoder en självklarhet sedan länge, oavsett vad det anses betyda och hur väl det fungerar.

Molnet såklart

Nu är det en självklarhet i många sammanhang men för inte så länge sedan var det väldigt missförstått och vissa tyckte det var läskigt.
Beslutsfattare var oinsatta och vissa av dem skeptiska.
Lagar och regler hängde inte med och problem uppstod.
Vissa tyckte att det var lösningen på allt, men som vanligt stämde inte det.
Nu är kunskapen mer spridd och det finns gott om folk på alla kunskapsnivåer.

Nu är molnlösningar och molnbaserade SaaS-produkter sedan länge en självklarhet i både privata och professionella sammanhang .

Frontend och Design

För bara några år sedan sa vissa att det var olämpligt eller till och med omöjligt att blanda in de här kunskaperna och ansvaren i de vanliga utvecklingsteamen.
Frontendutveckling ansågs av vissa vara så annorlunda att de helst inte ville ägna tid åt det.
Design sades av vissa vara ’en helt annan sak, ju’ och sades inte alls kunna bedrivas i samma team som annan utveckling. Nu tycker många visst att det går och många har faktiskt provat olika sätt att göra det.

Det som sades vara omöjligt och olämpligt har nu många infört sedan länge och ser som självklarheter.

Så vilka lärdomar bör vi dra?

När något hajpas leder det ofta till konstiga beslut. Kostnader ökar men de utlovade intäkterna och besparingarna kan dröja. Risker analyseras inte och problem hanteras inte tillräckligt väl. Separata team skapas och mål är oklara. Dålig struktur och oklara krav skylls på att det handlar om outforskat territorium.

Det behöver inte vara så. Det behöver inte vara så svårt att åtminstone lära något av historien och undvika att göra om samma misstag.

• Sätt enkla mål och följ upp dem. Effektmål, intäktsmål, besparingsmål, leveransmål – situationen får avgöra vad som behövs.
• Utbilda och informera fler men utbilda på olika nivå. Beslutsfattare behöver inte alltid vara experter på detaljerna, men bör kunna mer än ett par hajpade koncept.
• Skyll inte dålig struktur och oklara krav på att det hajpade är så nytt.
  Att ställa krav handlar inte bara om att kräva saker av andra, utan lika mycket om att vi bör ställa krav på oss själva.
• Var mindre okritisk och kräv resultat – precis som med allting annat.
• Gör bättre riskanalyser och diskutera dem iterativt, det behöver inte vara svårt. Agera på resultaten.
• Tro inte att bra ledarskap inte behövs.

…och nu då, vad är hajpat nu?

Alla får tänka till nu. Inte kan det vara så svårt att gissa?
Mycket händer på området. Lite överallt är förväntningarna höga, separata team skapas och konstiga beslut tas.
Det är mycket spännande och lovande. Struktur och tydliga mål är det ofta lite si och så med.

…men det kommer att vara en spridd självklarhet inom en snar framtid.

Ingen behöver ha gjort fel, men om vi tar det lite lugnt, tänker till och diskuterar det lite mindre okritiskt så blir det bättre. De snabba och ibland blinda investeringarna behöver som alltid blandas upp med riskmedvetande, tydlighet, mål och krav på nytta och funktion.

Lycka till!

/Björn