Category Archives: Utveckling

DrupalCamp 2013

Har parkerat i soffan efter hel dag på DrupalCamp. Det var riktigt bra ordnat i år och en skara på 300 pers som nördade ner sig i Drupal. Själv deltog jag i en paneldebatt på slutet som blev rätt lyckad. Vi pratade om Drupal 8, vad som kommer och vad vi hoppas på.

#042

En sådan där dag

Det har varit en sådan där dag. En dag när man fastnar på ett problem och bara inte kommer ur det. Jag har fortfarande inte löst det, men nu har jag en plan i alla fall och i morgon kommer jag att vinna. Och när jag väl gör det kommer jag att få den härliga känslan av att ha överkommit ett stort hinder, den förlösande känslan som är en av anledningarna till att jag älskar att vara utvecklare.

#009

Gör tekniken till din bitch, inte tvärtom

Teknik är till för att användas i människans tjänst. På stenåldern hade de flinta, nu har vi laptops. Våra datorer och telefoner är verktyg som är till för att göra livet lättare för oss, inte hindra oss i vardagen.

Du kanske inte tycker att det är lite läskigt med teknik, men du kanske känner någon som “inte vill bli lurad” och därför väljer att gå till resebyrån istället för att leta upp billigaste flygstolen på nätet. So be it. Vill du hellre trängas på ett bankkontor runt lunchtid än betala dina räkningar på nätet så för all del, gör det.

Men tro inte att du inte kan. Webbsidor och mjukvara är inget att vara rädd för. Om de inte fungerar så är det fel på dem, inte på dig. Webbsidan ska anpassa sig efter vad du vill ha, inte tvinga dig att lista ut hur den fungerar. Om du någonsin behöver säga till en kund eller besökare att “systemet låter mig inte göra det”, så ta dig en lång funderare kring huruvida det inte är dags att ändra på systemet.

Lär dig prata med dina techies

På sommarens SSWC höll jag en session om hur man pratar med techies (8 tips om hur man kommunicerar krav till utvecklare). Ämnet låter kanske en smula banalt men kommunikation är nyckeln till framgång i utvecklingsprojekt och den viktigaste överföringen av kunskap är mellan kund/designer och utvecklare.

Innan konferensen frågade jag deltagarna på Facebook ifall det fanns intresse för ämnet. Jag fick mycket feedback och en hel del kommentarer om skisser och metoder. Men det var egentligen inte det perspektivet jag tänkte ha. Jag tror inte att mediet är det viktiga, dvs om man beskriver det man vill uppnå med skisser eller text eller diagram eller origami. Det är andra saker som är viktiga, som vad du har för attityd och på vilket sätt du väljer att engagera personerna i ditt team.

1. Försök inte prata med tekniker på teknikers vis.

En vän till mig, som också är utvecklare, träffade en av sina kunder på DrupalCamp i våras. Hon frågade honom vad han förväntade sig att få ut av konferensen. I sitt jobb som beställare ville han ha bättre koll på tekniken, för att kunna kommunicera bättre med utvecklare. Men faktum är att de sämsta beställarna är de som försöker prata med tekniker på teknikers vis. När du använder ord och formuleringar som du inte riktigt behärskar så blir det lätt rappakalja till slut. Ansträng dig istället för att bli bra på att kommunicera på ett sätt som du är van vid, och att kunna formulera det du vill uppnå med dina egna ord. Är du bra på att uttrycka dig i text, skriv, är du bra på att göra skisser, rita. Gör det som funkar för dig och ditt team.

2. Låt utvecklaren vara med tidigt i projektet.

Jag har varit på en mängd långa kickoff-möten i början av utvecklingsfasen för projekt. På bara några timmar så ska interaktionsdesigners, grafiker och projektledare försöka överföra all den kunskap som det har tagit dem flera månader att förskansa sig. Jag är smart och jag är en bra utvecklare, men det är inte rimligt att jag ska kunna suga åt mig allt jag behöver veta på en dag. Halva teamet har funderat och diskuterat med och utan kunden och fått en djup förståelse för vad målet är med projektet. Det kan inte ersättas med ett par personas eller en skiss för att resten av teamet ska få samma förståelse.

