Quando la partnership tecnologica diventa una condanna

La partnership strategica. Quel vincolo aziendale che trasforma qualsiasi decisione tecnologica in un obbligo morale, in un matrimonio combinato dove il progetto viene promesso a una tecnologia senza alternative, senza corteggiamento, senza compatibilità verificata.

“Siamo partner strategici di MegaCorpTech” è la frase che annulla ogni valutazione tecnica, ogni analisi dei requisiti, ogni considerazione pratica. Non importa cosa serva realmente al progetto, importa cosa può offrire il partner. La partnership diventa un vincolo assoluto che prevale su qualsiasi logica tecnica o economica.

Il vincolo che annulla ogni scelta

La logica è semplice: abbiamo firmato un accordo con MegaCorpTech, quindi ora dobbiamo usare tutti i loro prodotti. È come se, avendo comprato un frigorifero, ci si sentisse in dovere di riempire la casa di prodotti dello stesso marchio, dalla lavatrice al water.

Questo approccio ignora che ogni progetto ha esigenze specifiche. Non tutti i problemi si risolvono con gli stessi strumenti. Ma quando esiste una partnership, la domanda non è più “Quale tecnologia è più adatta?” ma “Come possiamo forzare la tecnologia del partner a fare quello che ci serve?”

I team devono contorcersi per adattare soluzioni quadrate in problemi tondi. Database scalabile per miliardi di transazioni? Usiamo il foglio di calcolo del partner ribattezzato “Enterprise Data Solution”. Sistema di messaggistica real-time? Il loro CRM può fare anche quello, con solo qualche personalizzazione estrema.

Il partnership contortionist

Questa dinamica ha generato una figura professionale: il partnership contortionist. Quell’architetto software che deve giustificare tecnicamente scelte che di tecnico non hanno nulla. Lo riconosci durante le riunioni: ha lo sguardo perso mentre pronuncia frasi come “Non è esattamente ciò di cui abbiamo bisogno, ma possiamo personalizzarlo… significativamente… completamente… praticamente riscriverlo da zero…”

Il ruolo richiede talento speciale: la capacità di presentare limitazioni come opportunità. “Questa piattaforma non supporta i nostri requisiti di scalabilità, ma questo ci darà l’occasione di ripensare completamente l’architettura”. Traduzione: passeremo i prossimi due anni a combattere con una tecnologia fondamentalmente inadeguata.

Il ciclo infinito dei problemi

Questa situazione genera un ciclo infinito. Prima si installa la tecnologia inappropriata. Poi si assumono consulenti, guarda caso della stessa azienda partner, per adattarla. Poi si comprano moduli aggiuntivi per colmare le lacune. Poi altri consulenti per integrare i moduli che non si parlano.

Alla fine ci si ritrova con un’architettura mostruosa. Strati su strati di personalizzazioni, integrazioni, workaround. Nessuno capisce più come funziona. Ogni modifica richiede analisi di impatto estenuanti.

Il costo supera di ordini di grandezza quello che sarebbe stato sviluppare una soluzione custom. Ma questo viene presentato come inevitabile. “È il prezzo dell’enterprise”.

Il disturbo post-traumatico da partnership

I team sviluppano disturbo post-traumatico da partnership. Sintomi: tic nervosi quando sentono il nome del partner, risate isteriche durante le presentazioni commerciali, scuse creative per evitare i workshop formativi.

Gli sviluppatori diventano cinici. Hanno visto la stessa storia: promesse grandiose, implementazione dolorosa, risultati deludenti. Lavorare con strumenti inadeguati è frustrante. La produttività crolla mentre si aggirano ostacoli che non dovrebbero esistere.

La celebrazione dell’inevitabile

Queste partnership vengono celebrate con eventi, comunicati stampa e foto di CEO sorridenti. “Siamo entusiasti di questa collaborazione che porterà innovazione!” Traduzione: “Abbiamo firmato un contratto che vi costringerà a usare tecnologie inappropriate.”

Gli annunci enfatizzano benefici vaghi. Si parla di “trasformazione digitale”, “eccellenza operativa”. Mai di dettagli su come queste tecnologie risolveranno problemi specifici. Le partnership hanno più valore simbolico che pratico.

Il rituale dello showroom

Non dimentichiamo la visita allo showroom del partner. I manager vengono portati nella sede luccicante dove tutto funziona perfettamente in demo preconfezionate senza attinenza con la realtà.

“Guardate come è facile implementare machine learning!” Certo, quando la supply chain consiste ancora in ordini faxati, il machine learning diventa prioritario. Le demo mostrano scenari ideali. La realtà è dati sporchi, processi caotici, sistemi incompatibili.

Il principio del martello universale

Le partnership dovrebbero essere come strumenti in una cassetta: usi il cacciavite quando serve, il martello quando serve. Invece, avere partnership con il produttore di martelli significa che ogni problema deve essere trattato come un chiodo.

Questa mentalità crea distorsioni enormi. I requisiti vengono adattati alle capacità della tecnologia. Si rinuncia a funzionalità essenziali perché la piattaforma non le supporta. Il risultato sono sistemi che non soddisfano le esigenze degli utenti.

Il ciclo infinito delle partnership

Dopo anni di contorsionismi, arriva la rivoluzione. Un nuovo CEO annuncia l’abbandono della vecchia tecnologia inadeguata e l’adozione di soluzioni moderne.

Indovinate? Sarà sostituita con la tecnologia di un nuovo partner strategico, ugualmente inadatta ma con logo più moderno. E così il ciclo ricomincia. La lezione non viene mai imparata perché chi decide non subisce le conseguenze.

Verso scelte tecnologiche razionali

Le partnership hanno senso quando creano valore reale. Sconti significativi, supporto prioritario, accesso a tecnologie altrimenti inaccessibili. Ma questo valore deve essere valutato progetto per progetto.

Serve il coraggio di dire: “Siamo partner, ma per questo progetto la loro tecnologia non è appropriata.” Serve cambiare la mentalità che vede le partnership come obblighi invece che come opzioni.

La prossima volta che sentite “Utilizzeremo questa tecnologia perché siamo partner di…”, preparatevi. State per imbarcarvi in un’avventura che farà sembrare l’Odissea una tranquilla gita. Ma almeno avrete penne brandizzate per consolarvi durante le notti di debugging.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT