Företagskulturers makt : överbrygga språkliga klyftor

Dialoger

Företagskulturers makt

© Gunnar Berg 2008

trita-ieo-r 2008: 07 issn 1100-7982

isrn/kth/ieo/r - 08/05-se isbn 978-91-7178-966-2

Licentiatuppsats: Gunnar Berg Handledare: Bo Göranzon

Biträdande handledare: Lars Mouwitz Kungliga Tekniska Högskolan Yrkeskunnande och Teknologi

Institutionen för Industriell ekonomi och organisation 100 44 Stockholm

Omslagsillustration: Nils Kölare, Blue square in front of yellow cross Omslag och inlaga: Santérus Förlag

7

Förord 11

Inledning 13

Dialogseminariet, Dialogseminariemetoden och tidskriften 15

Dilemma 17

Uppdraget 18

Entusiasm och insikt 18

Uppbyggnad och kulturer 22

Internt förtroende 26

Stormöten med avrapportering 26

Fokuseringskris 27

Slutet 28

Efterkommentar 29

Konsten som kunskapskälla 31

Oscar Wilde 31

Joseph Conrad 33

Ludwik Fleck 35

Tradering och inre bild 38

Artefakten Kravspecifi kation 40

Kravspecifi kationen som kalkyl 40

Logisk positivism 41

Krav 42

Det matematiska kulturarvet 49

Att förstå 50

Att förstå – inom undervisning 54

Att förstå – att företräda 54

Initieringsrit 55

Apropå Språk 57

Mästaren och lärlingen 59

Bildning 60

Dialogseminarium 62

Om att framföda ett Dialogseminarium Eller

En övning i dialogisk utveckling 63

Kommentar till »Om att framföda ett Dialogseminarium Eller

En övning i dialogisk utveckling« 65

Vad har formen för betydelse för förståelsen? 67

Platt fall 68

Gombrowicz makt 69

Formens makt 69

Gestaltning – refl ektion 71

Erfarenhet – refl ektion 71

Dialogseminariet kontra Dialogseminariemetoden 74

Dialogseminariet 74

Dialogseminariemetoden 83

Dialog för förståelse – Galilei 87

Om Galileis dialog 87

En dialog med Galilei 90

Inledning 91

Fragment I – Om Auktoritetstro 92

Fragment II – Om formen 93

Fragment III – Om metoden 94

Fragment IV – Om Kunskapen 96

Om lyssnandets roll 97

Kommentarer, tillägg 99

Fragment II, Om att gå vilse 99

Reflektion 103

Fått erfarenhet 103

Konsten 104

Fått upp ögonen 104

Verktygen 105

Vad kunde vi gjort istället? 106

Bilaga 1: Utdrag ur

Dialog om de två världssystemen, Galileo Galilei 109

Om metod 109

Om yrkeskunnande 110

Om mänskliga upptäckter 111

Om auktoritetstro 111

Bilaga2: Direktiv till regeringens

matematikdelegation dir. 2003:8 113

Bilaga 3: Program för

det matematiska kulturarvet 21 mars 2007 119

Bilaga 4: Program för arbetsmötesdagen 22 mars 2004 123

Referenser 125

11

Denna studie är något som växt fram under ett antal år. Jag blev medveten om forskningsområdet då jag började arbeta på Combitech Systems år 2000. Combitech hade då arbetat tillsammans med Yrkeskunnande och Teknologi och Bo Göranzon på KTH om att få fram en metod (metoder) för att ha något för dem som passerat stadiet att »gå på kurs«. Jag arbetade då hos Bo Hagerf på Stockholmskontoret av Combitech Systems och han ansåg att jag hade rätt inställning och intresse för denna typ av forskning. Så han såg till att jag kom iväg på utbildningen med namnet Steg 2. Denna utbildning var en utbildning i kunskapsteori och dialogseminariemetoden. Efter denna utbildning insåg jag att det i kontakten med Bo Göranzon och Maria Hammarén fanns mer att hämta och jag blev knuten till Forskarsko-lan på Yrkeskunnande och Teknologi.

Genom samarbetet med Bo Göranzon och Maria Hammarén , och senare också med Lars Mouwitz , som jag kom i kontakt med under arbetet med Det matematiska kulturarvet, har det arbete som här presenteras vuxit fram. Det har inte varit en resa som gått spikrakt fram. Jag började inte med forskningsfrågan för att sedan söka svaren och skriva ned resultaten. Det har snarare varit en resa i utforskande av olika infallsvinklar och sökande bland olika förhållningssätt.

Erfarenhetsexemplet, som jag själv varit med om, var för mig så starkt att det först nu, i samband med att jag formulerade det för denna uppsats, varit tillgängligt för mig. Jag har alltså inte kunnat ta tag i det tidigare. Men med hjälp av de metoder och verktyg som nu fi nns på min repertoar genom arbetet med uppsatsen har jag kunnat ta mig an denna erfarenhet. Och förmodligen är den rumsliga tiden inte obetydlig när man kan ta tag i starka händelser.

Mitt första tack går till Bo Göranzon , min handledare, som jag uppfattar har förstått mina intentioner, då andra kanske tyckt att jag varit ute och cyklat. Tack för inspirationen Bo! Vidare Maria Hammarén som genom sitt stora språkliga kunnande och långa erfarenhet av tekniska texter samt genom sin blotta närvaro har varit till stor hjälp. Tack Maria för många intressanta och spännande samtalsutfl ykter. Lars Mouwitz – du har på ett lugnt och metodiskt sätt fått mig att se samband som jag tidigare inte såg. Ett tack måste riktas till Bo Hagerf som fi ck in mig på spåret. Vi arbetade tillsammans även innan jag kom till Combitech Systems och på något sätt tänker vi lika.

Fler som ska tackas för stöd är givetvis min familj, Eva och Sofi a som stått ut med arbetet. Supportrar har också varit min mor och far, Ulla och Sievert.

Eftersom arbetsmarknaden varit lite turbulent under den period då uppsatsen arbetats fram, vill jag rikta uppmärksamheten mot fyra företag och organisationer som ställt upp och hjälpt mig: Combitech Systems, Jay-bis, Scania och Regeringens matematikdelegation. Utan dessa fyra skulle detta arbete inte ha kunnat genomföras.

Arbetet har genomförts på KTH, Yrkeskunnande och teknologi i Fors-karskolan, vilket har varit en fantastiskt inspirerande och utbildande miljö och alla deltagarna där förtjänar också ett stort tack för stöd med ifråga-sättande och konstruktiv kritik. Adrian, Lotta, Peter, Johan, Niklas, Mats, Dan, Göran, Jan, Elisabeth, Kristina, Lotta, Clas, Anders, Karin, Roland, Sven. Har jag glömt någon så tack ändå, det är inte medvetet.

Detta har varit en mycket spännande och lärorik resa och jag hoppas att denna uppsats kan hjälpa några på traven att få upp ögonen för ämnet.

Huddinge 21 februari 2008 Gunnar Berg

13

I denna uppsats arbetas med en triplett1_{, nämligen förståelse – tolkning –} bildning. Eller egentligen är det nog en beskrivning av att lära sig ta tag i ett egenupplevt »misslyckande«. Vad kan jag lära av det och vad kan jag förmedla så att andra kan lära sig av min upplevelse och att lära av sina egna upplevelser – erfarenheter. Upplevelser blir inte erfarenheter med automatik, de måste bearbetas. Och erfarenheter blir inte med automatik kunskap, de måste refl ekteras över.

Kravställning är ett spännande område, jag använder mig av detta som exempel i hela uppsatsen, då detta var vad mitt »misslyckande« handlade om, men det ska endast ses som ett exempel. Vid första anblicken kan det te sig väldigt enkelt att tala om krav, tala om för någon vad du vill ha gjort. Vari ligger svårigheten? Kanske kommer man på att jag nog inte har talat om allt som jag vill ha gjort men det är bara att komplettera med det som saknas, jag vet vad jag vill ha gjort. Men kan jag förmedla det? Vårt verbala språk öppnar för tolkningar och att verbalspråkligt beskriva krav är mycket vanligt. Detta medför att det jag tycker är en entydig kravspecifi kation inte alls behöver vara entydig för någon annan, eller kanske ännu värre: den är entydig för någon annan men denna person har inte gjort samma tolkning som jag. Alltså har vi ett problem. Ingen har gjort fel – båda har gjort rätt, de har till och med (kanske) pratat ihop sig, men resultatet stämmer ändå inte med det förväntade.

1 Ordet triplett använder jag som en utökning av ordet dubblett till tre enheter. Om man slår upp ordet dubblett får man: »dubblett dubbletten dubbletter subst. dubbelexemplar; lägen-het med två (sammanhängande) rum«. När jag läste i Uppsala kallades en lägenlägen-het med tre studentrum och gemensamt kök för triplett, därav min lite mer generella användning.

