Så engagerar du ditt utvecklingsteam

En av de saker jag gillar mest med Zooma är att vi alltid strävar efter att göra allt vi gör ännu bättre genom att ta till oss de viktigaste lärdomarna från varje projekt. Det är naturligtvis en process som aldrig tar slut. Om jag hade skrivit den här texten för några år sedan, i ett annat sammanhang, skulle den ha låtit mycket annorlunda än vad den gör nu. Men även när saker och ting är bra finns det alltid utrymme för förbättringar. I den här artikeln kommer jag att fokusera på tre saker som alltid är viktiga att inte underskatta eller ta för givet när man involverar en utvecklare (eller någon annan mänsklig resurs) i ett projekt.

Jag tänker ofta på projektförbättringar för att leverera bästa möjliga, stabila, säkra och användarvänliga projekt. Jag gillar också att vara en del av leveransen, inte bara ansvarig för en isolerad del. Det är alltid ett kontinuerligt arbete att förbättra och hålla sig på topp, så ett projekt bör aldrig förlita sig för mycket på det tidigare sättet. I stället bör vi alltid ta in och använda lärdomarna från varje tidigare projekt. För att utvecklas måste man vara uppmärksam och ständigt ifrågasätta saker och ting.

Vad är en idealisk utvecklingsprocess? Tja, den ser ut så här.

Den idealiska utvecklingsprocessen

1. Briefing om hela projektets omfattning
   1. Separat genomgång av utvecklingsdelen
2. Brainstorming
   1. Samråd med andra utvecklare
   2. Dela upp projektet i delar och besluta om bästa tillvägagångssätt för att lösa funktionaliteten.
3. Uppskatta den tid som behövs för genomförandet.
4. Upprätta en tidsplan för utvecklingen.
5. Utveckling
   1. Regelbundna kodgranskningar
6. Testning/kvalitetssäkring
7. Korrigering av buggar/fel + omarbetning av koden.
8. Lansering
9. Korrigeringar efter lanseringen

Även om vi redan följer en stor del av denna struktur i dag finns det alltid saker som tenderar att få mindre uppmärksamhet. Särskilt om något plötsligt kräver att saker och ting ska ske snabbare än vad som ursprungligen var planerat. Därför vill jag lyfta fram tre avgörande saker som måste ingå i alla projekt för att ha ett gemensamt tankesätt, mål och arbetssätt för att uppnå det förväntade resultatet.

Kommunikation

Den första och viktigaste saken är tydlig kommunikation under hela projektet. Man kan aldrig sluta arbeta med att förbättra sina kommunikationskanaler och färdigheter, inte bara i projekt utan även i vardagen. Det gäller alla i ett team, men för en utvecklare är det avgörande hur projektledaren håller kommunikationen och engagemanget hos alla teammedlemmar på topp. Det är lätt att betydelser försvinner i en kedja av samtal, vilket gör det extra svårt att få en fullständig bild om man ska kliva in i produktionen i ett senare skede av tidslinjen, vilket en utvecklare ofta gör.

Chefer och utvecklare närmar sig naturligtvis sina projekt och utmaningar utifrån sina roller i företaget, så det finns ofta olika perspektiv på vad som bör komma först och vad som är viktigast. Därför är det viktigt med ömsesidig förståelse. Det måste finnas en överenskommelse om prioriteringarna av planering, budget och mål samt de utmaningar som uppstår inom cykeln för att utveckla ny funktionalitet. Att skriva kod är till exempel en uppgift som ständigt utvecklas, och det som var teknisk bästa praxis i det senaste projektet kanske inte är relevant i nästa projekt. Det innebär att utvecklare vanligtvis behöver tid för att tänka och hitta på nya lösningar som kanske inte har gjorts tidigare, så det bör finnas utrymme för flexibilitet i planen.

Ett bra projektledningsverktyg är också viktigt. Jag tror att alla på Zooma skulle hålla med om det, och jag skulle bara kunna arbeta med ett. Det spelar ingen roll vilket verktyg det är för mig; jag är nöjd så länge jag vet var jag kan hitta mina uppgifter och var all information lagras. Jag arbetar vanligtvis med flera projekt under veckan, så jag måste veta var jag kan hitta mina prioriteringar. Helst skulle det vara bra att ha "ett verktyg/en app som styr alla", men det är bara ibland möjligt, så det är viktigt att definiera och kommunicera hur man arbetar med ett visst projekt, vilket verktyg som används och hur.

Engagemang

En utvecklare vill vara delaktig från början. Vi vill veta vad som händer, hela omfattningen och orsakerna bakom planeringen, även om vi inte planeras göra något förrän senare aktivt. Naturligtvis hjälper detta oss när vi ska planera våra to-do's inom projektet. Men det bidrar också till att vi känner oss delaktiga och delaktiga i helheten, och inte bara skriver kod. 

Jag kan till exempel få en briefing om att jag förväntas bygga en butiksfunktionalitet. Men kanske är den butiken en del av ett helt nytt webbprojekt. Då bör briefingen innehålla information om både butiksdelen och resten av webbprojektet (även om jag fortfarande bara bygger butiksdelen). När du utvecklar butiken vill du ha hela dokumentationen, eftersom ditt sätt att lösa olika funktioner kommer att påverka de alternativ som du kan överväga i ljuset av hela omfattningen. För att utvärdera och hitta den bästa lösningen måste du veta hur och var den kommer att användas. När utvecklarna inte är helt medvetna om förväntningarna på projektet kanske de gör saker och ting på ett visst sätt, vilket kan försvåra till exempel senare uppgraderingar av tjänster. Det är till stor hjälp när vi kan tänka igenom saker och ting i förväg - innan något kommer tillbaka senare.

