{"id":491,"date":"2014-09-30T21:30:40","date_gmt":"2014-09-30T19:30:40","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/giorno-della-dipendenza-poteri-e-pericoli-delle-soluzioni-esterne\/"},"modified":"2014-09-30T21:30:40","modified_gmt":"2014-09-30T19:30:40","slug":"giorno-della-dipendenza-poteri-e-pericoli-delle-soluzioni-esterne","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/giorno-della-dipendenza-poteri-e-pericoli-delle-soluzioni-esterne\/","title":{"rendered":"il giorno della dipendenza: poteri e pericoli delle soluzioni esterne"},"content":{"rendered":"

“Non possiamo semplicemente usare questo plugin?”. Negli esaltanti giorni degli anni 2000 in cui i CMS open source cominciavano a diventare molto popolari si sentiva spesso questa domanda, posta in maniera ottimistica, pieni di speranze riguardanti tutte quelle soluzioni che distavano da noi solo per un download. Nel corso degli anni abbiamo visto svilupparsi delle librerie sicure e delle community potenti, ma \u00e8 anche vero che continuano ad aumentare i cimiteri di codice abbandonato e servizi dimenticati. Molte di quelle soluzioni erano semplici da installare ma difficili da debuggare. Ad alcuni fornitori interessavano solo le vendite, non il supporto clienti.<\/p>\n

Anni dopo ci poniamo ancora la stessa domanda, ma siamo meno ottimisti e sempre pi\u00f9 dipendenti, e io ho paura quando mi trovo ad avere a che fare con chiunque che sia cos\u00ec intelligente da creare qualcosa che io non sono in grado di fare. La vera sfida per le piccole aziende che oggi si occupano di sviluppo \u00e8 sapere come controllare le relazioni fra le parti che offrono soluzioni esterne e quando evitare di ricorrervi. Vi mostrer\u00f2 il mio approccio, che consiste nel porsi un certo numero di domande.<\/p>\n

\n

Un web di soluzioni esterne<\/h2>\n

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

Il panorama delle soluzioni esterne \u00e8 in rapida espansione. Github \u00e8 cresciuto fino a raggiungere quasi i 7 milioni di utenti<\/a> e il repo di plugin di WordPress si sta avvicinando a 1 miliardo di download<\/a>. 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.<\/p>\n

Tuttavia, con cos\u00ec tante opzioni di terzi tra cui scegliere, ci sono pi\u00f9 occasioni del solito di deviare dalla rotta prestabilita.<\/p>\n<\/div>\n

\n

Cosa potrebbe andar storto?<\/h2>\n

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\u00e9 fare noi tutto questo lavoro”, dissi, “quando il problema \u00e8 gi\u00e0 stato risolto?”. La mia incoerenza era lampante. Essere dogmatici rispetto al non<\/em> usare una soluzione esterna non \u00e8 meglio che buttarsi a capofitto su un’altra e io ero riuscito ad essere entrambe le cose in un colpo solo!<\/p>\n

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.<\/p>\n

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

\n

La differenze tra un requisito e un obiettivo<\/h2>\n

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<\/em> stessero cercando di fare, fummo sorpresi: erano totalmente presi dalla funzionalit\u00e0 “typeahead”, mentre praticamente non percepivano il valore delle altre feature.<\/p>\n

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

Potrebbe sembrare un primo passo ovvio, ma ho visto progetti partire nella direzione sbagliata perch\u00e9 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.<\/p>\n<\/div>\n

\n

Sviluppare o scaricare?<\/h2>\n

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.<\/p>\n

Punti di forza e di debolezza<\/h3>\n

Il task della ricerca si allineava bene con i nostri punti di forza perch\u00e9 avevamo dei bravi front-end developer e avevamo le capacit\u00e0 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.<\/p>\n

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 \u00e8 roba da cervelloni, ma i cron task erno un particolare peso per noi.<\/p>\n

Miglioramenti del team<\/h3>\n

Quando ci esponiamo per ottenere un obiettivo per un cliente, c’\u00e8 in ballo qualcosa di pi\u00f9 del semplice lavorare: \u00e8 un’opportunit\u00e0 per il nostro team di migliorarsi imparando nuove skill. Le migliori opportunit\u00e0 per ottenere ci\u00f2 sono quelle che presentano dei task impegnativi ma raggiungibili, che creano crescenti ricompense<\/a>. Alcuni ricercatori<\/a> 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’\u00e8 un costo organizzativo nel perdere un’opportunit\u00e0 di essere pagati per imparare. Il progetto della ricerca typeahead ci sembrava l’opportunit\u00e0 perfetta per migliorare le nostre capacit\u00e0.<\/p>\n

Mission aziendale<\/h3>\n

Se un nuovo progetto \u00e8 in linea con la nostra mission, lo rivenderemo molte volte. Probabilmente, il nostro team di sviluppo in-house dovr\u00e0 fare alcune iterazioni su questo progetto per poterlo adattare ai nostri bisogni. E avremo davvero il budget per fare cos\u00ec 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<\/abbr> a questo. Di contro, molti altri clienti erano interessati a una ricerca sul sito pi\u00f9 potente, quindi ci sembrava tempo speso bene.<\/p>\n

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\u00f9 attentamente cosa succede di seguito in entrambe i casi.<\/p>\n<\/div>\n

\n

Valutare l’ignoto<\/h2>\n

La cosa frustrante del lavorare con soluzioni esterne \u00e8 che le decisioni pi\u00f9 importanti devono essere prese quando si hanno meno informazioni, ma ci sono alcune cose che possiamo determinare prima di impegnarci. La familiarit\u00e0, la vitalit\u00e0, l’estensibilit\u00f2, il branding e i Service Level Agreements (SLA) sono tutti osservabili da lontano.<\/p>\n

Familiarit\u00e0: c’\u00e8 un fornitore con cui abbiamo gi\u00e0 lavorato?<\/h3>\n

Sebbene andremo ad incrementare il numero di dipendenze<\/em> da soluzioni esterne, cercheremo di evitare il numero crescente di relazioni<\/em> con terzi.<\/p>\n

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.<\/p>\n

Vitalit\u00e0: questo servizio durer\u00e0?<\/h3>\n

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

Estensibilit\u00e0: questo servizio si adatter\u00e0 al variare delle nostre esigenze?<\/h3>\n

Non dobbiamo solo valutarne i servizi principali, ma dobbiamo anche vedere quanto \u00e8 estensibile analizzandone le API. Se un servizio \u00e8 estensibile, \u00e8 pi\u00f9 probabile che andr\u00e0 bene sul lungo corso.<\/p>\n

Le API possono anche presentare delle nuove opportunit\u00e0. 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\u00ec che i developer “in house” rimangano coinvolti ed entusiasti riguardo al servizio.<\/p>\n

Branding: il loro \u00e8 forte o potete usare il vostro?<\/h3>\n

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\u00f2 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.<\/p>\n

SLA: cosa ottenete, oltre all’uptime?<\/h3>\n

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

Nel caso del nostro servizio di aggregazione di feed, non c’erano altre soluzioni sul banco. Quella pi\u00f9 popolare in realt\u00e0 aveva un avviso di chiusura! C’erano a disposizione un paio di provider pi\u00f9 piccoli, ma non avevamo mai lavorato con nessuno di questi prima di allora. Il supporto dei browser e l’accessibilit\u00e0 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\u00e9 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\u00f9 produttive del titubare tra due soluzioni simili.<\/p>\n<\/div>\n

\n

Mantenimento delle relazioni<\/h2>\n

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

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.<\/p>\n

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.<\/p>\n

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\u00e9 stiamo usando un certo servizio o perch\u00e9 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.<\/p>\n

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.<\/p>\n

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

\n

Fai da te: una terza parte in attesa?<\/h2>\n

Fermatemi se avete gi\u00e0 sentito questa storia: uno sviluppatore orgoglioso assicura il team che una cosa simile pu\u00f2 essere fatta internamente. \u00c8 un progetto complesso. Crea qualcosa e l’azienda comincia a farci affidamento. Passa il tempo e il prodotto che \u00e8 stato realizzato internamente va bene, sebbene ci sia una certa quantit\u00e0 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 \u00e8 totalmente personalizzato, non c’\u00e8 nulla di simile ad una community.<\/p>\n

Una volta che si \u00e8 deciso di realizzare qualcosa internamente, in che modo si pu\u00f2 evitare che il lavoro devolva in una dipendenza che crea risentimento ed alienazione?<\/p>\n