Detta är inte en helt ovanlig situation i systemutveckling, det är till och med så att detta är mer regel än undantag. Vad detta beror på kan det fi nnas många tankar om, men en måste vara att tron på specifi katio-ner är oerhört stor inom utvecklingsorganisatiokatio-ner. I och för sig fi nns det metoder, och som exempel kan nämnas så kallade lättrörliga, som fokuserar mycket på att kunden – kravägaren – ska fi nnas med hela tiden och prioritera och specifi cera under hela projektets löptid. Detta är bland annat ett försök till att angripa problemet. Ändå tror jag att det fortfarande (kan) blir problem i tolkningen. Men problemen kanske kan bli mindre. Faktorer som påverkar är ofta av andra karaktärer, det kan vara kulturella skillnader, språkliga barriärer, traditioner, djupt rotade företagskulturer, förväntningar och andra typer av mjuka värden.

Vad jag i detta arbete försöker framhålla är att dels väcka insikten om att dessa problem existerar, dels presentera lite om varför de existerar, samt ge några ingångar för att angripa problemen. Detta leder inte till att det i slutet fi nns ett kapitel som heter – Så här skriver du en exakt kravspecifi -kation som alla förstår – det går nämligen inte. Men om det nu hade gått att skriva en sådan specifi kation så hade i alla fall inte slutkapitlet hetat så, för detta arbete handlar inte om krav i den meningen utan om något allmängiltigare, som vi här kan kalla för mänsklig kommunikation.

De texter och material jag jobbar med är spridda över vida områden i både tid, rum och ämne. Det vill säga jag plockar fram hela bokhyllan och öppnar upp den på mitt arbetsbord och väljer där helt fritt ur det som jag tycker mig behöva. Det låter kanske lite ambitiöst eller rent av felaktigt att använda texterna fritt ur sin kontext och sammansmälta dem till något nytt.

För mig är denna metod, att välja fritt ur det jag ser mig behöva, kraft-full och framgångsrik och för att peka ut att jag inte är ensam om denna metod kommer här ett citat ifrån Paul Ricœur . Han skriver i förordet till sin bok Minne, historia, glömska:

»Ännu en anmärkning: jag åberopar och citerar ofta författare som till-hör olika epoker, men jag ger ingen historisk redovisning av problemet. Jag åberopar den ene eller den andre författaren alltefter argumentatio-nens krav, utan kronologisk hänsyn. Denna rätt förefaller mig vara en rätt som tillkommer varje läsare inför vilken alla böcker samtidigt ligger uppslagna.«2

I referenslistan i slutet har jag, givetvis, tagit upp de verk som refereras 2 Ricœur , s. 35

men jag har också tagit med en del verk som inte fi nns direkt refererade i texten. Detta för att i många av dessa icke direkt refererade verk fi nns många indirekta infl uenser. Till exempel något jag har läst, påverkats av, men ändå inte citerat ur eller som satt direkta spår i texten, utan som mera har gett allmänt underlag till texten och förståelsen.

En metod som jag också använder är att jag citerar friskt, och ibland långt. De långa citaten tycker jag verkligen tillför något. Författare och konstnärer som har formulerat något kan oftast inte bara kortas ned till en mening och ge den infl uens jag eftersträvar. Många av de konstnärliga texterna lever i ett i texten inbyggt paradigm, som är svårfångat. Inte hel-ler är det görligt och ger rätt effekt att skriva om en välformuhel-lerad text till en kort sammanfattning.

Skriva av, citera, läsa långsamt är viktigt för den som vill skaffa sig material till ett analogiskt tänkande. Karl Kraus kvalifi cerar läsandet som kreativ akt genom att lyfta fram vikten av att hitta de träffande citaten. Detta går på tvären mot alla rekommendationer i konsten att lära sig skriva, där citerandet ofta är en dödssynd. Kraus igen: – Citatet en kraft: inte att bevara, utan att rena, lösgöra från sitt sammanhang, bryta ned; den enda kraft som ännu ger hopp om att något ska överleva denna epok – därför att det har brutits ut ur den.3

!

Dialogseminariet, Dialogseminariemetoden och tidskriften

kultur-arvet arbeta på mina upplevelser, »misslyckandet« som beskrivs i första kapitlet och koppla ihop det mot tripletten förståelse – tolkning – bild-ning. Det är dock inte bara materialet från Det matematiska kulturarvet jag låter arbeta på mina upplevelser utan det är alla material jag anför: Gali-leo Galilei , Gombrowicz för att nämna några. Texterna som jag använder från Det matematiska kulturarvet, fi nns samlade i ett nummer av tidskriften

Dialoger.4 _{Jag låter dem arbeta mot min upplevelse och även utöka med} exempel och kopplingar kring tripletten förståelse – tolkning – bildning.

Vissa delar kommer att röra sig kring utbildning – tradering av förstå-3 Jämför Göranzon 2001, s. 148, jämför även med Göranzon 2001. s. 169

är form vid gestaltning och utförande? Hur påverkar formen dialogsemi-nariet och dialogseminariemetoden? Detta görs bland annat via Gombro-wicz .

Ett gestaltande tar sig också upp till ett kapitel i denna uppsats, näm-ligen en konstruerad dialog ur Dialog om de två världssystemen av Galileo Galilei . Denna dialog är konstruerad precis som en dialog som framfördes på Dramaten i Det matematiska kulturarvet. (Dialogen som framfördes på Dramaten fi nns med som bilaga då den inte tidigare fi nns publicerad.) Att gestalta, att ge form, kan ses som en del av den metod jag använder, och förordar, för bearbetning. Annars skulle jag vilja beskriva min metod som Galileis metod, skriv om ett tema men tillåt utvikningar och låt dessa ta ut svängarna friskt.

Så långt inledningen. Nu till det verkliga materialet, och som Wittgen-stein säger: »Vad också läsaren kan, överlåt åt läsaren«.5

17

Dilemma

var jag en trasig teve skulle jag säkert orsaka fl er störningar i ert liv1

(Einar Màr Gu∂mundsson)

Apollo 8 startade 21/12 1968 och landade 27/12 1968.

Den julen, 1968, satt jag som klistrad vid TV:n vid alla nyhetssänd-ningar. Då var det fortfarande svart-vit TV. Det som var så spännande var att man för första gången skulle runda månen med en bemannad raket, Apollo 8. Jag kommer speciellt ihåg julafton. Vi var hemma hos några av mina kusiner i Årsta. Till och med under julmiddagen var det självklart att man skulle gå för att titta på hur det gick med rymdfärden. Det var något väldigt stort och spännande när man var 8 år gammal. Upplevelsen har nog alltid funnits kvar hos mig. Rymden är spännande och lockande.

Ytterligare en stark upplevelse var när månlandaren senare skulle starta från månen, hem till jorden, vid den första månlandningen (Apollo 11, 20/7 1969). Astronauterna hade placerat en kamera på månen som fi lmade starten. Det som bland annat höjde spänningen var klockan som räknade ner till 00:00 inför starten. Men när klockan sedan visade 00:00 hände inget. Man höll 1 Gu∂mundsson , s. 7

andan. Sju sekunder senare startade farkosten. Det vi trodde var ett fel var bara den fördröjning som sker genom att det tar sju sekunder för signalen att nå jorden. Så bilden vi såg var sju sekunder gammal. Rymden är spän-nande och lockande.

Uppdraget

Jag lockades över till konsultbolaget Combitech Systems genom löftet att jag skulle få ett konsultuppdrag på Rymdbolaget (SSC – Swedish Space Corporation) som mjukvaruarkitekt2 _{för en ny månsond,}3 _{som skulle} utvecklas i Sverige.

En månsond skulle alltså utvecklas i Sverige, och jag skulle få vara med. Denna sonds primära uppgift var att prova en typ av motor, en jon-motor. En jonmotor är, förenklat, en motor som kan gå länge på en liten mängd bränsle, men som också ger väldigt liten dragkraft, så det tar väl-digt lång tid att åka dit man ska. Dock kan man färdas välväl-digt långt.

Uppdragsgivare för detta projekt var ESA (Europeiska rymdstyrelsen – European Space Agency). ESA hade beställt utvecklingen av sonden från SSC som i sin tur kontrakterat mig via Combitech Systems som mjuk-varuarkitekt för projektet.

Entusiasm och insikt

Jag skulle alltså gå in som mjukvaruarkitekt för detta utmanande utveck-lingsprojekt och SSC hade redan en projektledare för mjukvaruutveck-lingen på plats. Han hade under något års tid arbetat med att förstå och ta fram kravbilden och brutit ned detta till en kravspecifi kation. Kravspecifi -kationen omfattade inte enbart mjukvaran för sonden utan hela projektet. Hårdvara, solpaneler, kommunikation, … med mera med mera. Mjukva-ran var endast ett kapitel. Detta kapitel skulle vara färdigt och nedbrutet när jag skulle komma in och börja arbeta. Combitech Systems och jag gick alltså in i projektet med uppfattningen att vårt uppdrag var att imple-mentera det som stod i kravspecifi kationen. Givetvis insåg vi (jag) att det skulle behövas kommunikation och förtydliganden och troligen utbyte av 2 Jag kommer genomgående att använda ordet mjukvara för programvara, orden är synonyma, men jag har valt mjukvara. Detta är alltså de program som exekverar (kör) i en dator. Med mjukvaruarkitektur menar jag en struktur för att bygga mjukvara. Detta för att underlätta för programmerarna och även för till exempel framtida underhåll.

