InnerSource incoraggia e premia la collaborazione ed il riuso del codice per chiunque, indifferentemente dalla posizione che ricopre all’interno della struttura organizzativa aziendale. Questo approccio differisce da quello che si è visto all’interno delle aziende tradizionali dove le idee ed il prodotto del lavoro tendono a rimanere intrappolati tra confini della gerarchia aziendale interna e dei suoi silos. Esploriamo una situazione che illustra un esempio di questa idea.
Immagina che due team della stessa azienda producano software distinti con uno dei componenti dipendente dall’altro. Un esempio potrebbe essere un’interfaccia utente che dipende da un servizio con API esposta per reperire i dati da visualizzare. Questa è una situazione comune in aziende grandi dove un singolo team di produzione software che può avere dozzine o centinaia di clienti.
Quando i team di consumo hanno bisogno di molte funzionalità, i team di produzione normalmente hanno una sorta di requisiti ed un processo di definizione delle priorità per decidere su quali funzionalità lavoreranno. Per le richieste di funzionalità critiche che non hanno una priorità tale da renderle lavorabili subito, il team di consumo potrebbe comunemente scegliere una delle 3 opzioni, ognuna delle quali porta degli svantaggi.
-
Aspetta. I team di consumo potrebbero non fare nulla e zoppicano senza la funzionalità richiesta. Questa opzione richiede la minima quantità di lavoro da parte loro. A seconda dell’utilità della richiesta di funzionalità, l’attesa potrebbe andare bene. Comunque, può comportare un’importante quantità di sofferenza, specialmente se la funzionalità richiesta non venisse mai espletata.
-
Soluzione alternativa. Un team di consumo che non vuole aspettare potrebbe fare un lavoro extra per compensare l’assenza della funzionalità richiesta. Questo lavoro extra può arrivare come un cambiamento nel progetto per chi ne usufruisce. Alternativamente, potrebbero creare un nuovo progetto che include le loro esigenze e che sostituisce il loro utilizzo di tutte o alcune parti del sistema creato dal team di produzione (duplicazione del codice/progetto) Questa strategia permette al team di consumo di ottenere la funzionalità richiesta tramite solo il proprio sforzo. Tuttavia, questo approccio presenta diversi inconvenienti.
-
Qualsiasi lavoro svolto dal team di consumo rimane non disponibile ad altri consumatori con la stessa richiesta di funzionalità.
-
Il team di consumo ha inavvertitamente firmato a lungo termine l’onere del mantenimento del codice appena scritto, che non è nel dominio delle loro competenze di base del team.
-
L’azienda nel suo insieme acquisisce progetti e codice duplicati nello stesso contesto problematico.
-
-
Escalation . Il team di consumo potrebbe non accettare un "no" come risposta e, invece, potrebbe avvalersi di qualcuno tra i manager di produzione per influenzare (o forzare) il team di produzione a realizzare il lavoro. Questa opzione sembra attraente per il team di consumo perché otterrebbero la funzionalità richiesta senza fare il lavoro di implementazione o mantenimento. Tuttavia, è ancora un ostacolo per il team, perché devia necessariamente parte della loro attenzione e del lavoro sul compito non ingegneristico dell’escalation. Inoltre, questa opzione non è scalabile in quanto potrebbe non capitare molte volte che un consumatore possa richiedere l’escalation su richieste di funzionalità prima di danneggiare la loro credibilità L’escalation è dirompente nello stesso modo (ancora di più) per i membri del team di produzione, che sono portati fuori dai loro normali metodi di workflow e assegnazione delle priorità per gestire la richiesta di funzionalità in escalation.
Questa discussione pone le basi per l’InnerSource. InnerSource si applica allo stesso tipo di situazione dove un team di consumo non riesce ad ottenere quello di cui ha bisogno tramite richieste di funzionalità. InnerSource fornisce un modo per i team di incrementare i benefici di attesa, workaround, ed escalation senza gli inconvenienti associati.
InnerSource fornisce anche un miglioramento generale alla cultura ingegneristica poiché gli ingegneri hanno la possibilità di lavorare con un’ampia varietà di nuove tecnologie e persone. Gli sviluppatori fanno da mentori e imparano gli uni dagli altri condividendo idee e soluzioni in tutti i silos organizzativi. Gli ingegneri ed i team possono riusare le soluzioni interne ai problemi di prodotto, permettendo loro di focalizzarsi su flussi di lavoro di più alto valore per l’organizzazione.
