il giorno della dipendenza: poteri e pericoli delle soluzioni esterne

Un web di soluzioni esterne#section1

Vorrei cominciare con una definizione piuttosto generica su cosa significhi essere una “soluzione esterna”: se è una persona e non le dò un compenso per il suo intero lavoro, si tratta di una soluzione esterna. Se è un’azienda o un servizio che non controllo, si tratta di una soluzione esterna. Se è codice e il mio team non è in grado di capirne tutte le righe, si tratta di una soluzione esterna.

Il panorama delle soluzioni esterne è in rapida espansione. Github è cresciuto fino a raggiungere quasi i 7 milioni di utenti e il repo di plugin di WordPress si sta avvicinando a 1 miliardo di download. Molte di queste soluzioni possono essere implementate semplicemente da clienti e competitor. Nel frattempo, io sono ancora nel mio laboratorio a debuggare il mio codice creato su misura. L’idea di vendere lavoro originale sembra stranamente fuori moda.

Tuttavia, con così tante opzioni di terzi tra cui scegliere, ci sono più occasioni del solito di deviare dalla rotta prestabilita.

Cosa potrebbe andar storto?#section2

Un paio di anni fa, durante una riunione, portai degli argomenti contro la decisione di utilizzare un servizio esterno per gestire la widget di ricerca di un progetto per un cliente. “Dovremmo fare noi stessi le cose”, dissi. Non molto tempo dopo, sempre per quello stesso progetto, portai argomenti a favore dell’uso di una soluzione esterna per aggregare i feed RSS in un singolo documento. “Perché fare noi tutto questo lavoro”, dissi, “quando il problema è già stato risolto?”. La mia incoerenza era lampante. Essere dogmatici rispetto al non usare una soluzione esterna non è meglio che buttarsi a capofitto su un’altra e io ero riuscito ad essere entrambe le cose in un colpo solo!

Ma in quel caso, pensavo che valesse la pena di correre il rischio. Nell’altro pensavo non fosse il caso. Semplicemente non sapevo come comunicare questi pensieri al mio team.

Avevo bisogno, nel gergo dei giorni nostri, di un framework di decision-making. Per tale scopo, mantengo un elenco di punti a cui far riferimento nei vari stage di coinvolgimento con le soluzioni esterne. Vi elencherò queste idee usando come esempi la widget di ricerca e l’aggregatore di RSS.

La differenze tra un requisito e un obiettivo#section3

Questo punto spesso rivela false assunzioni riguardo a quello che vuole un cliente o uno stakeholder. Nel caso della widget di ricerca, cominciammo col fare delle indagini su un servizio che ci era stato specificatamente richiesto dal nostro cliente. Sembrava decisamente all’altezza del compito avendo la navigazione ajax, la ricerca “full text” e crwal automatizzati per indicizzare il contenuto. Ma quando chiedemmo ai nostri clienti che cosa esattamente stessero cercando di fare, fummo sorpresi: erano totalmente presi dalla funzionalità “typeahead”, mentre praticamente non percepivano il valore delle altre feature.

Nel caso dell’aggregatore di RSS, avevamo già uno strumento prodotto da noi che prendeva un array di URL di feed e girava ordinatamente tra questi, dando in uscita x post per feed in un formato su misura. Erano troppo buoni per la nostra amata widget multi-feed? In realtà, il cliente aveva una visione completamente differente e valida: volevano x risultati in totale da tutti i loro siti e li volevano ordinati per data di pubblicazione, non per sito. Cedetti.

Potrebbe sembrare un primo passo ovvio, ma ho visto progetti partire nella direzione sbagliata perché non si conosceva l’obiettivo finale. A questo punto, per entrambe i nostri esempi, abbiamo chiaro lo scopo e siamo pronti a valutare delle soluzioni.

Sviluppare o scaricare?#section4

Prima di decidere di usare una soluzione esterna, trovo di dover innanzitutto esaminare la mia organizzazione, spesso in quattro modi particolari: punti di forza, punti deboli, miglioramenti e mission.

Punti di forza e di debolezza#section5