3 En rymdsond är en rymdfarkost som skickas iväg till en planet eller måne. En månsond är alltså en rymdfarkost som skickas iväg till vår måne. Detta till skillnad från en satellit som kretsar kring en planet, vanligen jorden.

vissa krav, men på det stora hela skulle kravbilden vara klar.

Det skulle bara vara en formell punkt kvar – jag och mjukvaruprojekt-ledaren skulle åka ned till ESA och stämma av några punkter i den lägsta nivån på kravnedbrytningen. Jag (och bakom mig Combitech Systems) antog alltså att det SSC sa om kravspecifi kationen var korrekt, den var till 98 procent färdig. (Vad 98 procent betyder kan man undra över, men i detta fall betyder det att kravspecifi kationen var färdig så långt att det defi nitivt gick att börja arbeta efter den – annars är detta mått inte så lätt att defi niera och mäta.) Detta var alldeles i början av mitt uppdrag.

Att Combitech Systems engagerades för detta uppdrag var bland annat för att vi skulle hjälpa till att ta in nya utvecklingsmetoder och verktyg till SSC. Alltså inte för att vi hade speciell domänkunskap för utveckling inom rymdindustrin med alla de kunskaper det innebär. Här kan också nämnas att domänkunskap inte behöver vara entydig i vilken domän som åsyftas, de domäner vi hade kunskap om, och som vi fi ck utvecklingsuppdraget på var inbyggda realtidssystem och modern utveckling. Detta med olika domänkunskaper för tankarna till att det förmodligen fi nns ett antal olika praktiker inom mjukvaruutveckling och dessa är inte på något sätt utbyt-bara. Mjukvaruutvecklare använder samma typ av verktyg för att göra helt olika tillämpningar, men för det behöver inte den som använder verktygen förstå och kunna göra bra insatser inom olika praktiker. Både en kock och en snickare använder kniv men de kan inte byta arbetsuppgifter med varan-dra. Detsamma gäller för mjukvaruutvecklare inom olika praktiker, de kan inte byta arbetsuppgifter bara för de behärskar samma verktyg. Detta är ett försummat problem och insikten hade säkert varit till hjälp för oss när vi bemannade projektet.

Det var alltså ett uttalat krav från SSC, att vi, Combitech, skulle använda till exempel objektorientering, UML4_{, ObjectTime – ett design- och} kodgenere-rande verktyg, operativsystem och iterativ utveckling. (Se förklaringsruta 1).

Detta kan låta som självklara val idag, men då var det nytt – i alla fall för rymdindustrin. Att köra med ett operativsystem i botten låter till exempel inte så kontroversiellt. Tidigare projekt hade utvecklats enligt en väldigt strikt vattenfallsmodell (PSS-05). (Se förklaringsruta 2).

Och kodningen av mjukvaran, hade till stor del hittills bestått i att handkoda i assembler.5

4 UML: Unifi ed Modeling Language. Ett grafi skt språk för att beskriva hur ett (data) system ska byggas.

5 Assembler är den lägsta hanterbara nivån av programmering. Man programmerar direkt med instruktioner som datorn kan exekvera. Detta i motsats till då man skriver i högnivåspråk som är lättare att förstå och beskriva funktioner i. Högnivåspråk kan vara C, C++, Java, till exempel.

Combitech hade inte kunskap om PSS-05, med ett undantag – vi hade en person som tidigare hade arbetat på SAAB Space och kunde ge oss ett visst stöd, men han var inte del av vårt utvecklingsteam i Stockholm. Vi, jag och Combitech Systems, skulle nu alltså genomföra detta projekt med hjälp av de senaste utvecklingsmodellerna, verktygen och metoderna. Projektet skulle genomföras med objektorienterad utveckling, iterativ utveckling och så vidare. Detta stämde inte ihop med traditionen med vattenfalls-modellen och assemblerkodningen.

Mjukvaruprojektledaren och jag åkte till ESA i Holland för att träffa vår motpart, uppdragsgivare – kravställarna. Då skulle vi fastställa kravspecifi -kationen och hur kraven var nedbrutna, det vill säga »bara« ordna till de sista detaljerna – som vi trodde.

De förberedelser som ESA gjort inför mötet var att ett antal av deras experter hade granskat de olika delarna av de nedbrutna kraven, som de fått sig tillsända på förhand. Med kraven menas här endast den del som avsåg mjukvaran och då även undantaget den del som skulle hantera navi-geringen av månsonden. Navigeringsmjukvaran innehåller bland annat navigeringsalgoritmer och deras implementation. Denna mjukvara togs fram av ett team som är experter på rymdnavigering hos SSC.

Vi hade avsatt två dagar till detta besök hos ESA – gott om tid trodde Krav

Design

Implementation Verifiering Underhåll

Iteration 1 Iteration 2 Iteration 3

iterationer, för att få fram helheten. Varje iteration ska producera något användbart och genom att man hela tiden passerar alla faser i utvecklingen kan man lättare styra så att man hamnar mer rätt vid målet.

Se schematisk bild nedan.

vi. Det visade sig dock att de frågor och protokoll som skrivits om vår kravspecifi kation av ESA: s experter var minst lika omfattande som hela vår kravspecifi kation. Alltså skulle vi ha kunnat sitta där och diskutera och resonera i många dagar om kravspecifi kationen och den nedbrytning av kraven som vi redovisade i kravspecifi kationen.

Hur skulle då denna granskning och genomgång av kravspecifi katio-nen gå till? Genomgången av kravspecifi katiokatio-nen skulle gå till enligt föl-jande. ESA: s sammanhållande, mjukvaruprojektledaren och jag, kallade in experterna som granskat de olika delarna, en efter en för att de skulle ge sina synpunkter och vi skulle fastslå vad som skulle justeras eller om det var bra som det var. Men detta blev efter en stund helt ohållbart. Det tog för mycket tid och det var för stora skillnader mellan vad vi presente-rade som våra krav och vad man hade förväntat sig. Det blev diskussion och resonemang om i stort sett varje krav. Antal krav på lägsta nivån var omkring 1000.

En annan del av detta möte bestod i att SSC: s expert på

rymdnavige-Krav

Design

Implementation

Verifiering

Underhåll vara helt färdig innan nästa fas kan eller får påbörjas. Till exempel ska

kravspecifikationerna vara färdiga och godkända innan systemkonstruktionen får påbörjas. Systemkonstruktionsfasen ska sedan vara färdig innan testfasen påbörjas och så vidare. Detta är mycket förenklat.

Se även nedanstående illustration.

Framåtskridande går alltså från överst till vänster ner till nederst till höger, som ett ”vattenfall”.

ring kom till Holland och hade med sin del av kravspecifi kationen. Jag och mjukvaruprojektledaren, satt med under denna genomgång och hörde hur vår, SSC: s, expert och deras, ESA: s, expert på ett smidigt och effektivt sätt gick igenom den delen av kravspecifi kationen. De talade på något sätt med varandra och använde samma språk. Det var en viktig skillnad mot när vi talade med våra motparter. Vi och dem pratade förbi varandra och talade olika språk (tolkningsmässigt). Det var den känslan som infann sig.

Redan i detta tidiga skede av projektet kunde noteras att det fanns missuppfattningar inbyggda i kommunikationen. På mötena fanns en, på något sätt, inbyggd icke-förståelse mellan deltagarna, kanske en vi-och-dem-relation, men troligare är att värderingarna gick isär och tolkningarna skiljde sig mellan parterna.

Resultatet av mötena, för vår del, blev att vi fi ck åka hem och fortsätta arbeta med nedbrytningen av kraven och framtagandet av vår kravspecifi -kation. Detta för att tillfredsställa uppdragsgivarna och få starttillstånd för att börja designa mjukvaran, allt enligt vattenfallsmodellen.

Översättningen mellan ESA: s modell för utveckling och den modell SSC och Combitech ville använda att utveckla med, var inte gjord eller fastställd. Tillbaka till ruta ett, samt en försening redan i starten, och designers var redan på väg in.

Uppbyggnad och kulturer

Någon tid efter besöket hos ESA i Holland kom nästa besked, projektle-daren för mjukvara lämnade in sin avskedsansökan. Då blev jag tillfrågad om jag ville axla den rollen och ta över mjukvaruprojektet. Jag tackade ja. Ett av de dilemman som då uppstod var att projektledaren, som slutade, hade hela kravspecifi kationen i huvudet och kunde läsa vad som stod där, det var han som skrivit den under något års tid. Vi kunde självklart läsa vad som stod i texten – den verkliga utmaningen var att verkligen läsa vad som stod i texten. Combitechs projektteam kom ännu längre bort från uppdragsgivarens språk.

