Den levande döden

Skapad 2026-03-08 senast editerad 2026-10-26

De senaste två veckorna har jag börjat titta på SVT-dokumentärer om döden. Egentligen började mitt intresse för döden för mer än tio år sedan. Kanske blev det tydligt första gången när min mormor, som blev 103 år, dog 2015. Innan dess hade jag naturligtvis varit i kontakt med döden, inte minst genom min pappas bortgång 2012. Men i takt med att jag själv kom i allt närmare kontakt med mitt eget varsevarande har jag insett att det är viktigt att begrunda ”döden” för att förstå livet.

Detta låter kanske morbidt, men jag finner det fascinerande. Jag har den djupaste respekt för vars och ens personliga upplevelser av döden, framför allt när nära personer och familjemedlemmar försvinner ur ens liv. Jag har ingen vilja att övertyga någon om att ändra sin syn på döden eller sina upplevelser. Detta är bara mina personliga iakttagelser och reflektioner.

Den första dokumentären var 6 dagar kvar att leva, där tv-journalisten Carina Bergfeldt åker till Texas och träffar en dödsdömd fånge. Hon försöker också förstå alla sidor: förövaren, förövarens anhöriga, offren, offrens anhöriga, fängelsepersonal, stadsbor och flera personer som är involverade i själva avrättningen, vilken är planerad att ske sex dagar efter att seriens berättelse börjar.

Den andra är På tirsdag skal jeg dø och handlar om Preben, som till följd av en allvarlig arbetsplatsolycka är förlamad från halsen och nedåt. Han upplever inte längre att han har ett liv som är ett liv och vill avsluta det genom assisterat självmord på en klinik i Belgien. Serien handlar även om Prebens närmaste familj, däribland hans fru Brit och hans fosterson.

Serierna har det gemensamt att båda personerna vet – eller bedömer det som sannolikt – att de kommer att dö inom bara några dagar.

Det är uppenbart att vetskapen om att döden närmar sig gör något med människor. Jag har också sett det hos mina anhöriga.

Människor som snart ska dö tenderar att bli ärliga. Det finns inte tid för bullshit längre. Man ser det i Ramirez uppriktighet, och man ser det i Prebens och Brits oförställda och kärleksfulla relation.

Egot är satt i schackmatt och kan inte längre försöka kontrollera. (Inte för att det någonsin kan kontrollera något – det är mest en illusion att vi tror att det är vi som egon som kontrollerar något över huvud taget.) På grund av detta är Ramirez den ende som ser klart, för han befinner sig inte i en offerposition, även om hans kropp ska ”offras”. Han förstår att offrens anhöriga är obönhörligt förlamade av sorg och att det beror på hans eget agerande. Han förstår att verkligheten är som den är och att Texas kommer att ta hans liv, och det är ingenting han argumenterar emot. Det här är exakt vad Byron Katie menar med att älska livet som det är. Det är därför Ramirez är så uppenbart öppen, inte visar någon självömkan och samtidigt känner empati. Det här är svårt för egot att förstå, och det är lätt att dra slutsatsen att han på något sätt ”spelar god”. Men det tror inte jag.

Preben inser fullt ut att hans handlande i första hand är till för hans egen skull, att det är egoistiskt, vilket inte riktigt är detsamma som ”egoiskt”. Man kan debattera huruvida det är etiskt enligt någon skola att lämna anhöriga på det här sättet. Kanske ser inte Preben att det finns ett alternativ i att leva livet fullt ut i nuet. Men här finns en annan lektion: verkligheten är som den är, och det är upp till var och en att göra det som är möjligt i stunden. Tydligen var det möjligt att genomföra ett läkarassisterat självmord, för det var så verkligheten såg ut i den berättelsen. Huruvida det är etiskt eller inte är en annan historia, som verkligheten inte bryr sig om.

Projektledning – på mitt sätt

Skrivet 2026-10-26, senast uppdaterad 2026-10-26