Il task della ricerca si allineava bene con i nostri punti di forza perché avevamo dei bravi front-end developer e avevamo le capacità per estendere il nostro CMS. Quindi, quando ci fu chiesto di fare la ricerca typeahead, eravamo sereni scommettendo su noi stessi. L’avevamo fatto prima? Non proprio, ma potevamo arrivarci.

In quello stesso momento, l’infrastruttura di backend era un punto debole del nostro team. Avevamo avuto parecchi sysadmin e a volte sembrava che non fossimo in grado di assumere quel tipo di talento. Mentre pensavo a come avremmo potuto creare un aggregatore di feed per conto nostro, mi sembrava di toccare un nervo scoperto. Forse avremmo dovuto impostare un cron job per fare il poll degli URL desiderati, prendere i contenuti del feed e memorizzarli sui nostri server. Non è roba da cervelloni, ma i cron task erno un particolare peso per noi.

Miglioramenti del team#section6

Quando ci esponiamo per ottenere un obiettivo per un cliente, c’è in ballo qualcosa di più del semplice lavorare: è un’opportunità per il nostro team di migliorarsi imparando nuove skill. Le migliori opportunità per ottenere ciò sono quelle che presentano dei task impegnativi ma raggiungibili, che creano crescenti ricompense. Alcuni ricercatori citano questo effetto come un fattore della dipendenza da gioco. L’ho sentito io stesso quando stavo imparando cose nuove durante un progetto e quelli sono alcuni dei miei momenti lavorativi preferiti. I team li apprezzano e c’è un costo organizzativo nel perdere un’opportunità di essere pagati per imparare. Il progetto della ricerca typeahead ci sembrava l’opportunità perfetta per migliorare le nostre capacità.

Mission aziendale#section7

Se un nuovo progetto è in linea con la nostra mission, lo rivenderemo molte volte. Probabilmente, il nostro team di sviluppo in-house dovrà fare alcune iterazioni su questo progetto per poterlo adattare ai nostri bisogni. E avremo davvero il budget per fare così se lo venderemo molte volte. Nessuno ci aveva mai chiesto un aggregatore di feed prima d’ora, quindi non ci sembrava ragionevole dedicare un budget per R&D a questo. Di contro, molti altri clienti erano interessati a una ricerca sul sito più potente, quindi ci sembrava tempo speso bene.

A questo punto, ci siamo chiariti i nostri obiettivi finali e abbiamo visto in che modo questi progetti si allineano con il nostro team. Basandoci su questo, stiamo creando noi stessi la widget di ricerca e stiamo dando in outsourcing l’aggregatore di feed. Adesso osserviamo più attentamente cosa succede di seguito in entrambe i casi.

Valutare l’ignoto#section8

La cosa frustrante del lavorare con soluzioni esterne è che le decisioni più importanti devono essere prese quando si hanno meno informazioni, ma ci sono alcune cose che possiamo determinare prima di impegnarci. La familiarità, la vitalità, l’estensibilitò, il branding e i Service Level Agreements (SLA) sono tutti osservabili da lontano.

Familiarità: c’è un fornitore con cui abbiamo già lavorato?#section9

Sebbene andremo ad incrementare il numero di dipendenze da soluzioni esterne, cercheremo di evitare il numero crescente di relazioni con terzi.

Lavorare con un venditore che conosciamo ha molti benefici potenziali: possono farci un prezzo di favore. Il markup e gli stili probabilmente saranno consistenti tra le varie soluzioni. E li conosciamo meglio di quanto non conosceremmo un nuovo servizio.

Vitalità: questo servizio durerà?#section10

La cosa peggiore che possiamo fare è affidarci a un servizio solo per vederlo chiudere il mese successivo. Un servizio con una grande vitalità probabilmente (e con ogni diritto) vanterà dei grossi clienti tra le sue fila. Se è open source, ci sarà una community appassionata di contributor. Oppure, potrebbe pubblicizzare una chiusura. Più spesso, la verità si trova nel mezzo: osservate la frequenza con cui viene aggiornato il servizio, è un buon punto di partenza per determinarne la vitalità.

Estensibilità: questo servizio si adatterà al variare delle nostre esigenze?#section11

Non dobbiamo solo valutarne i servizi principali, ma dobbiamo anche vedere quanto è estensibile analizzandone le API. Se un servizio è estensibile, è più probabile che andrà bene sul lungo corso.