Att ta över en text är inte så enkelt som att man får texten som den är skriven, av den som behärskar texten. Den verkliga utmaningen ligger i att ta över den, i många fall, dolda undertexten. Detta är inte en enkel uppgift. Om man är medveten om detta, kan det fi nnas sätt att angripa tolkningsdilemmat. Är man som i det beskrivna fallet naiv nog att tro att det som fi nns nedskrivet tolkas på samma sätt av alla parter, inbjuder detta till, att som i vårt fall, förstärka icke-förståelsen mellan parterna. För att det ska vara möjligt att ta över en text, på det enkla sättet att texten verkligen innehåller all information, så skulle »drömmen om det exakta

språket« vara en förutsättning. (Se förklaringsruta 3). Alla tolkar en text exakt lika. Nu är detta inte en idé som är genomförbar och därför så är det en reell utmaning att ta över en text. Det här är en av de centrala och viktiga insikterna i denna studie.

En annan faktor var att i stort sett hela ESA: s projektorganisation var ita-lienare, och jag var inte förberedd på hur de arbetar i en situation som den som uppkom. Jag var nog väldigt oförberedd och svensk i mitt angrepps-sätt. Jag förstod inte, eller insåg inte att det fanns en kulturell skillnad

som skulle komma att påverka arbetsklimatet på många sätt. Klyftan (eller sprickan) mellan kulturerna var mycket större än jag förstod. Det fanns en svensk i ESA: s organisation och när han gick in och var med på möten gick det något bättre. Han förstod alltså vår kulturella bakgrund och vårt kroppsspråk. Därför spelade vi på samma plan med samma regler. Något som vi också fi ck en känsla av, var att ESA: s medarbetare alltid måste visa sig bättre än oss inför varandra, de var antagligen i behov av att visa upp sig för att komma vidare i sin karriär inte bara genom sina expertkunska-per utan också i sitt uppträdande och agerande mot en underleverantör. Vi agerade inte på det sättet, så även i kroppsspråken talade ESA: s orga-nisation och vi förbi varandra.

Projektet byggdes upp i en bra takt, vi plockade in fl er och fl er perso-ner och fyllde rollerna: arkitekt, confi guration manager, testledare och utvecklare. Detta trots att vi inte hade en godkänd kravspecifi kation. Alla dessa personer kom från Combitech Systems. Ett bra team byggdes upp. Vi körde alltså igång med designen utan att ha en signerad och helt färdig kravspecifi kation, men den var tillräcklig för att kunna köra igång. Det fanns i detta läge inte tid att vänta på att få ett godkännande på hela krav-specifi kationen, vi var tvungna att komma igång. Det var vår bedömning. Vi gjorde alltså avsteg från vår ålagda vattenfallsmodell.

Parallellt med mjukvaruutvecklingen pågick hårdvaruutvecklingen. Detta innebar att allt pågick samtidigt. Vi visste alltså inte med säkerhet hur hårdvaran såg ut som vi skulle exekvera på. Processorarkitektur och liknande var klart men inte detaljerna. Detta är i och för sig inte unikt

Förklaringsruta 3

»Drömmen om det exakta språket« är en ide som bland annat har hållits högt av de logiska positivisterna. Idén innebär i korthet att alla begrepp är exakt beskrivna och defi nierade och att de är fria från tolkningsmöj-ligheter.

eller ens speciellt för detta projekt, det är till och med mycket vanligt vid nyutveckling av system. Så har det varit i projekt jag drivit och arbetat i för SAAB, Bofors, Ericsson med fl era. Ett sätt att hantera detta är att arbeta oerhört nära hårdvarugruppen med den del av mjukvarugruppen som är direkt beroende av hur hårdvaran ser ut. Detta fungerar oftast mycket bra, båda sidor har behov av samarbetet. Mjukvaruutvecklarna behöver samarbetet för att de behöver något att exekvera på och hårdvarugruppen för att de behöver mjukvara att testa med. Det som ofta används, och även här hos SSC, är att man köper in en hårdvara som har grundfunktionerna klara och som man kan köra stora delar av mjukvaran på. Speciella hård-varudelar kan sedan vänta lite och köras av teamen tillsammans. Ofta fi nns idag också väldigt bra simulatorer för hårdvaran så att det går att simu-lera funktioner som inte är färdigutvecklade. Det som kan framföras som intressant här, i kravhänseende, var att vi upplevde det som om kraven på hårdvaran blev klara medan vi fi ck kämpa (stånga oss blodiga) hela tiden för att komma framåt på kravfronten på ett helt annat sätt.

Projektet löpte på, vi arbetade parallellt med vidareutveckling, nedbryt-ning av kravbilden och design av mjukvaran. Fokus för kravnedbrytnedbryt-ningen låg på de områden som ansågs svårast och ofta krävde andra typer av analyser. Ett exempel kan vara felmodsanalyser, när olika felmoder skulle aktiveras och man skulle gå till säkra tillstånd. Ett annat område var att analysera hur processerna i mjukvaran skulle tillåtas exekvera för att man skulle säkerställa att det som ska göras hinns med av processorn. För detta tog vi in ytterligare en expert från Combitech. Prioriteringen av dessa olika områden fi ck vi hjälp med av ESA: s personal som hade den rätta erfarenheten för att bedöma var de största riskerna fanns och var mycket utvecklingstid kunde hamna.

Kravhanteringen skedde med ett av SSC utvecklat kravhanteringsverk-tyg. Verktyget hade byggts på det sättet att ett kundkrav skulle brytas ner i två ytterligare nivåer, man talade om nivå 1, 2 och 3 krav. Nivå-tre-kraven var dem som skulle vara underlag för att designa och kunna implementera utifrån. Nedbrytningen och registreringen av kraven i verktyget var helt textbaserad, det som verktyget hjälpte till med var att hålla ihop relatio-nerna mellan kraven på olika nivåer.

Det fi nns fördelar med egenutvecklade verktyg men det fi nns också nackdelar. En fördel här var att det var anpassat till hur ESA ville se på kraven. Detta var troligen en av orsakerna till att man hade utvecklat verktyget. En annan fördel var att man hade kompetens på hur verktyget fungerade och det var möjligt att rätta och förbättra verktyget inom väg-garna på SSC. Dock fanns det några stora nackdelar, en kan skrivas som direkt svar på ovan nämnda fördel, att man hade egen kompetens på

verk-tyget – ingen hade tid att ägna sig åt underhållet på verkverk-tyget, man hade inte tid och det ansågs inte prioriterat. Något som också saknades när man ville använda en modern miljö för utvecklingen, i detta fall ObjectTime, var att kunna integrera kravverktyg med design och utvecklingsverktyg. Detta var inte möjligt vilket medförde att vi manuellt fi ck skapa spårbarhet från kundkrav till implementering. Spårbarheten av kraven i designen och implementeringen var i sig själv ett övergripande krav på utvecklingen.

Implementeringen skulle gå att spåra mot nivå 3-kraven. Det är i och för sig inte någon företeelse som är speciell för det här projektet, men vi hade hoppats kunna använda en helt integrerad kedja. En åtgärd vi då vidtog var att införskaffa ett kravverktyg som integrerade mot vår utvecklingsmiljö och att vi manuellt fl yttade in nivå 3-kraven i detta verktyg. Vi trodde att det nya arbetssätt och verktyg vi introducerade, skulle förbättra kommu-nikationen med kunden och höja utvecklingens kvalitet. Det kom dock att bli så, att detta införande, blev ytterligare ett bakslag i kommunikationen med kunden. Kommunikationen blev inte bättre, snarare dubbel och mera förvirrad. Vi var aldrig helt i synk mellan verktygen, och kunden ville inte godkänna det vi hade i vårt verktyg då det bland annat saknade spår-barheten uppåt i kravhierarkin (spårspår-barheten fanns men bara text uellt).

Förklaringsruta 4

Spårbarhet:

Med spårbarhet menar jag här att man från till exempel ett övergri-pande krav, kan hitta hur detta är nedbrutet till nivå 2-krav och hur dessa är nedbrutna till nivå 3-krav. Från nivå 3-kraven ska det sedan gå att följa vilka delar av designen som realiserar dessa krav. Sen ska det från designen gå att spåra var i koden som detta är imple-menterat. Spårningen ska gå åt båda håll. Alltså, är jag någonstans i koden ska jag kunna hitta från vilket krav detta härrör. Hela vägen upp till högsta kravnivån.

Denna spårning kan göras textuellt och manuellt men underlät-tas oerhört om man har verktygsstöd för den. Det är också mycket större sannolikhet att spårningen är konsekvent och korrekt om ett verktyg används.

Spårningen kan användas för att till exempel se att alla krav är realiserade, se vad som påverkas av en ändring i kravbilden eller tvärtom att se vilka krav som påverkas av en ändring i koden.

