Come lavoriamo · il modello di team
Due, sei, dieci e undici. Questi sono i team, e potete verificarli tutti e quattro.
Ogni fornitore pubblica un organigramma di ruoli. Quasi nessuno pubblica le dimensioni che ha davvero gestito, perché quelle dimensioni sono imbarazzanti o inventate. Questi quattro numeri vengono dai quattro casi presenti su questo sito e ciascuno è riportato sul caso a cui appartiene.
Quel che segue è la forma dietro ciascun numero e poi la metà più utile: quando ciascun ruolo non serve affatto.
I numeri reali
Quattro incarichi, quattro forme diverse
Il rapporto conta più del totale. Ognuno di questi è stato composto in base a dove stava davvero la difficoltà, e la difficoltà stava ogni volta in un punto diverso.
Undici · compliance normativa
Un project manager, un analista di sistema, un designer, cinque analisti ML, dati e trading, un ingegnere QA, un ingegnere DevOps, uno sviluppatore full-stack. Cinque analisti contro un solo sviluppatore: la difficoltà era capire cosa richiede una norma e che aspetto ha il trading abusivo, non costruire schermate. Il caso
Dieci · rilevamento delle minacce SMS
Un project manager, un analista di sistema, un designer, tre analisti ML, dati e trading, un ingegnere QA, un ingegnere DevOps, uno sviluppatore back-end e uno front-end. Tre analisti contro due sviluppatori: il rilevamento si vince con le persone che sanno distinguere una campagna fraudolenta da una di marketing e che continuano ad avere ragione dopo che i truffatori si sono adattati. Il caso
Sei · piattaforma comunale
Un team di consegna completo per un sistema con un flusso di lavoro reale, più ruoli e due client su un unico core — costruito, consegnato e in funzione dal 2020 senza di noi. La dimensione adatta a un sistema in cui il dominio è conoscibile e il lavoro è la quantità di schermate. Il caso
Due · applicazione di pagamento
Un ingegnere mobile e un ingegnere backend su un servizio PHP, a mantenere e migrare un’applicazione di pagamento che è rimasta in produzione per tutto il tempo. Un prodotto ben compreso con una scadenza esterna rigida non ha bisogno di un team; ha bisogno di due persone che non vengono interrotte. Il caso
I ruoli
A cosa serve ciascuna persona, e quando non serve
- Analista di sistema. Trasforma ciò che fa l’azienda in entità, stati, regole e nei casi che nessuno menziona perché sono ovvi per chi fa quel lavoro ogni giorno. Su un sistema con un dominio complesso questo ruolo fa risparmiare più di qualunque altro — ed è il primo che i committenti inesperti tagliano. Non serve quando il dominio è davvero semplice o avete già un business analyst che mette le cose per iscritto.
- Project manager. Il piano, il calendario, i rischi e la revisione ogni due settimane. Non serve sotto le quattro persone circa, e non ve lo metteremo in fattura. Mai un traduttore tra voi e gli ingegneri.
- Designer UI/UX. Serve quando un’interfaccia sarà guardata da persone che non hanno scelto di usarla — il pubblico, i clienti, gli ispettori. Non serve quando il sistema è interno, gli utenti sono formati e la coerenza conta più dell’aspetto.
- Ingegnere QA. Serve dove un difetto arriva ai soldi, a un’autorità di vigilanza o alla giornata di una persona. Non serve quando avete un QA che conosce già la vostra attività, e vale più del nostro che non la conosce.
- Ingegnere DevOps. Serve quando il percorso di deployment non esiste ancora, o esiste e nessuno osa usarlo. Non serve quando avete un team di piattaforma — in quel caso i nostri ingegneri si inseriscono nella vostra pipeline invece di costruirne una seconda.
- Analisti, ML e dati. Servono quando il prodotto è un giudizio e non una schermata. È il ruolo che cresce con la difficoltà e non con il volume, e i due incarichi qui sopra lo mostrano salire a cinque e a tre.
- Sviluppatori. Meno di quanti ci si aspetti sui sistemi con un dominio complesso, e il punto è il rapporto, non il numero di teste.
Regole di composizione dei team che rispettiamo
Quattro cose che decidono la forma prima che appaia un CV
01 · Comporre il team sulla difficoltà, non sul deliverable
Valutate dove il progetto può davvero fallire. Se è il dominio, gli analisti sono più numerosi degli sviluppatori e la fattura non dovrebbe sorprendere nessuno. Se è la scadenza, il team è piccolo e non viene interrotto.
02 · Un solo nome responsabile
Non un comitato e non un titolo di ruolo. Nei team piccoli l’ingegnere senior, in quelli più grandi il project manager, e il nome è nella proposta, non si scopre durante il primo incidente.
03 · Assegnati a una fase, non riservati
Le persone sono impegnate sulla fase che hanno davanti, e vi diciamo onestamente se le stesse persone saranno libere per quella successiva. Una continuità promessa che non arriva è peggio di una continuità mai promessa.
04 · Persone con nome e cognome, e con i loro punti deboli
Incontrate gli ingegneri prima del contratto, e diciamo in cosa ciascuno è più debole — forte sulla piattaforma, nuovo al vostro dominio; ingegnere eccellente, silenzioso in una riunione di dodici persone. Lo scoprireste comunque alla terza settimana.
Domande
Quelle che arrivano quando arriva la proposta
Perché i vostri team sono così piccoli?
Perché il secondo sviluppatore su un sistema costa più di mezzo sviluppatore in coordinamento, e il quinto costa molto di più. Noi componiamo il team sulla forma del problema: l’incarico di compliance aveva cinque analisti e un solo sviluppatore perché la difficoltà era capire la regolamentazione, non scrivere schermate, e l’applicazione di pagamento è andata avanti con due persone perché era un prodotto ben compreso con una scadenza rigida. Un fornitore i cui team hanno tutti la stessa dimensione sta componendo il team a partire da un listino di tariffe.
Avremo un project manager?
Su un incarico abbastanza grande da richiederlo, sì, e il suo lavoro è il piano, il calendario e i rischi — non fare da traduttore tra voi e gli ingegneri. Sotto le quattro persone circa un project manager è un costo in più e non ve lo metteremo in fattura. Se vi trovate a spiegare qualcosa di tecnico a qualcuno che non può rispondere a una domanda tecnica, quello è un nostro errore di composizione del team.
Che cosa fa concretamente un analista di sistema?
Trasforma ciò che fa l’azienda in qualcosa che uno sviluppatore può costruire e un tester può verificare — le entità, gli stati, le regole, i casi che nessuno ha menzionato perché sono ovvi per chiunque faccia quel lavoro ogni giorno. Sui sistemi con un dominio complesso questo ruolo fa risparmiare più di qualunque altro, ed è il primo che i committenti inesperti cercano di tagliare.
Possiamo usare il nostro designer, il nostro QA o il nostro DevOps?
Sì, e dovreste farlo dove li avete. Preferiamo inserirci in una capacità che già possedete piuttosto che duplicarla e farvela pagare due volte — e un ingegnere QA che conosce già la vostra attività vale più di uno nostro che non la conosce. Diteci cosa avete e la proposta verrà composta intorno a quello.
Chi è davvero responsabile se qualcosa va male?
Una persona con nome e cognome dalla nostra parte per tutto l’incarico, e non è un comitato. Nei team piccoli è l’ingegnere senior; in quelli più grandi il project manager. Il nome è nella proposta, non si scopre durante il primo incidente.
Che cosa succede al team tra una fase e l’altra?
Le persone sono assegnate a una fase, non riservate a tempo indeterminato, e vi diremo onestamente se le stesse persone saranno disponibili per quella successiva. Un fornitore che promette una continuità che non può garantire produce la versione peggiore di tutto questo: gli stessi nomi nella proposta e facce diverse allo stand-up.
Prossimo passo
Diteci cosa avete già
Design, QA, un team di piattaforma, un analista che conosce il dominio. Ognuna di queste cose rende la proposta più piccola, ed è meglio fare quella conversazione prima della proposta che dopo.