Progetto Guardrails: Design By Committee
Quando ti viene chiesto di costruire una soluzione per gli altri, principalmente sul web poiché è l’area in cui lavoro, penso che ci siano una serie di fattori importanti per un progetto :
- Non dovrebbe esserci alcun "design by comitato".
- Nessun altro che il team di sviluppo principale dovrebbe essere in grado di fornire sviluppo, staging e produzione.
- Nessuno dovrebbe essere in grado di scrivere in produzione tranne il team di sviluppo (e anche in questo caso dovrebbe esserci un processo di distribuzione).
Sono sempre riluttante a fare affermazioni come questa perché sembrano dogmatiche, ma trovo che più a lungo lavoro in questo settore, più penso che queste tre regole siano importanti.
O forse sono davvero solo delle linee guida. Dopotutto, ci sono scatti chiamati prima che finiamo effettivamente le cose.
Indipendentemente dal fatto che siano più suggerimenti o regole non importa. Ci sono ragioni per cui arriviamo tutti alle conclusioni che facciamo, giusto? E quindi nei prossimi post (piuttosto che in un lungo post), condividerò i motivi per cui ho ritenuto importanti queste tre regole.
Progettazione dal comitato
Quando si utilizza questo termine, non intendo dire che una singola persona dovrebbe essere responsabile della progettazione di un sito. Intendo solo che un’agenzia o un gruppo di coloro che si concentrano sul design dovrebbe esserne responsabile.
Design by Committee è un termine denigratorio per un progetto che vede coinvolti molti designer ma nessun piano o visione unificante.
Quindi un "comitato" in questo caso è quando un gruppo di persone, o i clienti o quelli legati ai clienti in qualche modo, vengono a vedere il risultato dell’implementazione (o anche solo il design), inviano suggerimenti via e-mail su ciò che avrebbero piace vedere e aspettarsi che accada.
Cioè, l’ esperienza se un determinato designer viene sacrificato per le opinioni di un altro gruppo.
La principessa Leia non era un comitato.
E, forse in casi estremi (anche se non l’ho mai sperimentato personalmente), usa il pagamento come leva per ottenere ciò che vogliono.
Il fatto è che le persone incaricate di progettare la soluzione per il cliente dovrebbero essere, come affermato, esperti del settore. Capiscono tipografia, colori, risoluzioni dello schermo, accessibilità e così via.
Lasciarli alla loro area di competenza è sempre una buona idea.
Prendersi cura del progetto
Niente di tutto questo ha a che fare con qualcuno che ha più controllo sul progetto di chiunque altro.
Si tratta di assicurarsi che tutte le parti interessate del progetto lavorino insieme e non attraversino aree di responsabilità. (Immaginate, per esempio, le GIF che verrebbero utilizzate per la pubblicità se gli sviluppatori fossero responsabili delle pubblicità. 😏)
La conclusione è che un progetto di successo è proprio questo quando tutti stanno nel proprio angolo e lavorano insieme nella propria area di competenza.
Altrimenti, finisci con le cose che non sono sincronizzate e fondamentalmente crei più problemi quando non ce n’erano (beh, almeno in un’area particolare) con cui iniziare.
Qual è il prossimo?
Nel prossimo post tratterò l’idea del provisioning degli ambienti, cosa significa e come gioca nel ruolo generale della gestione del progetto. Ma ne parlerò più in dettaglio nel post.
In definitiva, si tratta di assicurarsi che chi ha accesso in lettura e scrittura alle varie aree in cui è possibile distribuire l’applicazione o il progetto. Certo, per qualcuno che legge questo, questo potrebbe sembrare un po’ come un contenuto "per principianti" o non come un contenuto relativo allo "sviluppo".
Ma se sei nel business di lavorare con gli altri per costruire una soluzione, allora queste sono cose in cui probabilmente ti imbatterai ed è più facile avere un piano basato sugli errori che altri hanno commesso (vale a dire io 🙂) che imparare cose nel modo più duro.