Jag tog mitt första projektledningsuppdrag i bilindustrin 2015, lite motvilligt.

En högre chef tyckte att jag skulle passa som projektledare. Han lyfte fram min tekniska förståelse och min förmåga att kommunicera. Ändå tvekade jag. Jag tror det berodde på att jag på mitt första jobb hade sett PROJEKTLEDARE med stort mandat och lång erfarenhet. Som nybakad ingenjör tänkte jag: Tänk om jag kunde nå dit, men jag tänkte inte på att det var upp till mig att nå dit.

Mellan 2015 och 2018 ledde jag sedan tre projekt som pågick mellan sex och arton månader. Efter det blev jag linjechef men återgick till en tjänst som projektledare för hela engineeringleveransen på ett företag, och sedan var jag programchef på ett annat. Men om jag ska vara ärlig har jag inte känt mig helt bekväm i de rollerna. Länge kunde jag inte riktigt sätta fingret på varför.

Nu, genom ett välformulerat uppdrag från min kund, har jag börjat hitta ett sätt att leda som känns mer naturligt för mig.

En del av skillnaden var att projektet hade ett tydligt mål och en styrgrupp med mandat i organisationen. Men jag fick också utrymme att närma mig projektledning från grunden. Det handlade inte om att följa en färdig metod eller läsa Project Management Body of Knowledge. Jag fick i stället utforska ett ledarskap som känns autentiskt och ett arbetssätt som passar hur jag fungerar.

Under processen, som också innebar att jag behövde lära mig mycket om verksamheten och domänen, återkom jag ofta till frågan:

Hur skulle jag själv vilja bli ledd i den här situationen?

En insikt var att teamkänslan i ett projekt är minst lika viktig som i ett linjeteam. I större organisationer hade jag ofta fått personer utsedda till projektet och sedan börjat kalla till möten och organisera arbetet. Jag tänkte slarvigt att det nog bara var så man gör.

Den här gången började jag med enskilda samtal med alla i projektteamet – och gav samtalen ordentligt med tid. Jag kände inte teamet och var en konsult utifrån. Att bygga en personlig kontakt och en kollegial relation visade sig vara viktigt för att skapa ömsesidigt förtroende.

Jag slutade också med stående veckomöten där alla skulle rapportera status ”laget runt”. Jag insåg att jag själv inte tycker att det formatet fungerar särskilt bra. Jag lyssnar inte alltid aktivt när alla går ”laget runt”, och när det blir min tur är det inte självklart vad som förväntas av mig.

Vi har fortfarande ett veckomöte, men med ett tydligare syfte: att gå igenom läget, visa tidplanen och milstolparna, berätta om vad som händer i projektet, informera om förändringar i mötesstrukturen och förmedla beslut från styrgruppen. Det är främst ett tillfälle för mig att kommunicera till teamet. Om någon har frågor eller något att ta upp finns förstås utrymme för det. Och det går att hålla rätt kort; bara en halvtimme räcker.

Jag har också tagit bort separata ärende-, öppna punkter- och åtgärdslistor. Hos kunden har vi ett välfungerande ärendehanteringssystem, och det är där arbetet ska finnas. Jag vill inte skapa en parallell att-göra-lista som någon måste administrera. Med kompetenta medarbetare, tydliga milstolpar och deadlines behöver jag inte hålla ordning på var och ens arbetsuppgifter. Vi ansvarar alla själva för vår planering, på det sätt som fungerar för oss.

I stället har jag infört enskilda möten och möten i mindre grupper – ibland två eller tre personer, när flera arbetar med samma uppgift. De flesta träffar mig ungefär varannan vecka. Tillsammans blir det tre till fyra uppföljningsmöten varje vecka, ofta med ett tydligt ämne och konkreta frågor.

I övrigt försöker jag alltid vara tillgänglig för frågor, och jag försöker granska de dokument som är en del av projektets leveranser. I ett eller ett par fall har jag involverat mig i specifikt arbete när jag har egen erfarenhet av området.

