Partner tecnologici e di prodotto
Per software vendor e aziende di prodotto che hanno bisogno di un team di ingegneria accanto al proprio per anni e non per uno sprint. Un modulo di cui siamo responsabili end to end, una piattaforma che aiutiamo a gestire o un secondo team che porta avanti la roadmap che non riesce a coprire con il personale, con le stesse persone che restano abbastanza a lungo da imparare il dominio.
Diverso dall’acquisto di un progetto
Un progetto ha una fine, e tutto ciò che riguarda il modo in cui è composto il team ne discende: le persone vengono assegnate, il dominio viene appreso quanto basta per finire e la conoscenza se ne va con loro. Un prodotto non finisce. Da un team esterno richiede continuità, un interesse a far sopravvivere l’architettura nei due anni successivi e persone che si oppongono quando una scorciatoia costerà più tardi più di quanto fa risparmiare ora.
È il rapporto che questa pagina descrive. Dal punto di vista commerciale di solito assomiglia a un team dedicato; ciò che lo rende una partnership è che rispondiamo di un risultato nel Suo prodotto e non di un elenco di ticket.
Di che cosa siamo tipicamente responsabili
Un modulo di cui siamo responsabili end to end
Una parte circoscritta del Suo prodotto: il livello delle integrazioni, la parte di reportistica, l’area di amministrazione, il client mobile. Ne siamo responsabili nella Sua base di codice, secondo la Sua architettura, e rispondiamo dei suoi difetti e non di un numero di ticket.
Un secondo team sulla roadmap
Tutto ciò che sa di dover costruire e non riesce a coprire con il personale. Un team parallelo che lavora nei Suoi repository e secondo i Suoi rituali, così che la roadmap avanzi su due fronti anziché essere riprioritizzata fino a ridursi a uno.
La piattaforma sottostante
Infrastruttura cloud dichiarata in Terraform, pipeline, ambienti, osservabilità, lavoro su database e sicurezza. La parte per cui un team di prodotto non ha mai tempo e di cui sente la mancanza ogni settimana.
Portare avanti un prodotto datato
Un prodotto che vende ma che ha smesso di essere modificabile. Finora nove prese in carico, la più vecchia scritta nel 2008, sempre a partire da una revisione in sola lettura e da un elenco scritto dei rischi anziché da una proposta di riscrittura.
Che cosa fa funzionare una partnership di lunga durata
Persone che restano
Gli incarichi qui durano anni e non sprint, e la conoscenza del dominio resta alle stesse persone. Il risultato peggiore per un partner è pagare due volte la stessa curva di apprendimento.
La Sua architettura, non la nostra
Siamo abituati a prendere in mano la tecnologia su cui un prodotto già gira anziché orientarlo verso ciò che conosciamo meglio. Un team partner che continua a proporre una riscrittura è un team partner che ha smesso di essere utile.
Regole che sopravvivono a un passaggio di consegne
I test vengono rilasciati insieme alla funzionalità, la build si chiude con zero warning, la sicurezza è deny-by-default e l’infrastruttura è codice. Il codice scritto in questo modo è codice che i Suoi ingegneri possono riprendere in mano.
Un solo punto di riferimento per ogni dato
I valori derivati vengono calcolati una volta e usati ovunque. In un prodotto con più team al suo interno, una verità duplicata è il bug che si scopre sei mesi dopo e che non si riesce a spiegare a un cliente.
Una sostituzione a nostro carico, non fatturata
La revisione dell’architettura, un secondo paio d’occhi sulle pull request e la sostituzione durante le ferie vengono da BigTree108 e non dal Suo budget.
La Sua proprietà intellettuale, sempre
Ogni specialista cede all’azienda il proprio lavoro prima dell’accesso, e questo viene ceduto a sua volta a Lei, quindi nulla in una partnership di lunga durata complica la questione di chi possieda il prodotto.
Gestiamo un prodotto nostro
Tutto ciò che usiamo internamente, dalla selezione e dall’onboarding alla rilevazione delle ore, ai contratti e alla fatturazione, è un’unica piattaforma sullo stack che offriamo ai partner: .NET su Azure Functions, Angular, Azure SQL, Terraform. Non è un pezzo da portfolio: è il sistema da cui dipende l’azienda, e abbiamo convissuto abbastanza a lungo con le nostre decisioni di architettura da sapere quali fossero sbagliate.
È il giudizio che un partner di prodotto sta davvero acquistando. Il case study descrive che cosa fa e come è costruita.
Come inizia
Con qualcosa di piccolo e reversibile. Un ingegnere su una parte circoscritta del Suo backlog, oppure una revisione in sola lettura della parte del prodotto che La convince meno, consegnata come elenco scritto dei rischi in ordine di impatto sulla produzione. Entrambi sono modi poco costosi per scoprire se leggiamo la Sua base di codice come vorrebbe che la leggesse un partner.
Da lì la forma abituale è un team dedicato che cresce con la roadmap. Se alla fine preferisse possedere il team a pieno titolo, il Build-Operate-Transfer è lo stesso insieme di persone con un trasferimento scritto nel contratto.
Ha bisogno di un secondo team sul Suo prodotto?
Ci invii il prodotto, la parte della roadmap che continua a slittare e, se può, un link al repository. Riceve le domande che ci restano, un approccio e una stima entro un giorno lavorativo.