Le API possono anche presentare delle nuove opportunità. Per esempio, immaginate di selezionare un provider di email marketing con una API che espone i dati della campagna. Questo potrebbe permetterci di creare una dashboard per la performance della campagna nel nostro CMS: un valore aggiunto unico per i nostri clienti e una chance per far sì che i developer “in house” rimangano coinvolti ed entusiasti riguardo al servizio.

Branding: il loro è forte o potete usare il vostro?#section12

Si definisce “white-labeling” la pratica di rivendere un servizio con il vostro brand invece di quello del provider originale. Per alcune aziende questa pratica può avere senso per il marketing. In generale, a me non piace il white-labeling. I nostri clienti si fidano delle scelte che facciamo e dovremmo essere orgogliosi di mostrare quali sono queste scelte. In ogni caso, dovrete essere sicuri di essere a vostro agio con il brand che userete.

SLA: cosa ottenete, oltre all’uptime?#section13

Per i prodotti client-side, un fattore importante è quello del browser support: ogni dipendenza esterna rappresenta un altro layer che può aver abbandonato i browser più vecchi prima che voi abbiate deciso di farlo. Va considerata anche l’accessibilità: questa nuova soluzione esterna supporta gli utenti che hanno bisogni riguardanti l’accessibilità al livello che richiediamo? Ma forse l’aspetto più importante di tutti è il supporto. Possiamo acquistare un piano di supporto prioritario che offra aiuto rapido e accurato?

Nel caso del nostro servizio di aggregazione di feed, non c’erano altre soluzioni sul banco. Quella più popolare in realtà aveva un avviso di chiusura! C’erano a disposizione un paio di provider più piccoli, ma non avevamo mai lavorato con nessuno di questi prima di allora. Il supporto dei browser e l’accessibilità erano irrilevanti dal momento che avremmo fatto noi il parsing dei dati e la relativa visualizzazione. Il discorso dell’uptime era anch’esso ridotto perché ci saremmo assicurati di mettere in cache localmente i risultati. Comunque, con dei possibili candidati a portata di mano, potevamo spostare la nostra attenzione su questioni più produttive del titubare tra due soluzioni simili.

Mantenimento delle relazioni#section14

Se qualcun altro si occuperà della maggior parte del lavoro, voglio farmi carico quanto più possibile di tutto quel che manca. La gestione, la raccolta dati, la documentazione e il supporto in-house sono tutte ottime opportunità per rafforzare questa nuova relazione.

Per quanto possa essere esaltante questa nuova relazione, non dobbiamo partire in quarta. Al contrario, ci rivolgeremo ai clienti per guidarli e metterli in quarantena prima di lasciarla partire. Raccogliete i suggerimenti dai membri del team per determinare i candidati corretti per la fase pilota, mettendo insieme un mix di casi limite e normali.

Se la soluzione esterna dovesse raccogliere dati di qualsiasi tipo, dovremmo anche avere un modo automatizzato per importarne una copia, non solo come backup, ma anche come versione “cached” che possiamo utilizzare per ridurre al minimo la latenza. Se siamo dipendenti da un CDN per un servizio popolare, dobbiamo mandare una versione locale nel caso in cui la chiamata dovesse fallire.

Se il nostro team non ha un elenco di relazioni navigate con il fornitore, l’antefatto potrebbe andare perso. Lasciati passare alcuni mesi e un turnover del personale e potremmo dimenticare perfino perché stiamo usando un certo servizio o perché abbiamo scelto un pacchetto specifico. Tutte le persone del nostro team dovrebbero sapere dove e come apprendere cose riguardanti le relazioni con chi gestisce le soluzioni esterne.

Non serve che ogni membro del team sia un esperto del servizio, ma non dobbiamo aspettare che lo staff di supporto della terza parte risponda a domande semplici. Pertanto, dovremmo eleggere internamente un esperto di questa materia. Non deve essere per forza un developer. Abbiamo solo bisogno di qualcuno che abbia il compito di monitorare il servizio a intervalli regolari per verificare se ci sono cambiamenti nelle API, degli avvisi di shutdown o delle nuove feature. Dovrebbero essere in grado di addestrare nuovo personale e instradare richieste di supporto complesse alla terza parte.

