Sebastian om dynamiska arbetssätt och projektledning

När man jobbar med digital­isering i projekt­form så är ett bra fungerande arbets­sätt en av nycklarna till att komma framåt. Dåliga arbets­metoder gör att det tar längre tid, kostar mer och de man byggt har inte de funktion­erna man vill ha.

På Spinit kallar vi våra projekt­ledare för kaptener och så har det varit under många år. Kaptenen tar ansvar för att samordna alla funk­tioner i det vi bygger och leder teamet av ut­vecklare. Varje nytt upp­drag är unikt och vi jobbar i olika steg för att skapa förstå­else och sedan utveckla det som kunden vill att vi ska göra.

Jag pratade med Sebastian Appler Olsson, en av kapten­erna på Spinit, om hur han ser på sitt jobb.

Hur jobbar du när du leder ett nytt uppdrag för Spinit?

– Jag jobbar alltid dynamiskt och använder mig av de arbets­tekniker som passar in för det spec­ifika upp­draget.

– Det första jag gör att identifiera vad en kund har och inte har tillgång till när dom kommer till oss. Har de någon som kan generera design­skisser då tar de ansvar för det. Eller har de någon som är bra på att skriva tydlig dokumentation om hur systemet ska fungera. Likaså vet de vilken data som ska skickas var, och vilka rättig­heter olika använd­are ska ha då är ju vissa delar av jobbet redan gjort.

– Om specifika­tionen är klar från början så behöver vi inte lägga ner energi på det, och vi fyller upp de delarna som kunden inte har. Ofta har en kund inte allt i sina team de behöver för att bygga det de vill. Då går vi in och komp­letterar med våra kunskaper.

– Jag tycket inte det är kul att följa ett färdigt arbets­sätt bara för att det står så i projekt­hand­ledar­hand­boken. Det kan bli jätte­tråkigt och så vill man ju inte ha det. En av an­led­ningen till att jag tycker så är för det tillför onödigt gnissel mellan projekt­ledaren och teamet. Inför man många ritualer och arbets­sätt som projekt­ledare kan det orsaka tids­krävande krångel som teamet kanske inte är i behov av.

Vad gör du i början av ett nytt uppdrag?

– Jag sätter mig alltid in i speci­fika­tionen och tittar på vilka teknik­val som ska göras. Här så pratar jag ofta med någon som har gjort något liknande, bollar några idéer och så kommer man fram till ett förslag. I detta steget så under­söker vi vad som krävs för att kunna bygga systemet, det görs innan vi börjar att planera mer i detalj. Ofta har kunden en idé om vad som ska göras i början, och vi hjälper dem att skapa kon­kreta förslag av deras idéer. En kund har ofta en idé som vi sedan bygger vidare på och sedan har vi täta av­stäm­ningar för att se att vi ligger i fas med kundens önske­mål. Alla projekt ändras från grund­idén. För helt nya större projekt så föreslår jag att vi börjar med en förstudie för att reda ut allt som behövs för bygga platt­formen.

Hur gör du om en kund har har många idéer om vad de vill uppnå?

– Då stoppar man dem. Det gäller att identi­fiera vad som verkligen krävs för att få lös­ningen att fungera. Man får se till att man inte bränner för mycket tid på saker som inte är nöd­vändiga för projektet. Ibland är våra kunder bra på att prio­ritera vad som behövs, ibland är de inte det. Det gäller att kate­gori­sera prio­riter­ingar så att det som är vikt­igast blir gjort först. Det är väldigt lätt rent intuitivt att bara göra det som kunden säger, och det går bra tills lanser­ingen och man får ny feed­back. Då finns det lite tid kvar och allt blir dyrare än be­räknat.

Vi har alla hört om IT-projekt som har gått åt skogen. Hur kan det hjälpa att jobba mer dyn­amiskt? Och hur kan man slippa att förlora tid och pengar?

– Ofta så verkar sådana projekt varit väldigt stela från början och ingen vågar testa några nya arbets­metoder, man har ett bestämt arbets­sätt från början.

– Typiskt är att man slutar lyssna på signaler, ifråga­sätter inte och lägger ingen energi på att analysera vad som händer. Någon kanske har mycket aggressioner inom sig och dom andra går åt sidan istället för att göra något åt problemet. För att leda IT-projekt på ett bra sätt så måste man våga ifråga­sätta problemen redan från början.

Har du några tips för att undvika problem?

