Fram till förra året är ett av sätten som jag har nått milstolpar mycket baserat på perspektivet på hur jag eller mitt team och jag skulle arbeta med projektet.
Det finns dock ett problem med detta tillvägagångssätt: För de av oss som försöker inkludera kundfeedback under hela utvecklingsprocessen, är det inte lika lätt för dem att ta den jargong vi använder och ändå få dem att förstå det.
För det ändamålet har jag börjat omfånga WordPress-projektmilstolpar lite annorlunda så att de är lite mer kundvänliga samtidigt som de ger mening för hur ett team av utvecklare kan åstadkomma det som är nödvändigt för att se till att saker och ting fungerar.
WordPress-projektets milstolpar
Tänk ett ögonblick på förra gången du var ansvarig för att bygga ett anpassat plugin eller integrera anpassad funktionalitet i ett WordPress-projekt. Kanske innehöll det något i stil med:
- Importera data till WordPress-databasen,
- Gör informationen synlig och redigerbar från administrationsområdet för WordPress,
- Visa informationen på gränssnittet och på ett sätt som kan sorteras efter till exempel kolumnvärden,
- Uppgifterna kan uppdateras via annan import eller hanteras från administrationsområdet,
- Och kanske några andra relaterade funktioner.
Om du ska dela upp detta i utvecklarspråk, kommer du att prata mycket om vissa saker angående import, dataanalys, dataintegritet och så vidare. Och allt detta är 100% korrekt, och allt det är så det borde vara från en utvecklares synvinkel.
Men om du använder programvara för projektledning (som vi har fastställt på Asana på senare tid), kommer dessa typer av milstolpar inte att hjälpa när du tar med användare i projektet.
- Hur ska de veta något om detaljerna i en importprocess?
- Hur ska de förstå det tekniska med att göra något sorterbart?
- Finns det något sätt att enkelt beskriva en algoritm för dem som till och med spelar roll?
Jag skulle säga nej. Så hur kan vi göra WordPress-projektmilstolpar mer tillgängliga? Jag vet inte om mitt svar är ett gediget svar, men det är något vi har försökt och något som verkar fungera relativt bra, men det är enkelt:
- Kunder tänker ofta på sina projekt angående sidor (eller något relaterat),
- Eftersom vi som utvecklare kan arbeta inom det sammanhanget kan vi definiera ett offentligt projekt för att bryta ner uppgifter sida för sida.
Således blir WordPress-projektets milstolpar mer om uppgifterna per sida och de återstående uppgifterna i en mer "allmän" milstolpe.
Ett ord om tekniska aspekter
Allt som nämnts ovan fungerar bra när du har kunden med i vissa delar av projektet, men det lämnar fortfarande frågan om "Vad gör vi med de mer tekniska aspekterna?"
Och genom det kan det vara allt från hur du ska organisera dina gränssnitt, klasser, metoder och så vidare till hur du ska implementera en viss algoritm. Oavsett, poängen är att det finns en djupare teknisk diskussion som måste föras. Så vad gör vi med dem när vi diskuterar WordPress-projektmilstolpar?
Det finns flera alternativ:
- Ställ in en separat milstolpe, grupp av uppgifter, projekt, diskussion, vad ditt system än tillåter, och håll det mellan dig och ditt team.
- Utnyttja GitHub-problem, GitHub-projekt, en wiki, Trello eller något annat system,
- Behåll informationen i en annan applikation som är tillgänglig för alla utvecklare men isolerad från kunden.
Visst, det skapar lite mer overhead, men jag har upptäckt att ju mer information du har spridit över delar av ditt projekt, desto mer framgångsrikt kan ett projekt bli.
När information utelämnas, sprids, inte delas eller inte detaljerad, blir det svårare att hantera den ju längre projektet går, särskilt under framtida iterationer.
Summan av kardemumman är att jag tycker att det är viktigt att bryta ned WordPress-projektmilstolpar i delar där kunden enkelt förstår vilket arbete som görs och att du och ditt team har ett sätt att hantera det som görs.
Hur du gör det är självklart upp till dig, men det är något som jag har tyckt vara väl värt tiden att installera.