Gestire da soli attività su larga scala: decine di progetti con un piccolo team
Nella crescita di ogni piccola attività arriva un momento in cui i progetti attivi sono più numerosi di quelli che si riescono a tenere a mente. Gli ordini vanno monitorati su più marketplace. L’infrastruttura richiede manutenzione regolare. Sono in sviluppo nuove funzionalità. I clienti chiedono informazioni su spedizioni, conformità e previsioni. Sono tutte attività concrete, ma le ore disponibili non aumentano con il numero di progetti.
La maggior parte dei consigli su come gestire questa situazione presuppone l’assunzione di altre persone. Spesso è la risposta giusta, ma non sempre: soprattutto quando i progetti sono eterogenei, con stack tecnologici, ambiti e ritmi operativi diversi, e i ricavi aggiuntivi di ciascun progetto non giustificano una persona dedicata. Ai piccoli team che gestiscono decine di progetti servono sistemi, oltre a più persone.
Questo articolo descrive il nostro approccio: le scelte degli strumenti che hanno retto nel tempo, i principi operativi che riducono gli oneri di coordinamento e la tensione tra costruire cose nuove e mantenere ciò che già funziona.
La tensione centrale
La tensione fondamentale nella gestione su larga scala con un piccolo team nasce da due attività che competono per la stessa risorsa: l’attenzione. Costruire cose nuove richiede un’attenzione esplorativa e senza interruzioni. Mantenere i sistemi esistenti richiede un’attenzione pronta a reagire e rispondere. Sono modalità incompatibili, e passare dall’una all’altra ha un costo che non compare in nessuno strumento di gestione dei progetti.
In realtà, però, la maggior parte dei problemi operativi non nasce dalla scelta della modalità sbagliata. Nasce dall’assenza di una scelta: il confine tra manutenzione e sviluppo si sfuma finché nessuna delle due attività viene svolta correttamente. Il lavoro di manutenzione arretrato cresce perché lo sviluppo lo mette da parte. Lo sviluppo si blocca perché le interruzioni per la manutenzione si accumulano. Entrambi ne risentono.
La nostra disciplina consiste nell’assegnare il tempo deliberatamente, anziché lasciare che siano gli eventi a deciderlo. Una quota definita di ogni settimana è riservata alla manutenzione: revisioni dell’infrastruttura, aggiornamenti delle dipendenze, verifiche del monitoraggio e report ai clienti. Questo tempo non è disponibile per lo sviluppo, indipendentemente da quanto sia interessante il lavoro del momento. Il tempo dedicato allo sviluppo è protetto dalle interruzioni di manutenzione, salvo incidenti effettivi. La ripartizione non è rigida al minuto, ma è abbastanza concreta da non essere assorbita silenziosamente da altre priorità.
La scelta degli strumenti
Il principio che applichiamo agli strumenti è standardizzare rigorosamente all’interno di uno stack e ridurre al minimo il numero di stack. Ogni strumento aggiuntivo è un possibile punto di guasto, qualcosa da imparare e una potenziale dipendenza che può bloccare lavori non correlati quando presenta problemi. Il costo di uno strumento non è la licenza: è l’attenzione continua richiesta da tutto ciò che lo coinvolge.
Per l’infrastruttura utilizziamo Docker su un unico fornitore. Non Kubernetes, un’architettura multi-cloud o una service mesh. Docker Compose su un VPS adeguatamente dimensionato gestisce il carico di tutte le attività attuali, con una documentazione chiara che rende semplice il ripristino dopo un guasto. Un’infrastruttura più sofisticata richiederebbe più attenzione per la manutenzione di quanto farebbe risparmiare sotto qualsiasi altro aspetto.
Per lo sviluppo delle applicazioni adottiamo un insieme ristretto di tecnologie: TypeScript per i frontend web, Python per i servizi backend e le pipeline di dati, PostgreSQL (spesso TimescaleDB) per l’archiviazione persistente, Redis per code e cache. I nuovi progetti partono da questo stack, salvo un motivo convincente per discostarsene. Il motivo deve essere esplicitato e valutato rispetto al costo di mantenere nel lungo periodo uno stack non standard.
Per gestire progetti e attività usiamo un sistema abbastanza semplice da evitare che lo strumento stesso diventi un progetto. Gli oneri di manutenzione di un sistema complesso di gestione dei progetti spesso superano quelli dei progetti che dovrebbe coordinare. La struttura essenziale è questa: ogni progetto ha uno stato attuale definito, una prossima azione definita e un responsabile definito. Tutto il resto è un dettaglio facoltativo.
La disciplina consiste nel resistere alla pressione di adottare nuovi strumenti che risolvono problemi che ancora non abbiamo. Una nuova piattaforma di osservabilità, una nuova pipeline di distribuzione, un nuovo strumento di comunicazione del team: ciascuno viene presentato come una soluzione. Ma il costo di adozione è reale e immediato, mentre il beneficio è ipotetico e futuro. Valutiamo i nuovi strumenti chiedendoci quale problema concreto e attuale risolvano e se valga la pena sostenere i costi di adozione e manutenzione.
Dare priorità alle attività asincrone
La comunicazione sincrona, tramite chiamate, riunioni o chat in tempo reale, ha un costo fisso per interazione, indipendentemente dalla complessità dell’argomento. Ha anche un costo di pianificazione che spesso supera quello dell’interazione stessa. Per piccoli team con un portafoglio di progetti eterogeneo, gli oneri di coordinamento sincrono possono assorbire una quota sproporzionata del tempo di lavoro disponibile.
Diamo priorità alla comunicazione asincrona: comunicazione scritta e documentazione sono la norma, mentre riserviamo l’interazione sincrona alle situazioni in cui la scrittura è davvero insufficiente. Se una domanda trova risposta nella documentazione, si deve leggere la documentazione. Se questa non esiste, la risposta consiste nello scriverla, anziché fare una chiamata che risolve il caso attuale ma lascia senza risposta quello successivo.
In pratica, le decisioni vengono messe per iscritto. Quando prendiamo una decisione tecnica o operativa rilevante, come la scelta di un database, una modifica al processo di distribuzione o a un flusso di lavoro del cliente, documentiamo le ragioni, le alternative considerate e il risultato atteso. La documentazione non serve ai posteri. Serve per la prossima volta che si presenterà la stessa domanda, cosa che in una piccola organizzazione con molti progetti accade più spesso del previsto.
Gli aggiornamenti sullo stato dei progetti sono scritti e programmati, anziché verbali e reattivi. Ogni progetto ha un breve aggiornamento settimanale, con stato attuale, modifiche recenti, lavoro previsto ed eventuali ostacoli, che viene scritto anziché presentato in riunione. Scrivere l’aggiornamento spesso fa emergere problemi che non sarebbero comparsi in un confronto verbale, perché impone il livello di precisione necessario a renderli visibili.
Sviluppare o acquistare
Ogni strumento che sviluppi è un progetto che ti impegni a mantenere a tempo indeterminato. È facile dimenticarlo quando decidi di costruirlo, perché in quel momento vedi il costo di sviluppo e le capacità che lo strumento offre. Il costo della manutenzione continua emerge solo più avanti, ma è reale e si accumula.
Applichiamo tre criteri alle decisioni tra sviluppo e acquisto. Primo: esiste già uno strumento che risolve adeguatamente il problema? Adeguato non significa perfetto. Uno strumento commerciale che risolve bene il novanta per cento del problema è quasi sempre preferibile a uno personalizzato che lo risolve al cento per cento ma richiede manutenzione continua, perché il divario del dieci per cento è di solito inferiore al costo di manutenzione dello strumento personalizzato.
Secondo: il problema richiede una conoscenza dei nostri dati o sistemi specifici che nessuno strumento esterno può avere? Pipeline di dati, logica aziendale e integrazioni tra sistemi che controlliamo sono candidati allo sviluppo interno. Le funzioni generiche, come invio di email, elaborazione dei pagamenti, autenticazione e dashboard di monitoraggio, sono candidate all’acquisto, salvo che le opzioni commerciali siano davvero inadatte.
Terzo: siamo disposti a condividere i dati coinvolti con un servizio di terze parti? Alcuni dati operativi, come dettagli degli ordini, informazioni sui clienti e dati finanziari, non dovrebbero transitare attraverso servizi commerciali che li registrano, li analizzano o li usano per i propri scopi. Per queste funzioni, le soluzioni gestite sulla propria infrastruttura sono giustificate dalla privacy anche quando le alternative commerciali sono tecnicamente superiori. È per questo che gestiamo sulla nostra infrastruttura l’analisi dei dati, il backend Supabase e lo stack di monitoraggio.
In realtà, le decisioni di sviluppo più costose che abbiamo preso non sembravano sbagliate al momento. Apparivano strumenti personalizzati ragionevoli per esigenze specifiche. Il costo è emerso diciotto mesi dopo, quando uno strumento ha richiesto un aggiornamento per adattarsi a una modifica delle dipendenze, quando un nuovo membro del team ha dovuto comprendere codice privo di documentazione esterna o quando un bug ha bloccato una consegna al cliente senza un canale di assistenza a cui rivolgersi. La lezione non è evitare sempre lo sviluppo interno. È valutare con onestà il costo dell’intero ciclo di vita, non solo quello di costruzione.
La visione del portafoglio
Gestire contemporaneamente decine di progetti è più semplice quando ogni progetto è considerato parte di un portafoglio, anziché un obbligo indipendente. Un portafoglio comprende progetti che generano rendimenti crescenti nel tempo con investimenti continuativi relativamente ridotti e altri con risultati stabili o in calo. L’assegnazione delle risorse richiede valutazioni diverse per ciascuno.
I progetti con rendimenti crescenti meritano investimenti di manutenzione per proteggere ciò che funziona, ma raramente richiedono uno sviluppo significativo. Un’attività e-commerce con posizionamento organico stabile, buone recensioni e logistica affidabile ha già conquistato il proprio rendimento. Il compito è mantenerla funzionante, più che migliorarla. È un approccio radicalmente diverso da quello di un progetto ancora in costruzione e richiede meno attenzione, liberando capacità per i progetti che non generano ancora rendimenti crescenti.
I progetti che non generano rendimenti crescenti richiedono una valutazione chiara: è probabile che ulteriori investimenti migliorino la traiettoria, oppure è il momento di accettare il risultato e riassegnare le risorse? I piccoli team con molti progetti sono particolarmente esposti alla fallacia dei costi irrecuperabili: continuare a investire in progetti che non funzionano per via dell’impegno già speso. La visione del portafoglio rende più visibile questo errore, perché impone un confronto: l’attenzione dedicata a mantenere un progetto fermo non è disponibile per quelli che potrebbero generare rendimenti crescenti.
Il vero collo di bottiglia
La visione tradizionale dei limiti alla crescita dei piccoli team si concentra su denaro e tempo. Più progetti richiedono più denaro per finanziarli e più tempo per eseguirli. È vero, ma incompleto.
Il vincolo determinante per un piccolo team che gestisce progetti eterogenei in diversi ambiti è l’attenzione, in particolare la qualità dell’attenzione disponibile per le decisioni che richiedono conoscenza del contesto. Le attività operative di routine possono essere sistematizzate, delegate o automatizzate. Decidere cosa sviluppare, come rispondere a un cambiamento del mercato, se entrare in un nuovo marketplace o se un approccio tecnico sia valido richiede il giudizio di qualcuno che conosca l’intero contesto. Questo tipo di attenzione non cresce linearmente con le dimensioni del team e non può essere sostituito interamente da procedure.
Ne consegue che la leva più importante per un piccolo team non è l’efficienza, cioè fare le stesse cose più velocemente, ma la selettività: scegliere quali cose fare. Un progetto che richiede attenzione costante per restare sostenibile non è economico, anche se i costi diretti sono bassi. Un progetto che funziona in modo affidabile con interventi minimi vale nel portafoglio più di quanto suggeriscano i suoi ricavi, perché non consuma l’attenzione necessaria al lavoro che richiede maggiore capacità di giudizio.
Rendiamo esplicito questo criterio nella selezione dei progetti. Prima di impegnarci in una nuova iniziativa, stimiamo sia lo sforzo di costruzione sia il costo dell’attenzione a regime: quante ore alla settimana serviranno per gestirla una volta realizzata? I progetti con un costo dell’attenzione a regime elevato rispetto al rendimento sono meno interessanti di quanto appaiano considerando solo i costi di costruzione e il potenziale beneficio. Il budget di attenzione è limitato e, a differenza del denaro o del tempo, non se ne può acquistare altro.
Approfondimenti correlati
- Ingegneria della distribuzione: costruire sistemi che vendono al posto tuo — il principio alla base di sistemi operativi che richiedono poca attenzione
- Oltre cento container Docker: la nostra routine di verifica mensile — la disciplina di manutenzione che rende prevedibili gli oneri infrastrutturali
- Costruire un data warehouse Amazon con FastAPI e TimescaleDB — un esempio di scelta di sviluppo interno e l’infrastruttura dati alla base del portafoglio