Det finns ingen perfekt storlek för en feedbackloop

Ju mer jag skrev det här inlägget, desto mer kändes det som att jag borde skriva någon typ av TL;DR för vissa personer som läste detta. Så, i ett försök att spara tid, här är det:

Jag skriver det här för de som är nybörjare inom egenföretagare, projektledning eller generellt har mindre erfarenhet än de som frågar "Varför skriver du det här?" I slutändan är det något som de flesta av oss lär sig någon gång i det här. industrin, men om vi kan hjälpa varandra att korta vägen förr snarare än senare, gynnas vi alla.

Om du fortfarande är intresserad efter att ha läst anteckningen ovan, antar jag att du vill bli bättre på den här aspekten av kommunikation. Vilket är bra, för det är jag också 😏, och att använda en liten återkopplingsslinga är ett sätt på vilket jag har hittat att göra det.

---

Varje bransch har lite av sin egen jargong och många av oss skrattar åt det, men vi fortsätter alla att använda det i en professionell miljö. Vi är roliga på det sättet.

Hur som helst, i vår bransch är en av de fraser som vi använder mycket – inklusive mig själv – "feedback loop". Första gången jag någonsin stötte på frasen var med hänsyn till feedback från förstärkare. Det hade inget med mjukvara att göra. I det vi gör använder vi det i allmänhet för att referera till det som:

• skicka en förfrågan, kommentar eller allmän information till en kund,
• ta emot ett svar från kunden angående nämnda information.

Och för de som inte är vana vid idén (eftersom det finns de som gör ”big bang releaser" som jag ska prata om om en minut) brukar feedback loopar anses vara små eller stora.

Ju längre jag har arbetat med mjukvara, desto mer siktar jag alltid på En liten återkopplingsslinga oavsett vad.

Den perfekta återkopplingsslingan

En liten återkopplingsslinga innebär att det finns frekvent kommunikation mellan ett företag och kunden (så, naturligtvis, en stor återkopplingsslinga är när det finns mindre frekvent kommunikation).

Om du ska använda jargong, tänk åtminstone på det på något roligt sätt, eller hur?

Men du vet hela den där jargonggrejen som jag nämnde i början av artikeln? Vid normal omvandling skulle jag bara säga:

När det kommer till att arbeta med ett projekt föredrar jag mer frekvent kommunikation.

Och anledningen till att jag föredrar detta och till och med standard till detta är att när det gäller att bygga en lösning, oavsett storlek, för någon annan, finns det alltid rörliga delar att tänka på.

När det finns flera delar av ett projekt, finns det flera ställen där något kan behöva justeras eller ändras (eller som kan påverka det övergripande systemet) och att få det rätt tidigt snarare än senare sparar mycket tid (och därmed pengar) och stress för de flesta inblandade parter.

Än sen då?

Varför bry sig om att skriva om detta? För mig är anledningen för att ju längre jag driver en liten butik, desto mer hör jag från kunder om problemen som kommer med bristande tydlighet, kommunikation och projektledning i tidigare projekt.

Besvikelse. Jag vill inte köra den typen av operation. Så det är lätt att fixa, eller hur?

Dessutom är utvecklingsbranschen fylld av människor som kommer att ta kraven i ett projekt, anta att de förstår allt som behövs och sedan kommer tillbaka bara för att ha byggt något som inte bara missar målet utan bara ser ut ungefär som det kunden tänkt sig.

Detta är inte nödvändigtvis en knock på programmerare, men hela "[missar] målet" kan fixas om vi helt enkelt skulle kommunicera med dem vi arbetar med lite oftare än inte.

Anta inte att du vet vad de vill ha.

Ställ istället frågor, förtydliga kravet, arbeta med funktionen och presentera sedan för kunden i en iscensättningsmiljö. De kommer att veta om du har byggt vad de har bett om. Om så är fallet, gå vidare till nästa funktion. Om inte, finns det mer att göra. Att arbeta på detta sätt effektiviserar så mycket av de spänningspunkter som uppstår i projekt.

Och ja, att ställa många frågor kan bli tråkigt och till och med irriterande. Stor grej. Nämn redan från början att du kommer att ställa många frågor för att helt förstå problemet innan du försöker lösa det. Ge en anledning till varför du gör som du gör. Det brukar löna sig bra.

Big Bang Releases

Tidigare i inlägget nämner jag "big bang releases" och det här hänvisar generellt till idén om att en kund förser dig med krav, att du återgår till att arbeta med det i veckor i taget och sedan dyker upp igen och säger "Hej, jag jag är klar – ta en titt!” bara för att få reda på att det är långt borta.

Om jag skulle kontextualisera detta inom en typ av feedbackloop skulle jag säga att det inte finns någon. Den är inte ens stor eftersom ingen feedback begärdes. Det är helt enkelt:

• Här är kraven för projektet,
• Jag är klar med projektet.

Ofta leder detta till att utvecklare missförstår kraven, att kunder är i mörker om framsteg och att det övergripande projektet går söderut. Enkelt uttryckt, gör inte på det här sättet.

Den perfekta storleken?

Jag vet inte vad den perfekta storleken på en feedbackloop är. Det finns några kunder som jag har arbetat med där det är dagliga incheckningar, det finns någonstans där det är veckoincheckningar och det finns några som har sagt "bara slutför detta och låt mig veta när du är klar."

Veckovisa incheckningar, commits, releaser, etc. brukar vara min favorit men det beror på projektets storlek och storleken på teamet som jag arbetar med. Dagligen är inte heller dåligt beroende på uppgiften.

Jag gör aldrig big bang-stilen även om en kund säger att det är okej. Jag gillar fortfarande att ha kontrollpunkter för mitt eget förstånd. Så vilken typ av feedbackslinga som än fungerar bäst för dig, ditt team och din kund kommer att ha den perfekta storleken.