Att få full spårbarhet är ett utmanande område, och min uppfattning är att det bygger på att man tror att man kan specifi cera allt till fulländning och att det går att skriva en exakt kravspecifi kation. För att det ska gå att skriva en exakt kravspecifi kation så krävs det att »drömmen om det exakta språket« vore realiserbar, men detta är inte en hållbar ide.

Internt förtroende

SSC-projektet var ett spännande och prestigefyllt projekt för Combitech Systems. När Combitech System Stockholm skulle arrangera ett kund-seminarium på Berns, för befi ntliga och presumtiva kunder, så skulle givetvis månsonden presenteras. För denna presentation blev jag tillfrå-gad. Både totalprojektet och mjukvaruprojektet skulle presenteras – en verklig utmaning. Jag tackade ja. Att jag fi ck göra detta var spännande, då bland andra huvudprojektledaren från rymdbolaget fanns i publiken. Detta uppfattade jag (och tror fortfarande) som att man hade förtroende för mig från både Combitech och rymdbolaget, och att jag hade lyckats ta till mig en hel del kunskap och förståelse för både huvudprojektet och mjukvaruprojektet. Presentationen innehöll till exempel beskrivning och användning av jonmotorn. Presentationen mottogs mycket positivt och vi fi ck beröm för presentationen.

Stormöten med avrapportering

Ungefär varje kvartal hölls ett stormöte med beställaren, ESA, då hela deras projektorganisation kom till SSC i Sundbyberg från Holland. Dessa möten varade i två dagar, och omfattade genomgångar av allt. Mötena var uppbyggda både som stormöten med alla delprojektledare och som möten i smågrupper för att komma ner på detaljnivå. Genomgångarna gällde status på alla delar, till exempel kravläget, designläget, underleverantörer, tidsplanering, upparbetning, nya restriktioner med mera.

Mötena var stora händelser för SSC och man lade ner stor energi på förberedelser. Planören (»den som ansvarade för all planering i projek-tet«) och huvudprojektledaren hade väldigt bråda dagar inför dessa möten – man skulle ge ett bra intryck och förmedla förtroende. Detta smittade givetvis av sig på alla i projektet och speciellt på dem som skulle delta i mötena. Man förväntades ge en positiv bild av progressen och visa upp alla framgångar. Helst skulle man skapa förtroende så att man inte behövde dyka så djupt ner i detaljerna på småmötena och därigenom bibehålla en handlingsfrihet på den lägsta nivån.

vi inte lyckades presentera en positiv status i projektet. Hela tiden kom kravbilden upp som otydlig och inkomplett. Det vi implementerade och testade fungerade. Vi uppfattade att det uppfyllde kraven. Vi skrev också hela tiden parallellt en testplan med testfall som speglade vår uppfattning om hur kraven såg ut och hur de skulle testas.

Det arbete som gjordes var i våra ögon bra och rätt, men vi kom aldrig till den punkten att vi kunde få visa upp det. Formaliteter och krav stod i vägen för oss hela tiden. Förmodligen var det inte direkt formalia som stod i vägen, utan snarare tolkades det vi sa på ett sätt av dem, och på ett annat sätt av oss. Kommunikationen var på ett icke-förståelse plan. Detta slet hårt på mig.

Fokuseringskris

Jag började tappa orken och kontrollen och därmed fokuseringen på pro-jektet. Det var fortfarande spännande och stämningen i mitt team var bra, men min energi fl ydde. Jag sökte då kontakt med en kamrat som jobbat som projektledare i stora mjukvaruprojekt för att få stöd att ta detta pro-jekt i mål. För min del kändes det intressantare att dyka ner i hur assem-blerkoden skulle skrivas och exekvera på den nya hårdvaran än att driva projektet framåt. Både SSC och ESA accepterade min kamrat som rekon-struerare av mitt projekt. Han tog också med sig ytterligare en person för att hålla drivandet och planerandet separerat. Han skulle driva projektet och få stöd i planeringen av aktiviteterna.

De två började intervjua projektmedlemmarna och kontaktpersonerna runt om i projektet för att skapa sig en bild av hur det stod till i projektet. Detta var en del i min överlämning till dem. Deras grunduppfattning var att genom att byta projektledare för mjukvaran så skulle en hel del pro-blem lösas. Situationen att jag hela tiden hamnade i försvarsställning och inte i en kreativ dialog som ledde framåt med goda utvecklingsresultat som följd skulle försvinna. Därmed inte sagt att de utvecklingsresultat vi uppnådde var dåliga, men kommunikationen med uppdragsgivarna fungerade inte. Detta yttrande sig i att jag kände att det framförallt var en person som jag inte lyckades kommunicera med och det var givetvis vår närmsta uppdragsgivare och den person som jag verkligen behövde kom-municera med. Jag lyckades alltså inte spela tillsammans med honom, men han följde nog bara den formalia och kultur som fanns etablerad hos ESA. Den kultur som jag inte förstod.

Den nya projektledaren tog över projektet och jag fungerade som något sorts stöd som hade information om vad som hänt hittills. Detta löpte på bra och projektledaren och hans planerare kom igång. Vid denna tid

närmade sig ett av de stora avstämningsmötena då hela ESA: s projekt-organisation kom på besök. Jag deltog inte själv i detta möte men hade givetvis avstämning med den nya projektledaren under och efter mötet. Det som hände var att han inte lyckades ändra på rådande kommunika-tionssituation. Han gavs aldrig chansen att förbättra situationen, utan kom i samma försvarsställning som jag. De krävde mer och mer insyn och kontroll av vad som pågick, friheten att driva mjukvaruprojektet försvann mer och mer. Planeraren för mjukvaruprojektet rapporterade närmast till planören för hela projektet, en mycket kompetent och lyssnande person, som jag hela tiden hade haft en bra kommunikation med. Men ESA accep-terade inte de planer som han presenaccep-terade för våra delar utan ville gå mer och mer på djupet, vilket gav dem total insyn och gav dem möjlighet att ifrågasätta allt vi gjorde. Den nya planören för mjukvaran var en äldre och mycket erfaren person, som hade hållit i planeringen av mycket större projekt. Resultatet av de krav som kom att ställas på honom var att han efter en period sjukskrevs och inte kom tillbaka.

Situationen hade alltså gått så långt så att det inte gick att bryta den dåliga kommunikationsspiral vi kommit i.

Slutet

Efter ytterligare en tid kom beskedet att vi, projektteamet, inte fi ck gå vidare med utvecklingen av mjukvaran, utan den skulle läggas ut för ny upphandling. Det som angavs som skäl var primärt att de inte trodde att den nya teknik som vi utvecklade med, skulle klara av de krav de ställde. Det skulle alltså enligt dem inte vara möjligt att bygga mjukvara för denna typ av tillämpningar med modern teknik. Man ville gå tillbaka till tradi-tionell vattenfallsutveckling och assemblerkodning.

Uppdraget gick till en belgisk fi rma som byggt denna typ av tillämp-ningar förut och som använde traditionell teknik och inte minst hade levererat till ESA-projekt förut med lyckat resultat. De lyckades också genomföra projektet på ett bra sätt och månsonden kunde skickas ut på sin mission.

Det som hände för vår del var att vi fi ck besked att vårt jobb stoppades och att vi skulle gå hem. Vi fi ck beskedet på förmiddagen, tog farväl på eftermiddagen, fi ck ledigt resten av dagen och gick hem.

Allt detta satte djupa spår i mig. Inte bara i mig, utan i fl era i gruppen.

Efterkommentar

Totalprojektet med SMART-1, månsonden, blev ett framgångsprojekt. Man genomförde experimenten som planerat och det fungerade.

SMART-1 sköts upp 2003-09-27.

SMART-1 gick in i omloppsbana kring månen 2004-11-15. SMART-1 kraschade på månen 2006-09-03.

Varför envisades vi med att gå en väg som inte följde den som ESA önskade?

Combitech Systems uppdrag var att utveckla mjukvaran enligt ett

»modernt« tänkesätt. Sådant var det uppdrag vi fått från Rymdbolaget och så hade vi också byggt upp projektets resurser. Med den bemanning vi hade i projektet hade det inte varit möjligt att vända på utvecklingsmodel-len och följa den vattenfallsorienterade och assemblerkodande varianten.

Vad hände med PSS-05? Man har idag ändrat syn på utvecklingen, man fokuserar inte på dokument på samma sätt som i vattenfallsmodellen. Man har gått över till att fokusera på processer och tillåter, och till och med föreskriver, att den utvecklingsprocess som följs ska vara anpassad till det som ska utföras. Man har med andra ord öppnat för det som vi försökte göra innan öppningen fanns. Kanske hade det gått bättre för oss idag?

I sista kapitlet, »Refl ektion«, återkommer jag till vad som kunde ha gjorts för att förbättra och förändra situationen.

31

Konsten som kunskapskälla

Vem har lust att vara konsekvent?

Jo, dumskallar och dogmatiker, de där tråkmånsarna som håller på sina principer intill änden … En sådan skillnad från den sanne lögnarens temperament, med hans uppriktiga, orädda påståenden, hans sunda och naturliga förakt för bevis av alla slag … En av de främsta orsakerna till att det mesta av vår tids litteratur är så besyn-nerligt banal är utan tvivel lögnens förfall, lögnen som konst, som vetenskap och sällskapsnöje. (Oscar Wilde )2