Stöd

En sak som många utvecklare (och kreatörer i allmänhet) verkar ha gemensamt är bedragarsyndromet. Särskilt när det finns många olika sätt att lösa vissa problem, det är inte något jag hittat på, utan det kan ibland vara bra. Detta är när man känner att man gör sitt arbete baserat på tur och att saker och ting fungerar av en slump. Detta är naturligtvis inte sant, men många människor tänker så, och i sådana situationer kan projektledaren hjälpa till genom att se till att projektet löper som ett lagarbete. Vi gör allting tillsammans, även om vi alla har individuella ansvarsområden.

Arbetssätt

En annan sak där planering och utveckling ofta måste kompromissa är när det gäller arbetssättet. Om jag är generalist tenderar utvecklare att luta sig mer mot den agila metoden, medan projektledningen ser mer på det utifrån en vattenfallsmetod. I dessa fall krävs det en hybridprocess, "agil-vattenfall", där båda metoderna kombineras om vi vill hitta ett smidigt upplägg som fungerar för alla med det bästa resultatet för kunden.

Möten

En utvecklare har inget emot möten. Inte riktigt. Vi säger att vi gör det för att göra det svårare för ledningsgruppen. Skämt åsido, möten är rimliga och nödvändiga, men det kan vara bättre när de är färre. Och särskilt om de sker hela tiden. Det bryter det kreativa flödet om vi ständigt måste pausa för olika projektmöten. Så när det är möjligt är det värt mycket för produktiviteten om mötena kan vara välplanerade och hållas vid färre tillfällen.

Process

Utvecklingsprocessen skulle vara ständigt pågående, iterativ och innovativ i ett drömscenario. Endast vissa saker måste definieras i detalj i förväg. För att få acceptans måste du ha en begränsad omfattning, tidsplan och budget för varje projekt. Men om vi kan behålla ett utrymme för flexibilitet där man kan testa olika lösningar och väga dem mot varandra skulle alla tjäna på det. I det här fallet är det också så att en hybridmetod bäst uppfyller alla krav och förväntningar på resultatet.

Organisation

Det handlar inte bara om ett specifikt projekt och planeringen och genomförandet av det. Det handlar också om organisationen. Organisationens kultur och regler sätter ramarna för hur alla agerar. Det handlar alltså inte bara om att lösa praktiska, projektrelaterade uppgifter. En helhetssyn som tar hänsyn till fler kulturella parametrar i ett projekt skapar en utmärkt arbetsmiljö som gör det lättare att vara en kugge i maskineriet. 

Förväntningar

Det som vanligtvis stressar en utvecklare mest är när hen ombeds göra en uppskattning. Vi vill fastställa fasta leveransdatum och ha så exakta uppskattningar som möjligt, precis som alla andra. Men det kan ofta vara så att förväntningarna är ganska strikta. När man väl har gjort en uppskattning måste man hålla sig till den, och den uppskattningen följer en omedvetet, vilket ökar stressnivån. Chefer, sponsorer och kunden vill alla ha ett åtagande om tid och budget, vilket är naturligt. Men detta bygger alltid på antaganden, och antaganden kan ändras. Ibland är uppskattningen korrekt, och ibland måste den korrigeras med avseende på leveranstid eller kvalitet. Förväntningarna måste vara tydliga och kommuniceras för att undvika osäkerhet och missförstånd om varför saker händer och vilka åtgärder som kommer att vidtas om de inträffar.

Många kreatörer föredrar att inte ge en uppskattning, även om det bara är en begäran om en grov uppskattning till en början. Detta kräver den förståelse som redan finns med under rubriken kommunikation. Den nödvändiga uppskattningen innebär ofta antaganden som bygger på nya eller oprövade egenskaper och funktioner, och det är inte lätt att säga exakt hur något kommer att bete sig förrän man har byggt det. Men det skulle innebära att man redan är långt in i projektet, så man befinner sig i den klassiska Catch-22-situationen. Förväntningarna på uppskattningar och leveranser måste förstås av alla parter, och de måste vara rimliga. När projektet väl är igång måste kommunikationen vara tydlig fram till slutet. På så sätt kan vi undvika fallgropar och oönskade överraskningar eller åtminstone ta upp dem i tid för att hitta en lämplig lösning för att åtgärda dem. Dessutom är uppskattningarna ofta bra för att hålla dig fokuserad på arbetet, så flexibilitet är viktigt.

När det gäller förväntningar får vissa återkommande uppgifter ofta en lägre prioritet i en projektplan. En sådan sak är kodrefaktorisering. Det är lätt att kategorisera sådana uppgifter som nice-to-haves i stället för must-haves eftersom man förväntar sig att allt redan är gjort optimalt. Vilket det förhoppningsvis är. Men man hittar alltid saker att rensa ut eller anpassa när man väl är i slutet av ett projekt som man inte insåg eller var medveten om i början. Och då bör det finnas utrymme för att ta hand om dessa saker, inte för att lämna det som det är och hoppas på det bästa. 

Ett bra citat av Addy Osmani täcker in denna essens i bara tre steg:

Gör det först. Gör det sedan på rätt sätt. Gör det sedan bättre.

Så närhelst det är möjligt - tillämpa denna trestegsprocess för flexibilitet och optimering. Det kommer att göra mycket nytta att förfina resultatet.

För allt som anges ovan handlar det om att hitta balansen i varje projekt och låta alla få en chans att tala utifrån sitt perspektiv. Som ett resultat får du ett positivt och engagerat team som skapar lysande resultat.

Se till att prenumerera på Onlineguiden, så får du ett mejl när vi publicerar nya artiklar.

Denna artikel publicerades först på The Onlinification Hub - du kan läsa den på engelska här.