Sedan har jag också tänkt igenom grundläggande saker som intressenter, riskanalys, kommunikationsplan och disseminationsplan (hur vi delar med oss av vad vi lärt oss) ordentligt. Jag måste bli bäst på kunskapen om dessa saker – vem annars än projektledaren ska kunna det? Jag tänkte också igenom en ny milstolpsplan baserad på den uppgift vi försökte lösa, en plan som är logisk – där varje milstolpe är en verklig milstolpe: ”Ah, nu har vi kommit så här långt!”

Den planen är också byggd på en del av domänkunskapen. Jag skriver inte detta för att tala om hur bra jag har varit, utan för att belysa vikten av att verkligen tänka igenom hur man själv vill ha projektet – ungefär som man hade gjort om man skulle måla om ett rum hemma även om man inte är målare: Vad går det här ut på? Vad är viktigt? Vad kan jag inte och måste lära mig? Vad måste jag ha hjälp med? Vilken input saknar jag för att komma framåt? Hur gör man det här i rätt ordning? Hur ser det ut när man har målat det sista penseldraget – är man klar då?

Det här har blivit min egen, självgrundade projektledningsmetodik. Och plötsligt har projektledning blivit roligt.

Mellan spaghetti och rymden

På senare år har jag kommit i kontakt med arkitektur. Det är märkligt att man i livet ibland snubblar över ämnen man aldrig kunnat förutse att man skulle bli fascinerad av. Då menar jag inte byggnader och stadsplanering, utan det mer abstrakta och vetenskapliga begreppet arkitektur – sådant som uppstår när man försöker bygga komplexa tekniska system, som jag vågar påstå faktiskt inte riktigt är det man först tror att det är utan att närmare studera det.

Då jag i mitt arbete jobbar med system av elektronik och mjukvara är det naturligt att man stöter på begreppet systemarkitektur. Den här texten kommer inte att handla om vare sig system – som inte heller är helt trivialt att definiera – eller att djupdyka i vad arkitektur egentligen är.

Jag vill i stället titta på en text som skrevs redan 2001 av den amerikanske mjukvaruutvecklaren Joel Spolsky, om ett begrepp han kallar för ”Architecture astronauts”, i blogginlägget Don’t Let Architecture Astronauts Scare You.

Joel har en poäng: om man drar något för långt passerar det gränsen till att det blir oanvändbart. Man kan göra samma resonemang om abstrakt konst som blir konst för sakens skull, matlagning där matlagningen i sig är viktigare än hur maten upplevs, ja egentligen vad som helst. Allt som görs går att skruva in absurdum, vilket naturligtvis inte är fel för den som vill göra det för att man roas av det. Andra får väl gilla det eller inte bry sig om det.

Joels resonemang är att vissa ”arkitekter” (jag skriver detta med citationstecken av en anledning som vi snart ska se) blir ”arkitekturastronauter” och svävar ut i rymden utan syre och skapar arkitekturer (mjukvara i detta fall) som inte blir till nytta för något. Detta är säkert sant. Jag har nog själv hamnat där i något programmeringsinitiativ där jag velat tänka igenom planen för ett hemmaprojekt ett steg för mycket.

Man gör en pluginarkitektur för… en (1) plugin. Man gör en lagerarkitektur där funktionsanropen blir en rad ner i nästa lager som blir en rad ner i nästa lager – klassisk over engineering med andra ord. Och om man är ingenjör vill man inte bara lösa problemet – man ska också faktiskt använda lösningen till något. Oftast har man dessutom ont om både tid och pengar, så over engineering är inget man vill ha.

Inom mjukvaruvärlden är arkitekturastronautens motsats kodaren som skriver utan plan och skapar något som i bästa fall går att kompilera, köra och kanske använda, men som sedan aldrig mer går att ändra eller bygga ut. Det går inte heller att felsöka och förstå – och en bug som rättas skapar tre nya oönskade beteenden eller buggar. Det brukar gå under namnet spaghettikod eller ett anti-pattern kallat ”big ball of mud”.

