Cos'è DesignOps? Perché la tua squadra ha bisogno di questo? E come può DesignOps aiutare il tuo team di progettazione / sviluppo a riuscire? Questo articolo risponde a queste domande e fornisce anche suggerimenti utili su come iniziare a implementare questo nuovo concetto nel tuo team di sviluppo.
Nel mondo moderno, è la velocità del team di sviluppo che spesso definisce la fattibilità di un prodotto. Allo stesso tempo, c'è un elemento chiave che è più importante e più problematico: il design.
Il design spesso diventa un collo di bottiglia e influenza in modo significativo l'intero processo di sviluppo, indipendentemente dalle dimensioni della tua squadra. A volte sforzi sovrumani da parte di un design guidato aiutano a guidare il processo di progettazione, ma non appena il carico di lavoro aumenta, devi scalare la tua squadra.
Quante volte hai visto:
Se alcuni o tutti questi suoni familiari, è ora di implementare DesOps (Design Operations).
Il termine DesOps o DesignOps è una replica del termine DevOps che è una pratica di ingegneria del software che mira a unificare i processi di sviluppo per creare maggiore efficienza. Come gli specialisti DevOps, gli specialisti di DesOps sono esperti progettisti con capacità manageriali che comprendono il processo di progettazione nel più ampio contesto dello sviluppo del prodotto.
Anche se non tutti abbiamo il termine "DesOps" nel nostro titolo di lavoro, molti progettisti senior sono già responsabili dello stesso ruolo. Dalla creazione di processi di progettazione, allo sviluppo di sistemi di progettazione, alla creazione di strategie e alla gestione di team di progettazione, DesOps rappresenta un ruolo sempre più richiesto.
Ciò che conta davvero è che questo approccio è scalabile e pertinente anche in team con un singolo designer. Quindi, come inizi a implementare DesOps?
I progettisti devono sapere quando il loro lavoro è completo e pronto per essere passato al team di sviluppo. Ad esempio, i progettisti hanno bisogno di una chiara comprensione di quali stati devono avere ciascuna schermata e quali risorse saranno richieste al team di sviluppo per costruire tali risorse.
Potrebbe sembrare che questa sia un'area che i progettisti dovrebbero comprendere intrinsecamente. Ma in realtà è uno dei punti di frizione più comuni in un progetto e non dovrebbe essere ignorato. Se si articola chiaramente ciò che è richiesto, si riducono i conflitti e si assicura che tutti comprendano le proprie responsabilità.
I vantaggi di questo sono: consente di mantenere un ritmo di sviluppo costante; riduce il tempo di sviluppo totale; riduce il numero di discussioni necessarie tra progettisti, sviluppatori e lead.
Per l'ultimo punto, stavamo considerando specificamente ciò che il progettista dovrebbe trasmettere agli sviluppatori. Questo punto riguarda la forma che il progettista dovrebbe utilizzare per trasmettere design-mockups, design lucido, prototipi, moodboard: cosa deve fornire il progettista per trasmettere efficacemente le proprie intenzioni in un formato che gli sviluppatori possano comprendere.
Ci sono numerose opzioni, come ad esempio zeplin o InVision ma uno dei reclami più comuni da parte degli sviluppatori è che questi formati non forniscono tutto ciò di cui hanno bisogno (come le risorse esportate). Tuttavia, di solito è perché i progettisti non hanno esportato correttamente i loro progetti. Chiarendo per i progettisti ciò che dovrebbero produrre, possono trasferire facilmente le risorse giuste.
È necessario creare un documento interno che conterrà requisiti tecnici specifici per le risorse, gli strumenti di progettazione, la collaborazione con gli sviluppatori e altri membri del team; infine, questo documento dovrebbe definire chiaramente quando e come i disegni devono essere consegnati.
Un insieme di soluzioni progettuali e ingegneristiche e guide per la loro implementazione garantiranno una serie di vantaggi: integrità del prodotto; l'onboarding più semplice e veloce dei nuovi membri del team; lavoro più efficiente di progettisti e sviluppatori (dato che possono comunicare in una lingua definita dal sistema di progettazione).
I vantaggi di questo includono: miglioramento della qualità complessiva del lavoro; riduce la "sag" quando si scala la squadra; aumenta la velocità di progettazione e sviluppo.
Tutti noi amiamo i nuovi fantastici strumenti, ma un team efficace lavora con un set uniforme di strumenti e garantisce che questa unità sia sotto la vostra responsabilità.
Tutti gli strumenti dovrebbero essere aggiornati, ma se un aggiornamento viene saltato per qualsiasi motivo, tutti dovrebbero saltarlo.
I vantaggi di questo includono: maggiore coinvolgimento del team; maggiore design e velocità di sviluppo; migliore collaborazione di squadra.
Gli sviluppatori sono più fortunati in termini di questo compito, perché il controllo della versione per il codice è un settore maturo con molte opzioni. È difficile produrre un approccio simile per i progettisti, dal momento che i processi sono così diversi, ma nell'ultimo anno strumenti come Astratto , Kaktus , e pianta sono sempre più popolari Puoi persino avere più designer che lavorano su un singolo layout con qualcosa di simile Figma .
I vantaggi di questo sono: una migliore comunicazione; ridimensionamento semplificato del team; processi di progettazione di tracce veloci in quanto più progettisti possono lavorare su un singolo progetto in modo produttivo.
Per descrivere tutte le funzionalità relative ai progetti, cerca di utilizzare "documentazione visiva" invece di scrivere specifiche tecniche. Nella maggior parte dei casi, è sufficiente che uno sviluppatore disponga di un prototipo interattivo per comprendere la logica di base e trovare risposte alla maggior parte delle domande.
I vantaggi di questo includono: tempo ridotto di scrittura di specifiche tecniche; riduce la scala di lavoro per gli scrittori tecnici; gli sviluppatori dedicano meno tempo a leggere la documentazione e più tempo a scrivere codice; i designer sono più produttivi; ritmo di sviluppo accelerato.
Non c'è assolutamente spazio per la progettazione in molte delle più diffuse metodologie di sviluppo del software; qualunque sia il processo di sviluppo che stai utilizzando, trova spazio per i progettisti.
I vantaggi di questo sono: una squadra unita con una migliore comunicazione; maggiore velocità di sviluppo; rielaborazione ridotta e tempi di inattività degli sviluppatori.
Dovresti dimostrare costantemente la crescita di indicatori quantitativi e qualitativi grazie ai cambiamenti implementati, sia per i membri del team che per il top management. Senza questo, un team sarà riluttante a cambiare, mentre il top management non sarà in grado di capire dove e perché vengono spesi risorse aggiuntive. La costante raccolta e presentazione di risultati positivi dopo l'implementazione delle modifiche ti aiuterà a ottenere credibilità e autorità necessarie per ulteriori cambiamenti nel flusso di lavoro del team.
I vantaggi includono: maggiore motivazione e una squadra più forte; facilitazione di nuove regole e pratiche; supporto per l'innovazione futura.
Il termine "DesOps" è piuttosto nuovo e sta appena iniziando ad acquisire il suo significato; il prima conferenza di DesOps è stato tenuto solo a novembre, a New York.
Per ora chiamerei semplicemente questa una cultura che mira a sviluppare e facilitare processi di progettazione solidi. Ma ritengo che nel prossimo futuro avremo questo come un ruolo di design separato in ogni team di prodotto. Tuttavia, sento che possiamo già parlare con sicurezza dell'importanza di introdurre queste pratiche al fine di migliorare l'efficienza del flusso di lavoro di progettazione e lo sviluppo del prodotto in generale.