– Man måste vilja framåt och våga pröva nya saker. Det låter klyschigt att våga ifråga­sätta, men jag tycker att jag ser en gemensam nämnare i stora projekt som går åt pipan – ofta har det funnits problem som alla vet om, men ingen vågar ta tag i.

– Jag har aldrig lett ett projekt som har gått riktigt dåligt, en nyckel till framgång är att säga till när något känns fel i hur vi jobbar ihop med våra partners. Det går inte att jobba efter helt orimliga krav och man måste säga till när något är fel. Oftast så brukar det vara något miss­förstånd som ligger till grund när man inte kommun­icerar bra. Det gäller att sätta sig in i hur våra olika världar fungerar. Jag är för en ‘why-culture’, och ifråga­sätter också varför jag själv gör det jag gör.

Hur jobbar du med krav­specifik­ationer?

– Att ha en bra krav­specifik­ation från start är en bra början. Det finns ingen människa eller team som klarar av att skriva en 20 sidor lång krav­specifik­ation som gäller under hela projektet, det är mycket som kommer att ändras. Krav­specifika­tionen är fröet och sen växer den vidare och blir något annat. Ibland så ändrar kunden sina planer och då är det bra att jobba dynamiskt och använda sig av flexibla och dynamiska tekniker och arbetsmetoder.

– Det måste också vara någon i projektet som har ett heli­kopter­per­spektiv. Det bästa är när kunder tar den rollen eftersom de oftast känner till hela visionen och bakgrunden. Detta brukar vi i projekt­lednings­världen kalla för ’product owner’, eller produkt­ägare på svenska.

Är disciplin viktigt för att kunna jobba bra och effektivt med IT-projekt? Man har ju mycket avstämningar och mycket ansvar ligger på de som jobbar i projektet – både person­ligt ansvar och person­ligt ledar­skap.

– Ja, det ställs höga kvar på de som leder ett projekt, och man måste vara själv­gående som projekt­medlem. Att bara ha ett möte för att man måste är inte bra för gruppen, och det är lätt att några zoomar ut för att mötet inte var nöd­vändigt just då.

– För att få projekt­lederiet att kännas mer levande så är det bra att ställa samma av­stämnings­frågor på ett inform­ellt sätt. I vissa fall så faller det sig naturligt att ha en förut­bestämt stand-up möte, i andra fall så är ett in­form­ellt möte lika bra. Det finns tre frågor att ställa. Vad har du gjort? Vad ska du göra idag? Har du några problem? Detta gör man för att alla ska ligga på samma våg­längd och komma framåt. Det gäller att stanna upp och se till att teamet går åt rätt håll. Det är ju inte meningen att man ska upptäcka att man ligger helt fel till efter att man jobbat till­sammans i 15 veckor.

Har du något boktips till de som vill utveckla sin programmering?

– Extreme programming, den är bra, kort och pedagogisk.

Vad använder du för hjälp­verktyg när du jobbar?

– Jag använder Jira på att hålla koll på vad som ska göras, lägger in alla user stories1 där och då vet man att man under utvecklingen får med allt som vi bestämt från början. Här planerar jag varje sprint2 och ser till att utvecklingen går som den ska.

– Toggl hjälper mig att hålla koll på tiden och vad jag jobbar med. På det sättet så har vi alltid koll på vad vi har gjort och lagt tid på. Jag tycker även att det är prof­ession­ellt att vi kan detalj­erat påvisa vad vi jobbat med varje minut.

*1 User stories är ett verktyg för att beskriva de uppgift­erna som man vill att ett system ska lösa. Har man jobbat igenom alla user stories väl så får man också in allt som behövs i systemet.

*2 En sprint är en arbets­cykel och en del av ett större projekt. Till exempel kan man jobba i en eller två veckors sprintar och då fördela de olika arbets­uppgifterna, bestämma när man ska ge feedback, hur man ska testa olika funktioner etc. under de veckorna. Under nästa sprint så arbetar man med nya uppgifter.

Vilka projekt har du jobbat med?

– Bland annat NameISP, Willhem, vidar­eutveck­lingen av Göteborgs Hamn och SpeedLedger.

Har du några tips till de som vill jobba med programmering?

– Var intress­erad och ambitiös, och skaffa dig bra grund­kunskaper.

Tack!

Sebastian har också tidigare föreläst om agil utveckling på nForum kallat ”Vi kör ju typ Scrum”.