(Det finns ett annat roligt begrepp som är motsvarigheten till detta, fast för själva utvecklingsmetodiken: när man utan riktig plan ändrar något, kompilerar om, kör, testar igen och ser att man måste ändra igen. Och så vidare. Det kallade en av mina äldsta programmeringskompisar för norsk programmering. Ja, jag är själv halvt norrman).

Men det finns ett optimalt mellanting. Och hur når man det?

Om man nu ska vara arkitekt så arbetar man med arkitektur. Och vad är arkitektur?

Ett sätt att ta reda på det är att läsa ISO-standarderna som definierar vad det är och hur man arbetar med det. Jag tycker att ISO-standarder är rätt bra saker, då man i globala kommittéer samlas och försöker skriva ner vad man anser att saker är i någon form av konsensus. Det kanske inte är perfekt, men det finns goda chanser att de ligger nära sanningen och i alla fall representerar det bästa vi har.

Den standard som berör hur man arbetar med detta heter Software, systems and enterprise — Architecture processes (ISO/IEC/IEEE 42020:2019). Där finns processen beskriven. Jag ska inte gå igenom hela, för vi behöver inte komma så långt för att få svaret på frågan.

I korthet, och något förenklad, går den ut på följande.

  1. Ta reda på vad det är för system du vill utveckla, vad det ska göra (funktioner) och i vilken miljö det verkar.
  2. Ta reda på hur bra det ska vara på att göra dessa saker och hur bra det ska vara på andra saker, till exempel hur tungt det maximalt får vara eller hur dyrt det blir att köpa delarna till det. Detta brukar vi kalla för attribut. Andra ord är egenskaper eller kvaliteter.
  3. Skriv krav på funktionerna – funktionella krav.
  4. Skriv attributkrav på systemet. (Ibland kallas dessa också för icke-funktionella krav, men jag tycker att det låter lite negativt.)

    När man börjar tänka till kan attributkraven bli ganska många. Och man upptäcker en värre sak: alla attributkrav står i konflikt med ett eller flera andra attributkrav. Om man säger att något ska ha hög prestanda så drar det för mycket ström och batteritiden blir för kort. Om man ska göra det väldigt tillförlitligt så blir utvecklingstiden och därmed kostnaden för hög. Men alla ingenjörer gillar ju tillförlitlighet, och ja… just det – tid och pengar hade vi ju ont om.

    Så därför måste vi ta nästa steg.
  5. Balansera attributen mot varandra.

Beroende på vilket system man utvecklar ligger man olika långt ut på attributskalorna. En personbil får inte vara hur dyr som helst, för då går den inte att sälja, men man kan kompromissa lite med komponenttillförlitlighet eftersom man ju kan tillåta en viss garantikostnad under bilens 15-åriga livstid. En satellit måste däremot vara mycket tillförlitlig och hålla sina 15 år utan att repareras – för det finns inga serviceverkstäder i rymden. (Femton år råkar alltså vara en gemensam nämnare för dessa två system.)

Man måste alltså hitta ett optimum av kompromisser mellan alla attribut och sedan kravställa systemarkitekturen utifrån denna delikata balans. Notera: inte kravställa systemet, utan systemets arkitektur.

Därefter ska man, om man följer konstens alla regler, ta fram flera olika förslag på arkitekturer som uppfyller kraven – kanske mer eller mindre bra – och sedan välja den som passar de balanserade attributkraven bäst.

Detta har jag dock under min snart 30-åriga tid i kontakt med utveckling av inbyggda system aldrig sett göras i praktiken. Kanske faktiskt för att det sker väldigt snabbt – t.o.m. i huvudet. Arkitekterna vet att vissa typer av arkitekturer inte kommer att uppfylla kraven. Så kanske sker det ändå, fast lite undanskymt.