Om du vill att utvecklaren ska kunna känna engagemang och bidra till att gå mot samma mål som du så måste hon också får en chans att se och fundera över samma problem som du, att själv få höra kunden prata om vilka hinder som finns idag. Kreativa lösningar på problem måste få mogna fram. Ha täta avstämningar med utvecklaren när konceptet formas, bjud in till workshops och kundmöten. Den tid du gör av med på att ha en utvecklare i projektet några timmar i veckan redan i början, kommer du att få igen många gånger om, jag lovar.

3. Var tydlig och använd konkreta exempel.

Att vara tydlig innebär inte att du ska förklara alla krav in i minsta detalj, utan att du inte ska utelämna delar som du själv kanske tycker är självklara. Förutsätt inte att ni har samma bild av hur en funktion ska bete sig eller vilka steg som finns i ett flöde. Lägg fram all information om hur du vill att något ska fungera och dina preferenser, speciellt om du i förväg vill ha en uppskattning om hur lång tid något kommer att ta att bygga.

Ibland kanske du inte vet exakt vad det är du vill ha, inte förrän du ser resultatet och inser att det inte var det du trodde i alla fall. Var öppen med det i så fall och säg att du inte är helt säker och att du gärna vill prova dig fram. Men var då också medveten om att det inte är rimligt att be om noggranna tidsuppskattningar eller kostnadsförslag i dessa fall.

Det allra bästa är att hitta ett konkret exempel på det du vill ha. Det är lätt för alla inblandade att snabbt förstå vad målet är och att ställa frågor om anpassningar. Ett exempel måste dock kunna stå i proportion till din produkt. Ett dåligt exempel är att säga “Jag vill att det ska fungera ungefär som Facebook”. Ett bra exempel är: “Jag vill att inloggningen ska fungera som på Twitter, d.v.s att det åker ner en liten ruta som man loggar in i och sedan är man kvar på samma sida som innan, men man har flera val än när man inte är inloggad”.

4. Som man frågar får man svar

Har du någon gång bett en utvecklare om ett svar på hur lång tid det tar att bygga en funktion och fått till svar “Hur långt är ett snöre?” Det är ett ganska omoget svar, men det ligger något i det. Jag har själv använt det, det var ganska många år sedan nu, men jag tyckte jag var otroligt fyndig när jag sa det. Det kan verkligen vara svårt att svara på sådana frågor och det man som utvecklare är rädd för är ju att gissa fel och få skulden för att projektet inte höll deadline.

Du kan alltid kräva att få ett estimat av en utvecklare, men du kan inte kräva att estimatet håller ifall förutsättningarna ändras eller kraven är vaga och otydliga. Om du undrar hur mycket det kostar att bygga en webbplats så kan jag sanningsenligt säga att det kostar mellan 20 000 och 2 miljoner, men om du frågar hur lång tid det tar att bygga en webbplats baserad på Drupal som presenterar produkter så kan jag säga att det tar 2-3 månader. Ju mer information du ger mig desto bättre kan jag gissa.

5. Dela upp och prioritera funktioner

Se till att utvecklaren vet vilka funktioner som är viktiga och vilka som bara är nice to have redan från början, så att hon bygger funktionerna i rätt ordning. Ha en genomtänkt prioritet på uppgifterna och bolla gärna det med utvecklaren så att du inte sätter hög prioritet på något som är beroende av en funktion som du prioriterar lägre. Tänk också på att du kan dela upp själva funktionerna i en enklare version och en mer avancerad. På det sättet kan du få ut flera funktioner i första releasen, som du sedan bygger ut och gör bättre och bättre.

6. Undvik viskningsleken

