Intervju med Niklas Lindwall på Spinit

Niklas Lindwall på Spinit om hur han tänker när han förbereder och planerar inför nya stora it-projekt. Niklas har jobbat med systemutveckling i 20 år, är utbildad civilingenjör och jobbar som teknisk projektledare idag. Han brukar presentera sig som en social person som har lätt för att ta till sig saker och ting, och är öppen och nyfiken för nya tekniker.

I ett av mina möten med dig så visade du ett komplicerat Excelblad med massa flikar och beräkningar om hur lång tid ett av dina projekt skulle ta. Tror du att det skulle vara möjligt att bygga avancerade webblösningar utan hjälp av Excel?

– Nej, eller jo (skratt), många gillar ju inte att jobba i Excel, men det beror på vilka kunder man jobbar med. Om kunden är van vid att jobba i Excel så är det en fördel för att man får en bra översikt och det är lätt att göra uträkningarna inför ett projekt. Excel är ju inget vi använder när vi bygger system utan är praktisk hjälp när man skall räkna på ett projekt och ta fram en offert. När man väl har satt igång projektet så använder man inte det på samma sätt. Excel kan vara ett bra verktyg många gånger, men jag tycker inte att man ska grotta ner sig alltför mycket och bygga för avancerade modeller, då blir det ofta så att bara en person vet hur allt fungerar.

Spinit bygger och designar olika avancerade webblösningar. Var är dina tankar kring hur man ska designa hållbara webblösningar och it-system som ska kunna användas länge?

– Jag brukar alltid köra enligt mitt mantra Separation of Concerns, det vill säga att man ska tänka i moduler, där varje modul har en dedikerad uppgift så att man får mindre utbytbara micro-tjänster. Det här är något som är ganska givet i dagens arkitektur, men det har inte alltid varit lika självklart. När Spinit startade för över 20 år sedan då tänkte vi inte direkt i de banorna, då blev det mer färdiga applikationer som var lite monolitiska och slutna.

En del system gör att vi är beroende av att använda just deras produkter. Vad kan man tänka på när man bestämmer hur ett system ser ut så att man inte blir fastlåst i det i framtiden?

– Om man har mindre moduler i ett system så blir de lättare att utveckla för att man kan fördela arbetet på ett helt annat sätt och framför allt så får man inte ett beroende mellan de olika modulerna. Om man arbetar på detta sätt så får man utbytbara moduler och det blir lättare att underhålla systemet i framtiden. Detta därför att man kan byta ut en tjänst utan att behöva byta ut alla tjänster som ingår i applikationen.

När man bygger ihop olika system så pratar man ofta om API, hur förklarar du vad en API är för en person som inte är insatt i det tekniska?

– API:er handlar om att dela data mellan system och tjänster. Det kan vara både internt inom ett system men även utåt för andra att nyttja eller integrera mot. Majoriteten av alla appar du använder på din telefon kommunicerar med API:er på ett eller annat sätt. Google Maps är ett utmärkt exempel där de byggt ett utvecklar-API som kan nyttjas av alla i hela världen för att bygga egna tjänster mot vilket också otroligt många tjänster idag nyttjar. Där kan man t.ex. skicka in adress och få tillbaks en position på en karta att visa upp. Eller det omvända om du skickar in en position och får tillbaka en adress.

En stor risk när man bygger digitala plattformar är att man involverar slutanvändarna alldeles för sent. Jag hörde till exempel om ett landsting som byggt en diabetesapp utan att testa den på någon diabetiker under tiden de utvecklade den. Den fungerade inte alls. De fick snabbt arrangera en workshop med flera slutanvändare och på ett par dagar var appen klar att testa igen. Nu med nöjda användare. Vad tror du det är som gör att man ofta kommer på alldeles för sent att man ska testa produkten?

– Det där är ju rätt konstigt för alla är medvetna om det och man vill involvera slutanvändaren tidigt, men det har en tendens att ändå bli alldeles för sent. Jag tycker att slutanvändarna ska vara med redan i kravställningen innan man drar igång projektet. Dock är det inte givet att de är med från början. I värsta fall så kommer slutanvändarna in i en acceptans-test-period när man är i princip klar. Under projektets gång så har man jobbat sprintvis, men de som faktiskt sitter och använder systemet kanske inte testar igenom ordentligt på vägen. Varför det blir så här är svårt att säga, det har säkerligen med tid att göra, att slutanvändarna har svårt att ta tid från sitt dagliga arbete. Tyvärr är det väldigt kortsiktigt tänkt.

Många personer måste klicka och prova innan de kan ge feedback och få en känsla för om webbapplikationen fungerar. Jag har hört det från flera håll att man som projektledare ofta inte får någon bra feedback innan man har ett fungerande system. Detta är ett moment 22, och gör det svårt att komma framåt trots att man har gjort mock-ups och testat olika teorier. Har du några tankar kring hur man komma runt detta problemet?