Och här närmar vi oss det viktiga.

Notera att jag inte skrev arkitekterna med citationstecken denna gång. För jag menar att de ”arkitekter” som inte har koll på attributbalanseringen inte är arkitekter, de jobbar iallafall inte helt med arkitekturmetoder. Om man börjar sväva ut i rymden så måste det vara något attribut som har hamnat ur balans mot ett annat attribut, t.ex. utbyggbarhet. Antagligen för att man inte har någon genomtänkt kravställning och definitivt inte gjort n¨ågon attributbalansering.

Poängen är alltså att Joel säkert har rätt i att det finns astronauter. Men jag tycker att de per definition (enligt ISO-standardens definition) inte håller på med arkitekturarbete.

I övrigt är jag även lite osäker på om Joel har begreppen helt rätt. Jag tycker att han i slutet av texten snarare pratar om de senaste trenderna (nåväl, bara 25 år sedan) inom produkt- och teknologiutveckling – kanske rent av om konkurrensyttringar – och inte om arkitekturer som har blivit överambitiösa.

Alan Watts

Jag har lyssnat mycket på Alan Watts sedan ett par månader tillbaka. Det började med att jag hamnade där av någon anledning på Youtube.

Jag gillade det ”han” sa och i en period med sämre sömn och där jag ibland vaknar upp mitt i natten, så var det ett sätt att centrera mig. Konstigt nog, utan att jag fattade det helt, var det mest AI-genererat innehåll jag lyssnade på, så det var ingen ”han” jag lyssnade på. Och ännu konstigare var att det funkade ändå, innehållet var stundtals briljant. Men efter ett tag blev det mekaniskt – och det var också märkligt när AI:n ibland refererade till ”endless scrolling” och andra anakronismer – även om det faktiskt innehållsmässigt var rätt.

Nu har jag hittat till autentiskt material som står under kontroll av Alan Watts Organization som drivs av Alans son Mark Watts. På Spotify finns en hel podcast med Mark som heter Alan Watts Being in the Way som i skrivande stund består av 36 avsnitt som är 45 minuter upp till lite över en timme långa. (Podcasten drivs som ett samarbete mellan Alan Watts Org och Ram Dass’ Be Here Now Network.)

Alan Watts är en märklig karaktär av det lilla jag har förstått. Han började tydligen föreläsa redan som 16-åring och i zenkretsar höjde man på ögonbrynen av hans redan då nära mästerliga insikter. Han är född i England 1915 men flyttade till USA 1938 och utbildade sig till präst inom kristendomen (men lämnade yrket) och flyttade sedermera till Kalifornien. I USA föreläste han flitigt, t.ex på universitet. Han dog 1973, bara 58 år gammal kanske till följd av hans alkoholkonsumtion. Han är otrolig att lyssna på, kunnig i filosofi, religionskunskap och vetenskap, pratar en elegant och vacker engelska med brittisk accent som ändå är effektiv och lätt att förstå. Han otroligt skarp, snabb, har självdistans och är underhållande med en humor som ofta får hela publiken (och mig) att skratta och ta sig ur någon tanke att detta är allvarligt. Och samtidigt är det hela livet.

Det slog mig i morse att Alan’s föreläsningar eller underhållning som han faktiskt själv kallar det, är så fyllda med ”sprängstoff”att det räcker att lyssna 10 minuter åt gången för de triggar insikter som behöver få sjunka in. Och eftersom jag på senare tid har längat efter att få skriva igen, så vi gör ett försök här. Jag vill skriva för att reflektera, för att bara få skriva och för att dela med mig om någon vill läsa det. Att skriva publikt gör att jag måste tänka mer på vad och hur jag skriver saker och det hjälper mig att processa innehållet i det som kom upp när jag lyssnade.

Jag märker att jag inte gillar ordet blogg – det verkar komma med en inre bild som har med att vilja synas och det är inte det jag är ute efter.

Så jag skriver.