Nel nostro esempio del feed RSS, sapevamo che avremmo letto il loro output nel nostro database. Avevamo documentato questa relazione nella bacheca elettronica più attiva del nostro team, il nostro software CRM. E abbiamo fatto in modo che la gestione delle dipendenze esterne diventasse una parte primaria del lavoro di uno dei membri del team.

Fai da te: una terza parte in attesa?#section15

Fermatemi se avete già sentito questa storia: uno sviluppatore orgoglioso assicura il team che una cosa simile può essere fatta internamente. È un progetto complesso. Crea qualcosa e l’azienda comincia a farci affidamento. Passa il tempo e il prodotto che è stato realizzato internamente va bene, sebbene ci sia una certa quantità di lavoro di mantenimento da fare. Alla fine, lo sviluppatore se ne va dall’azienda. Il loro vecchio prodotto richiede manutenzione, nessuno sa cosa fare e, dal momento che è totalmente personalizzato, non c’è nulla di simile ad una community.

Una volta che si è deciso di realizzare qualcosa internamente, in che modo si può evitare che il lavoro devolva in una dipendenza che crea risentimento ed alienazione?

• Considerate il pair-programming. C’è un modo migliore per essere sicuri che più persone comprendano un prodotto di mettere più persone a crearlo?
• “I martedì dello scambio di lavoro”. Quando è possibile, facciamo in modo che gli sviluppatori si scambino il proprio ruolo per un intero giorno. Letteralmente, nel nostro sistema di ticketing, è come se una persona fosse un’altra. È un modo per forzare il cross-training senza duplicare le ore necessarie per un compito.
• Fate delle revisioni del codice prima di fare il push del nuovo codice. Sulle prime potrebbe sembrarvi piuttosto intrusivo, ma poi passa. Se non è leggibile non si può farne il deploy. Se avete dei project manager con conoscenze tecniche, permettegli di fare anche domande riguardo al codice.
• Portate alla luce il codice poco chiaro mostrandolo come phpDoc, JSDoc o qualcosa di simile.
• Attenti al grande. Create delle stime orarie come incrementi della serie di Fibonacci. Al crescere del progetto, cresce il suo livello di incertezza. Gli step di Fibonacci evitano che si sottostimi il budget e forniscono anche una chiave per chiamarsi fuori dai progetti che sono troppo difficili da stimare. In quel caso, è probabilmente meglio puntare a una soluzione esterna piuttosto che avventurarsi per sentieri oscuri da soli.

Tutte queste considerazioni si applicano al nostro precedente esempio, quello della widget di ricerca typeahead. Il più appropriato è il consiglio “fate attenzione alla grandezza”. Quando dico “grande”, lo intendo relativamente a quello che di solito funziona per un dato team. In questo caso, era un deliverable che sembrava molto familiare per dimensione e portata: ci era stato chiesto di estendere un CMS open source. Se invece ci avessero chiesto di fare un CMS, si sarebbero spente le sirene di allarme.

Guardate prima di saltare e dopo essere atterrati#section16

Non è che le soluzioni esterne siano cattive di per sé. È solo che il moderno web team mi sembra uno strano posto: non solo sediamo sulle spalle dei giganti, ma lo facciamo senza prima prenderci la briga di conoscerli, e mettiamo lassù anche le nostre aziende e i nostri clienti.

Ovviamente, ci sono molte cose che non dovreste fare da soli e c’è la possibilità che danneggereste la vostra azienda cercando di farle: NIH (Not Invented Here) è un problema, non un obiettivo. Ma quando i team errano troppo nella direzione opposta, gli sviluppatori vengono privati di un diritto, i componenti iniziano a sembrare pezzi di ricambio e i clienti pagano per soluzioni che non sono propriamente giuste. Usare una soluzione esterna piuttosto che sviluppare in-house è una grande decisione e dobbiamo rifletterci bene prima di decidere. Usate la mia serie di domande o fatevene una adatta al vostro team. Dopo tutto, siete voi la vostra miglior dipendenza.

Illustrazioni: {carlok}