Sviluppa il pensiero, non l’artefatto

Domande, riflessioni e operazioni che un software architect deve affrontare all’avvio di un nuovo progetto.

Siti Web e applicazioni hanno cicli di vita sempre più complessi. L’introduzione di nuove funzionalità, rivsitazioni dell’interfaccia e dell’esperienza utente sono all'ordine dello sprint. Per rispondere a questa esigenza, l'architettura software deve essere dinamica e non può più essere estrapolata dall’artefatto statico di un designer, ma deve entrare a far parte flusso di progettazione.

Alcune regole

0. Non impostare il progetto pensando al rilascio del prodotto e al MVP. Mira a semplificare l’introduzione di nuove feature e facilitarne il mantenimento. Dove e quando possibile, gioca d’anticipo.

1. Conosci i punti deboli del tuo team e metti subito il progetto in sicurezza. Un nuovo progetto è la migliore occasione per sperimentare pratiche e tecnologie, soprattutto se mirate a risolvere i problemi di flusso del progetto precedente. Una buona confidenza aumenta le possibilità di un forte slancio iniziale.

2. È importante che il codice sia resiliente, soprattuto in questa fase. La resilienza dipende dalla qualità del codice e del flusso con qui questo viene prodotto (review, pull request, pair), ma anche da come il progetto viene interpretato: più la struttura del codice ne è affine, più facile e veloce è l’evoluzione.

3. Conosci i contenuti che verranno inseriti, dove vengono salvati e la struttura dei database. Quando le viste sono in grado di riflettere proprietà e relazioni del dato, è probabile che l’introduzione di una nuova feature non richieda un refactor.

4. Conosci le dipendenze del progetto. Deve integrarsi con sistemi esistenti? Quali componenti esistono già? Su che tecnologia sono o saranno basati? O al contrario: quali progetti dipenderanno da questo? Come verrà distribuito e usato da altri sviluppatori?

5. Conosci le dipendenze delle dipendenze. Condizioni legali per il rispetto della privacy, esigenze di branding o di marketing, ricerche di mercato, test di usabilità (...) sono tutti fattori che aiutano ad interpretare al meglio il progetto.

6. Conosci i tuoi designer. Come approcciano il progetto? Quali sono le fondamenta sulle quali costruiscono? Quali relazioni creano tra i dati? Cerca di implementare gli stessi ragionamenti nella costruzione della vista. Fatti spiegare quali proposte sono state presentate e il motivo per il quale vengono rifiutate in modo da escludere soluzioni e ridurre gli scenari.

7. Conosci il tuo product owner e il tuo cliente. Quali sono le priorità dopo il primo rilascio? Quali sono gli obbiettivi del prodotto e quali invece quelli degli stakeholder? Quale parte del progetto vuoi/devi pianificare più attentamente perché una tecnologia diventi valore aggiunto per il cliente e il suo business? Cerca di essere proattivo per individuare e discutere quanto prima queste possibilità.

8. Conosci gli altri team e le persone con cui devi interfacciarti per dipendenze o lavorazioni condivise. Qual è il loro stack tecnologico? Quali sono i punti di forza di questo team? Chi è la persona più indicata per un determinato argomento? Instaurare un rapporto diretto e professionale con queste persone concretizza (e riduce) la distanza astratta tra i team, permettendo di creare prodotti più interoperabili.

Unire i puntini

Se le fondamenta del codice sapranno rispettare tutte queste interdipendenze e relazioni, se invece di sviluppare un progetto riesci a sviluppare l’idea che l’ha pensato e costruito, allora il tuo lavorò rientrerà nella dimensione totale del progetto, diminuendo frizioni, tempi, malumori e riduendo i margini di errore.