Oscar Wilde

»Oscar Wilde som jag valt att citera som en öppning till denna bok /…/ hade en hög värdering av konsten som hänger ihop med övertygelsen att den distanserar sig från verkligheten. För konstnären är de givna omstän-digheterna material för en bearbetning som vidgar deras betydelse. De blir något annat än de var från början. I denna överskridande process ligger det konstnärliga skapandets mening.

Konsten är någonting som skapas, till skillnad från det som är. Oscar Wildes intellektuella metod vill avslöja vanetänkandets fördummande och livsfarliga rutiner: ’Människorna är slavar under orden’ skriver han. Ing-enting spelar en viktigare roll i Oscar Wildes estetik än idén att konstens funktion är att vidga medvetandets ramar. Det är betraktaren som gör ver-ket. Läsandet är en kreativ akt. Oscar Wilde genomskådar uppriktighetens och äkthetens estetik. ’Människan är minst sig själv när hon talar i egen person. Ge henne en mask och hon skall säga sanningen.’

/…/ Wilde kom att tjäna som en förebild för Karl Kraus , infl ytelserik publicist i Wien kring förra sekelskiftet. Karl Kraus studerade noga många av Oscar Wildes essäer och tog starkt intryck«3

1 Göranzon 2001, s. 159 2 a.a. s. 7

I den tolkning som presenteras ovan låter Bo Göranzon , via Oscar Wildes lögner syfta på att vi måste låta konsten arbeta i vår vardag. Att jag plockat med Oscar Wilde -citatet är för att jag vill låta tråkmånsarna vara »dröm-men om det exakta språket«. Vi måste låta denna dröm somna in. Om vi tror på den hela tiden kommer vi att så småningom framstå som Wildes

»… dumskallar och dogmatiker, de där tråkmånsarna som håller på sina principer

intill änden …«. Wilde säger att vår tids litteratur är banal, detta kan ofta överföras direkt till tron om hur man till exempel skriver kravspecifi ka-tioner. Skrivarna är obildade och outbildade och tror att det de skriver är exakt oavsett alla kommande tolkningar och användare. Detta är vad jag ska försöka bemöta och förklara i detta kapitel. Därav detta inledande Oscar Wilde-citat. Jag vill med detta slå an ackordet för hur vi kan se på skrivandet och tolkandet av till exempel kravspecifi kationer, men kravspecifi kationen ska här mer ses som ett uttryck än en verklig artefakt. Det spelar egentligen ingen roll om vi pratar om kravspecifi kationer här för det det handlar om är kommunikation mellan människor, enskilda individer och grupper.

»’Vi hade för dåliga kravspecifi kationer’ är en vanlig slutsats som snabbt accepteras inom den befi ntliga tankestilen. Att det skulle ligga något para-doxalt i att skriva en kravspecifi kation för något man inte kan överblicka är inte direkt uppenbart. Om man däremot går utanför detta sammanhang och diskuterar möjligheten att skriva en kravspecifi kation till Edison inför hans arbete med att uppfi nna glödlampan så kastar man nytt ljus på problemet.«4 Så formulerar Christer Hoberg problemen kring att formulera och skriva en kravspecifi kation i sin licentiatuppsats. Det fångar mycket av de pro-blem som också jag beskrivit i det första kapitlet.

Laurikainen uttrycker detta med en förståelse inom en grupp och mel-lan grupper som att det bara kan existera som intersubjektivitet. Han beskriver i sitt fall synen på tron om den objektiva vetenskapen, men det passar precis lika bra som beskrivning av dilemmat som beskrevs i förra kapitlet. Laurikainen skriver:

»Av den orsaken är den empiriska kunskapen aldrig en kunskap om den objektiva verkligheten. Vetenskaplig objektivitet kan bara betyda

intersub-jektivitet: en strävan efter att olika iakttagare (som har ett mänskligt psyke och mänskliga sinnen) i stor utsträckning som möjligt kan nå samförstånd om det som gäller verkligheten.«5

4 Hoberg , s. 28 5 Den inre bilden, s. 26

Vad som också fi nns i citatet ovan, är att allt detta med intersubjektivitet och till exempel kommunikation handlar om människor och deras för-måga till tolkning och förståelse.

Åter till kravspecifi kationen och Christer Hobergs resonemang ovan. Krav specifi kationerna är ofta inte dåliga men befi ntlig tankestil har inga verk-tyg att hantera det verkliga problemet, att kravspecifi kationer skrivs i krav-ställarens intersubjektiva rum,6 _{och läses i ett annat intersubjektivt rum.}

Kommunikationen mellan de intersubjektiva rummen fallerar alltså i något led. De intersubjektiva rummen har inte samma tankestil. De förstår egentligen inte varandra på ett djupare plan.

Tore Nordenstam säger i introduktionen av Anders Lindseths uppsats i

Dialoger nummer 81–82 2007 Harry Martinson/intransitiv förståelse:

»/…/ en naturlig respekt för det individuella, för människan som indi-vid. I sina refl ektioner omkring det temat vidgar han perspektivet till en grundläggande kritik av djupt förankrade inslag i vår västerländska kultur, som enligt Anders Lindseth kännetecknas av en nedprioritering av förstå-elsen av det individuella och en upphaussning av faktavetandet. Det som ofta fattas är en förståelse av det systematiska teoretiska vetandets gränser och förutsättningar. Till de tysta förutsättningarna hör också den etik som ingår i alla människors möten med andra. I en viss mening kan man därför säga att etiken har företräde framför vetandet.«7

Alltså ännu ett exempel på hur viktigt det är att se människorna bakom kunskapen och inte bara kunskapen. Kunskapen sitter i människornas tolkningar och kommunikation emellan dem.

Nu hoppas jag att läsarna och jag befi nner oss i samma intersubjektiva rum eller åtminstone vill vara det. För det är vad denna uppsats handlar om, intersubjektiva rum, och hur vi får olika intersubjektiva rum att arbeta ihop på ett bra och konstruktivt sätt. Den intersubjektiva kommunikatio-nen måste fås att fungera.

Joseph Conrad

»Misslyckandet« – grundkänningen som beskrivs i första kapitlet, var en stark upplevelse och ett sätt hade varit, och är, att låta konsten arbeta och bearbeta denna erfarenhet. Det är vad dialogseminariet mycket handlar om. I Bo Göranzons Spelregler fi nns texten nedan som delvis binder ihop 6 Johannessen , s. 106

erfarenheten – konsten – refl ektionen vilket är en språngbräda vidare in i denna uppsats för att fånga det kunskapsteoretiska i grundstötningen ovan.

Citatet nedan, har jag alltså som nyss sagt, plockat ur Bo Göranzons

Spelregler. Texten kommer ursprungligen från Joseph Conrads bok Negern

på Narcissus. I Bo Göranzons Spelregler fi nns detta i kapitlet »Tyst kun-nande och risker« och handlar om hur man kan använda konsten som kunskapskälla. Låt mig här citera och kommentera stora delar av detta stycke då det är centralt för det tänkesätt som genomsyrar min uppsats.

»/…/ Joseph Conrad , som var sjökapten vid förra sekelskiftet, skrev i en konstnärlig gestaltning om sina erfarenheter; temat som återkom var bland annat ledarskap ombord på ett fartyg. Conrad skrev att ett fartyg godtar ’inte bluffmakare’. Ska man klara ett fartyg i hårt väder duger bara rejält yrkeskunnande.«8

Det i kapitel 1 beskrivna projektförloppet, beskriver ur ett kunskapsteo-retiskt perspektiv, hur olika yrkeskunnanden kolliderade. Mer om detta nedan. Även inom det av mig beskrivna området, systemutveckling, gäller att ett rejält yrkeskunnande är nödvändigt för framgång, men det är inte tillräckligt.

»I förordet till romanen Negern på Narcissus skriver Conrad om konstens uppgift: Den uppgift som jag försöker genomföra är att med det skrivna ordets makt få er att höra, få er att känna – och framförallt få er att se. Detta – och inget annat, och det är allt. Konstnären ger den verklighet han beskriver en intensivare framtoning. Han griper verkligheten och skapar om den så att var och en som tar del av vad han skapat säger sig: Så är det, jag igenkänner vad jag alltid vetat men inte haft ro och allvar nog att stanna kvar vid. Eller kanske tvärtom: Detta är för mig en ny erfarenhet som jag tar med mig. Den ger mig möjlighet att kasta nytt ljus på invanda klichéer och utveckla min fantasikänsla.«9

Även jag har använt konsten som inspirationskälla, till exempel kommer det senare bearbetningar via Gombrowicz i kapitel 4, under bland annat rubriken Gombrowicz makt . I arbetet med att skriva denna uppsats har jag också passerat ett antal andra konstnärer (författare primärt) som inte syns i texten, men som ändå har haft stort infl ytande, bland andra bör nämnas Strindberg , Ibsen och Beckett . Dessa intresserar mig då de tillför många 8 Göranzon 2001, s. 159–160

