Project Guardrails: Design By Committee
När du anlitas för att bygga en lösning för andra – främst på webben eftersom det är det område jag jobbar inom – tror jag att det finns ett antal faktorer som är viktiga för ett projekt :
- Det bör inte finnas någon "design av kommitté".
- Ingen annan som kärnutvecklingsteamet ska kunna tillhandahålla utveckling, iscensättning och produktion.
- Ingen ska kunna skriva till produktionen förutom utvecklingsteamet (och även då borde det finnas en distributionsprocess).
Jag är alltid tveksam till att göra sådana här uttalanden eftersom de framstår som dogmatiska, men jag tycker att ju längre jag jobbar i den här branschen, desto mer tycker jag att dessa tre regler är viktiga.
Eller så är de egentligen bara riktlinjer. Det är trots allt skott som kallas innan vi faktiskt får saker gjorda.
Oavsett om de är mer förslag eller regler spelar egentligen ingen roll. Det finns anledningar till att vi alla kommer fram till de slutsatser som vi gör, eller hur? Och så under de kommande inläggen (istället för ett långt inlägg) ska jag dela med mig av anledningarna till att jag har tyckt att dessa tre regler är viktiga.
Design av kommitté
När jag använder den här termen menar jag inte att en enda person ska vara ansvarig för att utforma en webbplats. Jag menar bara att en byrå eller en grupp av dem som fokuserar på design ska stå för det.
Design av kommitté är en nedsättande term för ett projekt som har många designers inblandade men ingen enande plan eller vision.
Så en "kommitté" i det här fallet är när en grupp människor, eller kunderna eller de som är relaterade till kunder till viss kapacitet, kommer för att se resultatet av implementeringen (eller till och med bara designen), e-posta förslag på vad de skulle gillar att se och förväntar sig att det ska hända.
Det vill säga expertis om en given designer offras för en annan grupps åsikter .
Prinsessan Leia var inte en kommitté.
Och, kanske i extrema fall (även om jag aldrig har upplevt detta personligen), använd betalning som hävstång för att få sin vilja igenom.
Saken är den att de som anlitas för att designa lösningen åt kunden ska som sagt vara experter på området. De förstår typografi, färger, skärmupplösningar, tillgänglighet och så vidare.
Att lämna dem till sitt expertområde är alltid en bra idé.
Ta hand om projektet
Inget av detta har att göra med att någon har mer kontroll över projektet än någon annan.
Det handlar om att se till att alla projektets intressenter arbetar i samverkan med varandra och inte korsar ansvarsområden. (Föreställ dig, säg, de GIF-filer som skulle användas för reklam om utvecklare var ansvariga för reklam. 😏)
Summan av kardemumman är att ett framgångsrikt projekt är just det när alla stannar i sitt hörn och arbetar tillsammans inom sitt eget kompetensområde.
Annars slutar du med att saker faller ur synk och skapar i princip fler problem när det inte fanns några (nåja, åtminstone i ett visst område) att börja med.
Vad kommer härnäst?
I nästa inlägg kommer jag att täcka idén om att tillhandahålla miljöer, vad detta betyder och hur det spelar in i den övergripande rollen för projektledning. Men det ska jag gå mer in på i inlägget.
Ytterst handlar det om att se till vem som har läs- och skrivåtkomst till de olika områden där applikationen eller projektet kan användas. Visst, för vissa som läser detta kan det här kännas lite som "nybörjarinnehåll" eller inte alls som "utvecklingsrelaterat innehåll".
Men om du arbetar med andra för att bygga en lösning, då är det här saker du sannolikt kommer att stöta på och det är lättare att ha en plan baserad på de misstag andra har gjort (nämligen jag 🙂) än att lära dig saker den svåra vägen.