– Det är väldigt olika hur man kan ta till sig en mockup, vi som sitter i det och jobbar som systemutvecklare kanske har en bättre förståelse för hur det kommer att fungera. Men det är svårt för en slutanvändare att se det, de vill gärna ha något att klämma och känna på, och klicka runt i. Ofta är det först då som de inser vilka funktioner de behöver mer i detalj. Vi jobbar agilt och i sprintar* och efter varje sprint så finns det något som är levererbart som man kan testa, och det är här man verkligen behöver involvera slutanvändarna efter varje leverans.

(*En sprint är en regelbunden, repeterbar arbetscykel i Scrum-metodiken. Efter varje sprint är det man byggt redo för att granskas och testas. Oftast är varje sprint mellan 7 till 30 dagar)

Kommentar: Tänk på våra skattepengar och vad de används till om kommuner och landsting inte använder agila metoder när de utvecklar digitala system, vilket slöseri med tid och pengar.

– Verkligen.

Hur håller man en digital webblösning levande länge?

– Det gäller att ha kontinuerlig avstämning med slutanvändarna så att de får en chans att komma med sina förbättringsförslag rent funktionellt. Sen handlar det också om underhåll på en mer teknisk nivå så att man hänger med i nya uppgraderingar av de tredjepartsprodukter som man använder.

Vad menas med uppgradering av tredjepartsprodukter?

– När man bygger it-system så använder man olika ramverk när man utvecklar. Det kan t.ex. vara Javascript ramverk som Angular och React eller NServiceBus för Service Bus kommunikation och NHibernate för data hämtning. Det händer mycket inom ramverken och det kan ju vara så att man måste byta ut en modul. Har man ett moduliserat system från början så ska det inte så svårt. Det kanske kommer något nytt som man tycker är mycket bättre och vill använda istället och då ska det vara fullt möjligt att göra det. Risken är att man inte följer med kontinuerligt, och då blir det en väldigt stor grej att göra uppgraderingen.

Jag tänker på alla hackerattacker som har hänt senaste tiden, kan de ha skett för att man inte har uppgraderat sin mjukvara och jobbar i gamla system?

– Så kan det absolut vara.

Vad gör mest skillnad när ni jobbar med en kund? Är det en bra specifikation eller en bra mottagare hos kunden? Eller är det något annat som gör att man lyckas bra när man är en leverantör som Spinit?

– Det är givetvis en kombination, att man har en bra mottagarpart som man kan bolla systemkraven med innan projektet drar igång är ju oerhört viktigt. Att man involverar slutanvändaren tidigt är oerhört viktigt, likaså att man får bra feedback under resans gång är en av nycklarna till ett lyckat projekt. Man behöver ha ett tätt samarbete under hela projektet, och likaså efteråt när man jobbar med förbättringar av systemet.

Ni jobbar ofta med ett mixat team med ett par erfarna systemutvecklare och några som nyligen studerat klart. Hur funkar det med det kollektiva lärandet när ni jobbar med nya projekt?

– Ofta så försöker jag skapa ett team med en bra mix med seniora utvecklare och utvecklare med mindre erfarenhet. När de som är nya kommer in är det viktigt att de får en mentor som de kan bolla saker med.

Vad försöker du uppmuntra när någon är ny i ett projekt?

– Om det är en befintlig applikation som de ska jobba med så försöker jag beskriva en helhet av applikationen så att de får en helhetsförståelse för vad det är vi ska göra och kanske inte bara beskriva den delen som de ska utveckla just då. Det är bra att få en helhetsbild av vad vi försöker uppnå, detta gäller alla system som vi jobbar med. En förklaring till lyckade projekt är att alla är involverade även om man sen bara sitter och gör en del.

Hur ofta har ni möten när ni jobbar med projekt?

– Vi brukar köra dagliga möten, daily standups, för att gå igenom vad man gjorde dan innan och vad som ligger för dagen. Vi utvecklar ofta i sprintrar om tre veckor och då har vi planeringsmöte inför varje sprint, sen har vi en demo för kunden med vad man levererar i varje omgång.

Har du några tips till företag och organisationer som vill bygga om sina gamla it-system?

– Tänk igenom vad ni faktiskt behöver, ofta så har man en tendens att tänka lite för långsiktigt. Ofta behöver man inte ha ett helt färdigt system vid första leveransen, utan man ska tänka i faser och mindre delar så att man kan få ett fungerande system som löser de kärnfunktionerna som man är ute efter. Många har en tendens att förstora saker och ting från början för att systemet ska vara superflexibelt och lösa allt som eventuellt kommer att hända i framtiden. I detta stadiet så behöver man inte tänka på alla de funktionerna som man eventuellt behöver i framtiden, utan man tjänar på att dela upp det i olika faser.

Tack så mycket!