idéer och förklaringar till mina funderingar kring tyst kollektiv kunskap. Det mesta i denna uppsats rör sig på ett sätt som har inspiration och kunskap genom konsten. Konsten driver analysen av skeendet framåt och (kan) skapa förståelse genom att vi då kan tänka analogiskt mot det som varit.

»Refl ektion är inte alltid en process i harmoni och balans. Den kan uppstå efter ’grundkänning’, som Joseph Conrad beskriver så här:

Tänk er att man satte en karl att med förbundna ögon köra en fl ytt-vagn på dålig väg. Jag kan försäkra er att jag både rös och svettades över mitt uppdrag. Det är ju i alla fall så att det för en sjöman står som en den oförlåtliga synden att få grundkänning med ett fartyg som under hans vård anta hålla sig fl ott hela tiden. Det är kanske ingen annan som mär-ker något men man glömmer aldrig stöten, förstår ni. Det är en stöt rätt i hjärtat. Man kommer ihåg den, man drömmer om den, man vaknar på natten och tänker på den – åratal efteråt – och blir ömsom varm och kall över hela kroppen.

Det här är en utomordentlig beskrivning av hur kampen med praktiken bygger upp ett yrkeskunnande.«10

Den ovan beskrivna händelsen var för mig en »grundkänning« som Conrad beskriver det. Det kändes i hela kroppen.

Ludwik Fleck

Tankestil – Så här skriver Ulla von Essen i Dialoger nummer 47 1998.

»Tankestilen innefattar en kunskapsteori där de grundläggande och ofta implicita föreställningarna och idéer – ibland oerhört långlivade, ibland historiskt situationsbestämda – som människor bär på spelar en viktig roll. Tankestilen innefattar också den speciella och mångfacetterade praktik som ett gediget yrkeskunnande, inlärt under en lång tid utgör. Tankesti-len lägger alltså till en historisk – och moralisk – dimension till arbetets kunskapsvärld.«11

Begreppet tankestil var något som introducerades av Ludwik Fleck , en polsk-judisk läkare och kunskapsteoretiker.

10 a.a. s. 159–160

»/…/ publicerades 1935 under titeln Entstehung und Entwicklung einer

wis-senschaftlichen Tatsache.12 _{Fleck betonade här att allt tänkande och allt} kun-nande är kulturellt-socialt-historiskt betingade praktiker, tankestilar, som utvecklas i olika mänskliga konstellationer, tankekollektiv.«13

Alltså sitter förståelsen inom ett tankekollektiv i den gemensamma upp-fattningen, man har samma praxis, man arbetar i samma intersubjektiva rum. Påverkan fi nns då från kulturellt betingade infl uenser, till exempel beskrivet i förra kapitlet som – jag var svensk och hade svenska kulturella infl uenser och skulle samarbeta och förstå det som mina italienska upp-dragsgivare beskrev med sina italienska kulturella infl uenser. Jag var inte beredd och det var nog inte de heller. Två olika tankekollektiv, två olika intersubjektiva rum.

Med kulturellt menas här ett större begrepp än det som beskrivs som en skillnad mellan en svensk och en italienare, det etniska. Det som omfattas av kulturellt omfattar mycket av det som ofta kallas företagskultur eller organisationskultur. Detta är något som uppträder på alla nivåer i ett före-tag eller organisation. Föreföre-tagsledning, divisioner, avdelningar, sektioner, grupper, informella grupperingar med mera, alltså precis var som helst i organisationen. Alltså mycket av det som sägs »sitta i väggarna«. Genom att det uppkommer olika företagskulturer i olika delar av organisationen kan situationen uppstå att dessa delar av organisationen kan komma »på kant« med varandra, bland annat, genom att de inte förstår varandra – de talar samma språk, använder samma ord men förståelsen är obefi ntlig. Det är oftast inte så drastiskt men det är mycket vanligt att ett visst »gnissel« uppstår mellan en organisations delar och produktiviteten sjunker. Detta

»gnissel«, stort eller litet, kan ofta spåras i att organisationsdelarna arbe-tar i olika intersubjektiva rum, som mer eller mindre överlappar varandra. Mellan företag kan samma resonemang appliceras. Beställare – leverantör, säljare – köpare, samarbetspartners arbetar ofta också i olika intersubjektiva rum.

Socialt – ESA jobbade i en typ av organisation som ställde vissa krav på beteende och vi jobbade i en annan typ av organisation som, tyvärr, ställde andra typer av krav på vårt beteende, en social kollision. »De fanns en svensk i ESA: s organisation och när han gick in och var med på möten gick det något bättre. Något som vi också fi ck en känsla av var att ESA: s medarbetare alltid måste visa sig bättre än oss inför varandra. De var antag-ligen i behov av att visa upp sig för att komma vidare i sin karriär inte bara 12 Finns på svenska, Uppkomsten och utvecklingen av ett vetenskapligt faktum.

genom sina expertkunskaper utan också genom sitt uppträdande mot en underleverantör. Vi agerade inte på det sättet, så kroppsspråken gick också förbi varandra.«14 _{Två olika tankekollektiv, två olika intersubjektiva rum.} Samma resonemang som ovan kan också appliceras på det sociala – sociala dilemman kan uppstå mellan olika företagsdelar, i olika konstellationer, såväl som mellan olika företag. De kan gälla både inom ett land och inom ett företag som spänner över fl era länder och företag i olika länder.

Historiskt – ESA hade alltid utvecklat med en vattenfallsmodell och i handkodad assembler. Vi ville använda iterativ utveckling och kodgenere-rande verktyg – detta gav en historisk, nutidskollision. Två olika tankekol-lektiv, två olika intersubjektiva rum. Organisationers och företags historia skapar på samma sätt som det kulturella och sociala olika intersubjektiva rum. Företag kan till exempel ha slagits samman, delar av organisationer kan ha delats och lagts ihop, sammanläggningar av företag eller organi-sationer är ett område för en egen bok, men jag vill här bara påpeka att i sådana situationer delas de intersubjektiva rummen och det intersubjek-tiva rummet kan då försvinna helt. Eller så kan sammanslagning skapa nya intersubjektiva rum med framgångsrika eller katastrofala följder.

I Flecks beskrivning fi nns alltså alla ingredienserna till den »grundstöt-ning« som jag gjorde. Här fi nns förklaringar till »grundstötningen« och kanske lösningar i tankekollektiv – det intersubjektiva rummet – som ska tas tillvara för att i framtiden nyttja detta i likartade »kulturellt-socialt-historiskt betingade« projekt och projektgrupper.

Låt mig förstärka detta med citat direkt från Fleck :

»Dessa formella ståndpunkter tar emellertid för det första ingen eller alltför liten hänsyn till den kulturhistoriska påverkan som ett sådant kun-skapsteoretiskt val, dvs. den påstådda konventionen, är utsatt för. På fem-tonhundratalet fanns det ingen möjlighet att välja ett naturvetenskapligt, patogenetiskt syfi lisbegrepp i stället för ett mystiskt-etiskt. Under varje epok är alla eller de fl esta begrepp stilriktigt uppbundna av den ömse sidiga påverkan som fi nns mellan dem. Man kan därför tala om en tankestil som bestämmer varje begrepps stil. Historien lär oss att häftiga strider om begreppsdefi nitioner förekommer. Detta visar i hur liten grad logiskt sett likvärdiga konventioner uppfattas som likvärdiga och att valet mellan dem inte sker från några som helst utilistiska överväganden.«15

Här utvecklar Fleck den historiska komponenten om vad som kan stå 14 Citat ut föregående kapitel.

bakom skillnader i tankestil. En av de komponenter han nämner är »häf-tiga strider om begreppsdefi nitioner«. Detta är något som kan vara en starkt bidragande orsak till att de intersubjektiva rummen inte vill samar-beta på ett bra sätt. Men man behöver inte dra det så långt så att det fi nns stridigheter om begreppen, det räcker med något så enkelt som att vi tror att vi menar samma sak med begreppen men att de i realiteten har olika innebörd för oss. Detta kanske dock rent av är värre än att vi inte förstår varandra explicit, och det kan vara starten på riktigt »häftiga strider«. Men, som Fleck säger, det historiska kulturarvet är en stark komponent i vår tankestil.

Tradering och inre bild

Bo Göranzon har på ett lite annat sätt formulerat det intersubjektiva. Han menar, och jag instämmer, att det intersubjektiva är något som måste vara något mellan människor. Precis på samma sätt som också Laurikainen hävdar att människorna är centrala.16 _{Intersubjektiva rummet för en grupp} existerar i gruppen och inte i individerna. Det sitter i kommunikationen. För att intersubjektiva rum ska kunna kommunicera med varandra krävs att de har samma tankestilar och praxisar. Det är antagligen till och med så att de då är samma intersubjektiva rum. Nu till hur Göranzon uttrycker det via kopplingar till konsten (Gombrowicz och Strindberg ).