Låt säga att kunden vänder sig till dig som projektledare, och beställer en funktion. Du upprepar vad kunden har sagt till utvecklaren, men glömmer någon detalj. Utvecklaren, som i sin tur kommer att tolka det du säger utifrån sina erfarenheter, ställer en motfråga, som du upprepar till kunden, utan att egentligen veta exakt vad frågan innebär. Kunden förstår inte heller utan ber dig förklara. Du vill inte avslöja att du är osäker utan svarar något som verkar rimligt och vips så har det enkla kontaktformuläret blivit en FAQ.

Ta bort onödiga steg i kommunikationsprocessen. Om du är projektledare i ett större team, låt utvecklaren prata direkt med kunden när kraven ska kommuniceras. Mellan en kund och ett team är det självklart nödvändigt att ha en point of contact så att inte olika krav hamnar hos olika personer, men när en beställning ska detaljeras och börja byggas så bör den som vet vad målet är prata direkt med den som ska uppfylla det.

7. Använd verktyg och metoder

Jag är en stor fan av scrum men jag är inte scrum-fascist. Jag håller inte med om att det är allt eller inget, att man måste följa alla regler inom metoden eller så kan man lika gärna strunta i det. Plocka russinen ur kakan och använd det som funkar för ditt team. Daily stand-ups och demos är ett utmärkt sätt att se hur kraven blir verklighet och ger dig utrymme för att göra förändringar om det visar sig att projektet är på väg åt fel håll.

8. Var inte hemlig

Scrum-möten är inte bara till för att utvecklarna ska berätta om sina resultat och problem, utan det är ett tillfälle för alla i teamet att prata om vad som pågår i deras del av projektet. Om du är interaktionsdesigner och har kört fast, berätta om det så att du kan få input från alla i teamet. Om du sitter som projektledare, var inte rädd för att prata om hur det ligger till med budget och deadline, eller om du har haft ett samtal med kunden om något som påverkar resten av projektet. Då får utvecklarna en chans att justera hur kommande uppgifter prioriteras så att det passar in i planen.

Ode till kodning eller Min relation till programmering

Jag är tacksam för att jag får jobba med något jag älskar. Men ibland hatar jag det. Jag hatade det i lördags när solen sken över ett snövitt Stockholm och varenda kotte var ute på långa promenader runt Södermalm. Bland andra min sambo, som kom hem med kameran full av vackra vinterbilder. Istället satt jag en hel dag och försökte installera Django och alla dess tillbehör på min mac. Det gick ganska bra tills jag kom till steget att installera bryggan mellan Python och MySQL. Hej då, resten av dagen.

Jag har aldrig tagit droger. När jag blir gammal och skröplig tänker jag bosätta mig i en bungalow på någon strand och röka gräs resten av livet, men just nu behöver jag min hjärna. Det närmsta jag kan komma ett drogliknande begär är att inte kunna lämna ett tekniskt problem olöst. Det går bara inte, oavsett hur vackert vädret är eller vad jag egentligen hade tänkt göra den dagen. Och då hatar jag det. Men morgonen efter så upptäcker jag att det finns ett extra ‘/’ i en konfigureringsfil och när jag tar bort det så fungerar hela kedjan. Och då älskar jag det igen! Hurra! Uppfylld av segerkänslor, lycka och tillfredsställelse och It’s good to be the Queen!

Att kämpa med ett problem av det här slaget är lite som att bråka med sin käraste. Det börjar som en irritation, växer till ett uppblåst gräl och slutar i att man inser att det man bråkar om är ganska fånigt och så går det över och man är kär igen.

Om jag inte jobbade som utvecklare så skulle jag vilja vara trädgårdsmästare eller snickare. Jag har känt så länge men kunde inte riktigt förklara dragningen innan jag insåg att det jag gör nu är ett hantverk. På samma sätt som att plantera ett frö och se det växa till en blomma, eller att börja med en hög plank och skapa ett vackert bord, så börjar jag med blanka filer som jag fyller med ord och tecken för att skapa en webbplats. Att börja med ingenting och skapa något som ger glädje eller nytta till någon annan är givande. Och att kunna peka på något och säga “Det där har jag gjort” är väldigt tillfredsställande.