Objektorienterad programmering i WordPress: Förstå kundernas förväntningar
När vi fortsätter att diskutera objektorienterad programmering i WordPress, är det viktigt att vi ser till att vi inte hoppar före oss själva när det gäller att bygga en produkt för någon annan.
Så ofta är det lätt att:
- hör vad en kund säger,
- bygga ut något baserat på vad vi har hört,
- lämna över det till nämnda kund.
Men det är så mycket mer än så. Jag har dansat runt det lite i tidigare inlägg i den här serien; men jag vill börja gå in på vad det innebär att höra:
- Vad en kund säger,
- Utveckla en uppsättning krav,
- Och skapa sedan feedback-loopar kring det.
I slutändan vill vi se till att de människor som vi arbetar för och lösningarna som vi bygger verkligen är lösningar och inte hinder eller hinder som de måste hoppa över.
Dessutom tror jag inte att det räcker med att en kund helt enkelt njuter av upplevelsen av sin slutprodukt, utan med att arbeta med den (eller de) som bygger lösningen också.
Med det sagt, låt oss ta en titt på vad det innebär att lyssna på vad de säger och gå därifrån.
Förstå kundernas förväntningar
När du läser böcker eller annat material kring den här typen av grejer, gör det ofta en av två av parterna till "bad guy". Inte alltid, men ibland gör det:
- kunden verkar okunnig om vad de pratar om,
- eller så får utvecklaren att verka som en idiot för att agera som någon som vet mer om det aktuella ämnet.
Vad sägs om ett tredje alternativ där kunden har en klar uppfattning om vad de vill ha, utvecklaren/utvecklarna är villiga att lyssna och arbeta tillsammans med kunden för att bygga något?
Visst, det kommer att bli ett förtydligande längs vägen, och det kommer att finnas termer som måste definieras, och någon "omkalibrering" av utvecklingskalendern kan till och med vara en del av den.
Men slutsatsen är denna: ingendera parten bör motarbeta den andra. Istället handlar det om att arbeta tillsammans för lösningen. Visst, det kräver kommunikation (vilket utvecklare inte alltid är bra på, enligt min erfarenhet, men det finns ingen anledning till att det inte kan bli bättre).
Vad säger en kund? (Vad säger utvecklaren?)
När ni träffas tänker ni troligen samma sak eftersom ni talar olika språk och var och en av er tycker att det som den andra säger är jargong.
Och det är inte fel.
Kunder har ett sätt att prata om vad de vill ha, och utvecklare har ett sätt att prata om hur de ska leverera.
Villkoren vi använder
Men det kan finnas ett gemensamt mål.
Sikta på en beskrivning av problemet som försöker lösas. Försök att göra det i lekmannatermer så att designen stämmer överens med lösningens mål och och funktionalitet.
Jag tror inte om detta kommer att fungera för alla, men det här är det första jag rekommenderar att du gör när du sitter ner med din klient.
Som du kommer att se senare i de här inläggen hjälper det att utveckla några meningar som du kan använda i början av din arbetsbeskrivning som du kan hänvisa tillbaka till varje gång du har ett beslut att fatta.
Med andra ord kan du (och de) fråga:
Bidrar det jag arbetar med till det gemensamma målet?
Och det är här du kan bestämma kärnkraven.
"Det måste…"
När det gäller att köpa något, bygga något, begära något, vilja ha något eller vad som helst, är det ganska lätt att börja meningen med att säga "Jag vill att det ska…"
Men det är stor skillnad mellan "jag vill att den ska göra [göra något]" och "jag behöver den [för att göra något]", och när du arbetar med mjukvara är det i allmänhet säkert att säga att de saker som behövs är kärnan till ansökan. Och de saker som önskas är det som kommer efter att grunden till applikationen har byggts.
Det vill säga, det är en konversation om "måste-ha" och "vill-ha". Och det är viktigt att ha konversationer så att du kan komma fram till den slutliga redogörelsen för det gemensamma målet med ansökan.
När det är på plats kan du börja och sedan planera din programvara kring kundens problem. Och det är där kravsamlingen spelar in.
Utveckla krav
Vad du och kunden har en gedigen förståelse för vad som behöver byggas, då är det dags att sätta ihop krav.
Den här delen kan vara roligare än den låter. Jag vet, jag vet: Det låter som läxor eller någon uppgift, eller hur? Men det är inte. Istället är det att ta vad de vill ha, vad du har förstått, översätta det till ett gemensamt språk och sedan skriva ett dokument som förklarar vad programvaran kommer att göra.
Beroende på din erfarenhet kan detta dock vara tråkigt. Och med tråkigt menar jag en av de värsta delarna av ditt jobb. Dessutom förändras kraven alltid, eller hur?
Inte alltid.
Om du tar dig tid att förstå vad de vill från början, så behöver inte kraven vara ett 50-sidigt dokument som beskriver hur varje enskild modul måste fungera.
Många böcker dokumenterar det som att det är så här det måste vara. Men under nästan ett decennium av att göra det här har jag aldrig haft något så långt och kunderna har i allmänhet varit otroligt tacksamma över att se en kort lista som kan ändras via e-post eller Google Dokument, undertecknas och sedan kallas projektet flyttar fram.
Jag kommer att prata mer om det i framtiden, men vilken dålig erfarenhet du än har, är du rädd eller bävan du har behöver inte sitta. Och det kommer vi att fortsätta prata om genom den här serien.