»Gombrowicz och Strindberg är båda uppmärksamma på hur vi påverkar varandra ömsesidigt. I stället för att ställa det objektiva mot det subjektiva är det mer fruktbart att tala i kategorier av det intersubjektiva – vad som händer mellan människor, att lära sig lyssna till andras erfarenheter och perspektiv på verkligheten, att över tiden bygga upp en gemensam

inter-subjektiv erfarenhet.«17

Påverkan går alltså åt båda håll, den är symmetrisk, om kommunikationen ska bli bra och överbygga klyftorna. För att överbygga klyftorna måste alltså förståelse traderas eller, annorlunda uttryckt, intersubjektiva rum skapas. Något som inte heller förenklar traderingen är att det intersub-jektiva inte är något statiskt som bara skrivs ned och sen gäller, utan en dynamisk företeelse som pågår och förändras hela tiden. Den som var del av ett intersubjektivt rum vid en tidpunkt behöver inte vara det vid en annan tidpunkt.

16 Den inre bilden, s. 26 17 Göranzon 2001, s. 30

Att förmedla eller tradera förståelse eller skapa intersubjektivitet är alltså inte lätt.

»Tankestilen på Narcissus är förmedlad och traderad genom ett långvarigt inskolande till en specifi k kunskapsvärld genom praktiska exempel. Novi-sen har i en mästare-lärling-situation utvecklat de nödvändiga färdighets-kunskaperna. Ett engelskt uttryck från just segelsjöfarten; ’to know the ropes’ beskriver träffande det tillstånd som kan liknas med att över huvud-taget börja kunna något. I kontakt med tilltagande färdighetskunskaper växer sedan förtrogenhetskunskapen långsamt fram. Nybörjaren blir en mer och mer kompetent utövare av vissa tekniker samtidigt som han börjar uppfatta likheter av analogisk natur i nya problemsituationer, och bygger upp ett bättre och bättre omdöme. Självkänslan växer och yrkesstoltheten etableras. Fleck kallar denna process initiation. Genom en utdragen ’initia-tionsrit’, träder den oinvigde, genom mötet med de praktiska exemplen, in i en värld som tidigare var sluten för honom. ’Vevlingar’, ’koffernaglar’, ’drej-rep’, ’nockbändslar’, ’klart att vända undan vind!’, ’brassa storrån fyrkant!’ – termer och kommandon som för oss och novisen döljer en otillgänglig praktik, integreras så småningom i en tyst eller intuitiv kunskap.18 _Detta lärande genom exempel gäller också de moraliskt-normativa delarna av tankestilen. Det fi nns inga explicita formulerade regler kring det solidariska arbetet på Narcissus, utan det är en praxis man skolas in i.«19

Är det så att förståelse och den inre bilden är intimt kopplade?20 _Maja-Lisa Perby berättar i sin »Den inre väderbilden – teknikbedömning från ett mitt-i-arbetet-perspektiv« att tillträdande meteorolog skapar sig en inre bild över hur vädret ser ut i närområdet med hjälp av tillgängliga data samt i dialog med avgående meteorolog. Maja-Lisa Perby använder följande citat för att beskriva hur den inre bilden byggs upp, »Min första bild är rätt teore-tisk – jag utgår från meteorologisk teori om atmosfärens uppbyggnad. Efter hand fylls den ut med allt mer av det rådande väderläget, också det som inte passar in riktigt i de teoretiska förväntningarna. Det är en bild av atmosfä-ren som den är. Jag blir bekant med väderutvecklingen: En ny bekantskap, något som är unikt för dagen även om den har likheter med tidigare.«21

18 Ludwik Fleck , Uppkomsten och utvecklingen av ett vetenskapligt faktum (1997), s. 61. Fleck visar också här hur tankestilen förstärks och formuleras i t.ex. vetenskapliga tankekollektiv genom att den teoretiskt formulerade kunskapen i läroböcker och handböcker förbinds med de praktiska exemplen och skapar ett ”gestalt – seende”

19 Ulla von Essen i Dialoger nr 47 1998, Tankestil och Tankekollektiv, s. 24 20 Den inre bilden, »Den inre väderbilden« – Maja-Lisa Perby

Detta känns som det också skulle kunna vara en beskrivning hur en, till exempel, erfaren systemarkitekt bygger upp sin bild, förståelse, av ett system, nytt eller befi ntligt. Givetvis med en annan tidshorisont än meteorologen, hon har horisonten sitt skift – kanske 6 timmar, medan sys-temarkitekten har ett perspektiv på några månader, eller kanske rentav år. Citatets fl öde är ett tydligt exempel på det som Christer Hoberg beskriver i Komplexitetsmax, vägen från kaos till ordning (struktur) via komplexitet. Christer Hoberg gör även själv kopplingen till Maja-Lisa Perbys meteoro-loger i sin uppsats.

Artefakten Kravspecifi kation

Låt mig använda artefakten kravspecifi kation för lite belysning.

En kravspecifi kation ska innehålla de krav som uppdragsgivaren, bestäl-laren, användaren eller fi nansiären ställer på det som ska utvecklas. Rol-len för den som specifi cerar kraven är egentligen egal – det viktiga här är att det är olika instanser som ställer och realiserar kraven. Kraven i specifi kationen ska vara entydiga, realiserbara, testbara och verifi erbara. Ofta klassifi ceras kraven i olika klasser till exempel i Funktionella och Icke funktionella krav.22 _{En annan klass av krav är de som beställaren} har implicit, det vill säga hans eller hennes förväntningar. Dessa är oftast inte nedtecknade och heller inte, i de fl esta fall, enkelt verbaliserbara, vi kan här tala om »tysta« krav, alltså en tyst kunskap hos beställaren. Till exempel, verbaliserbara men inte så kvantifi erbara: systemet ska fungera bra och vara lättanvänt.

Kravspecifi kationen som kalkyl

Låt oss göra ett tankeexperiment och anta att vi kan formulera våra krav så att de är entydiga, kompletta och testbara och fria från tolkningsutrymme genom ett exakt språk. Vad händer då? Vi skulle helt maskinellt kunna generera kod utifrån dessa krav och då erhålla ett system som uppfyller allt som vi specifi cerat. Detta låter till och med absurt.

Att kraven skall vara entydiga och testbara betyder att kraven skall beskriva allt, vara fria från tolkningsutrymme, vara logiskt sammanhäng-ande och bara kunna ge ett resultat. Det resultat som författaren har tänkt sig. Detta inkluderar då också författarens förväntningar. Det innebär alltså att språket för att formulera kraven är så precist och entydigt att inga missförstånd kan uppkomma. Denna kravspecifi kation skulle jag vilja se 22 Ickefunktionella krav är till exempel användbarhet, säkerhet, tillförlitlighet och så vidare.

för något som är icke-trivialt (i specifi kationshänseende). Detta går alltså tillbaka till drömmen om det exakta språket, som bland annat har föresprå-kats av de logiska positivisterna. Den »logisk-positivistiska traditionen« karakteriseras av tre idéer:

I: idén om vetenskapernas enhet

II: idén om ett matematiskt-logiskt idealspråk

III: identifi kationen av det empiriska meningsfulla med de påstå-enden som kan verifi eras.23

De två sista påståendena kan defi nitivt appliceras på det klassiska sättet att skriva och uppfatta hur en kravspecifi kation ska skrivas och vara upp-byggd. Kraven skall vara entydiga och testbara (verifi erbara). Den första karakteriserade idén känns dock lite mera perifer i detta samanhang.

Logisk positivism

Logiska positivisterna enligt Kjell S. Johannessen :

»Vi kan bara ha kunskap om sådant som för det första kan formuleras språk-ligt och som för det andra kan beläggas med empiriska metoder eller bevisas med formella metoder. Allt annat faller utanför den verkliga kunskapens område. /…/ När problemet formuleras på detta sätt bygger det gärna på en förutsättning som kan vara värd att granska. Vi har en tendens att följande två villkor måste vara uppfyllda för att det skall kunna vara tal om kunskap:

1. Det måste vara möjligt att formulera vårt vetande på ett eller annat språk.

2. Den språkligt formulerade utgåvan av vetande måste kunna beläggas empiriskt eller bevisas med formella metoder.«24

Jag är själv utbildad civilingenjör inom teknisk fysik och har därför en stark skolning i naturvetenskapligt tänkesätt, speciellt inom teknik, fysik och matematik. Min bild, så här i efterhand, är att allt vi lärde oss var uppbyggt kring att det var entydigt och verifi erbart. Matematikkurserna byggde på att bevisa satser – de skulle byggas upp logiskt. Fysiska experi-ment genomfördes, man hade en hypotes, som vi fi ck via en lärobok eller en lärare, som skulle verifi eras empiriskt genom allehanda experiment. Inom teknik, i mitt fall programmering/systemutveckling, lärde vi oss att 23 Bengt Molander , Vetenskapsfi losofi , s. 180.