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.
