Questa è una lettera aperta, oltre che un articolo. La rivolgo a tutti gli imprenditori che gestiscono aziende e startup tecnologiche e che hanno un team IT all’interno della loro azienda. È rivolto principalmente a voi, affinché capiate come si risolvono davvero i problemi che incontrate tutti i giorni.
Problemi come:
  • le deadline non vengono rispettate
  • i vostri dipendenti fanno resistenza ai cambiamenti
  • i budget che avevate previsto vengono superati
  • avete la sensazione che il team costi troppo per quello che produce
Ma questo “manuale” è rivolto anche ai CTO, ai capi dei reparti tecnici, che, costantemente, si trovano a dover combattere con mille difficoltà e problematiche che tendenzialmente la gente “comune”, cioè i non tecnici, non capisce. Vuole essere un punto di incontro tra imprenditori e sviluppatori. Il mio obiettivo è che ci capiamo una volta per tutte su cosa va fatto e cosa no, in modo da evitare incomprensioni e vivere felici e…produttivi.
Queste incomprensioni tra la parte non tecnica e la parte tecnica dell’azienda genera emozioni negative, di frustrazione soprattutto, da entrambi i lati. Rende irritabili le persone che dipendono dal team IT, cioè tutte quelle persone che dai tecnici si aspettano qualcosa ( come una funzionalità o che un big venga risolto ) e rendono infelici i tecnici, che vorrebbero lavorare con un metodo e con una struttura ben precisi, ma che per svariati motivi, non riescono ad ottenerli.
Vediamo insieme quali sono queste dinamiche e come possiamo intervenire efficacemente per risolverle in modo brillante.

Fare i conti con la dura realtà

 
Il problema degli imprenditori è che non riescono ad ottenere, cioè a far realizzare dai tecnici, quello che loro hanno in mente. Un imprenditore di solito ha delle idee, più o meno brillanti ( ma pur sempre delle idee ) che vuole provare ad applicare per migliorare il suo business. Nelle startup e nelle aziende tecnologiche, questo desiderio di realizzare delle cose, si trasforma in richieste che vengono portate al team tecnico. Facciamo un esempio:
  • Al CEO viene in mente l’idea di voler implementare una nuova funzionalità per i siti e-commerce che vende ( rimaniamo nell’ambito dei siti e-commerce, che è il focus di questo blog ). Decide che è un’ottima idea automatizzare le richieste di resi e rimborsi per tutti i siti che vende e decide quindi di far realizzare questa funzionalità al team tecnico. Il cliente finale del sito e-commerce, potrà quindi richiedere un rimborso o un reso tramite un apposito form, in modo che la richiesta arrivi al customer service già nella categoria giusta e non nel calderone di tutte le altre e-mail
Quale è il problema in un processo del genere? Processo che sulla carta dovrebbe essere molto semplice?
Idea -> richiesta al team tecnico -> realizzazione
Cosa, in questo semplicissimo processo ( almeno in apparenza ), non funziona?
Il problema della realtà. Che cosa sarebbe?
Lo chiamo così perché è la cosa che penso quando rifletto sui problemi tipici che si incontrano.
Come di consueto, il cliente vuole che la funzionalità venga realizzata in fretta. La piattaforma esiste, mettiamo caso, da un anno ( per comodità, facciamo finta che sia un e-commerce basato su Magento ).
Problema numero 1: iniziare con il piede sbagliato e volerlo online e funzionante “per ieri”
Il problema numero 1 è già evidente, almeno per gli sviluppatori. Ma lo spiegherò in modo comprensibile per tutti, cosi ci capiamo.
Le persone spesso non sono capaci di programmare una serie di interventi, perché le aziende sono in continua evoluzione e pianificare a volte è difficile. L’imprenditore, in particolare, non è in grado di farlo, perché preso da mille problematiche diverse che deve risolvere tutti i giorni. Tra tasse, pagamenti che non arrivano in tempo dai clienti, dipendenti stupidi e che si mettono di traverso, deve fare mille cose diverse.
Tuttavia, cosa succede in questo caso? Che la richiesta viaggia più veloce della luce nella casella di posta del CTO di turno, che vede scritto:
“urgente!!! da fare subito!!!”
Il CTO, quindi, può intervenire in soli 2 modi.
  1. può rifiutare la richiesta di realizzare la funzionalità subito, dicendo che le cose vanno programmate ( ed avrebbe tutte le ragioni ). Quindi propone una data nella quale il team tecnico sviluppa e consegna la nuova funzionalità
  2. può chinare il capo ed acconsentire senza fare troppe discussioni
Come credete che andrà a finire la maggior parte delle volte?
Esatto, finisce sempre nel modo numero 2.
Questo modo di fare, proviene di solito da lontano, da quando il CTO ha iniziato a fare il CTO.
Scenario: immaginate un programmatore di esperienza, che diventa CTO e ha un unico desiderio in mente: non deludere il capo. Nella sua testa, in quel momento, comincia a formarsi l’idea che il capo possiede delle qualità che non è detto abbia realmente, qualità come:
  • sapere quello che davvero vuole
  • sapere quello che davvero serve
  • sapere se una cosa è davvero fattibile nei tempi che vuole lui
  • sapere come funziona la SUA piattaforma e-commerce e fin dove può spingersi senza dover riscrivere mezza piattaforma
Purtroppo spesso non è così. Cari programmatori, dovete sapere che il vostro capo non è un tecnico ed è già tanto se comprende come funziona la casella di posta. Con tutto il rispetto per i miei CEO attuali, che invece sono molto più avanti di così. Ma loro sono più un’eccezione che la regola.
Il problema, quindi, è che già dall’inizio, il CTO imposta in modo errato il rapporto di lavoro.
Sarebbe come dire che il CTO abitua male il suo capo fin da subito, concedendogli modi di fare errati dal primo giorno.
Vanno invece stabilite da subito delle regole, come ad esempio:
  • gli interventi vanno programmati, non richiesti per essere realizzati il giorno stesso della richiesta
  • il codice va scritto bene e con le best practices il più possibile, perché se questo non accade, con il passare del tempo, la piattaforma diventa una sorta di “Frankenstein” che altro non è che un’accozzaglia di cose scritte male e, nel momento in cui la piattaforma deve scalare, cioè deve ingrandirsi e deve farlo anche velocemente, diventa un bagno di sangue
Per favore, CTO: impuntatevi. Stabilite da subito le regole del gioco e nessuno si farà male.

Problema numero 2: scontrarsi con la realtà

Il problema numero 2 che hanno molti imprenditori è: questa cosa va fatta, non importa come, ma va fatta per oggi.
Non sempre la risoluzione del problema sta nelle tempistiche: una cosa può anche essere fatta per oggi, basta avere a disposizione i mezzi necessari, cioè una “potenza di fuoco” sufficiente a coprire il fabbisogno di velocità per la realizzazione di un task.
Caro imprenditore: lo so che vuoi fare il più possibile con i tuoi soldi, lo farei anche io. Ma appunto, bisogna fare il possibile.
Tutte le cazzate che vi raccontate sul famoso collaboratore che fa l’impossibile o sul fatto che riuscite a lavorare anche di notte,
e che comunque fate tutto in modo eccellente, sono solo delle grosse strozzate.
Lasciatemelo dire senza paura di smentita ( e vi invito a dimostrare il contrario ): chi lavora tanto, lavora male. Fa un sacco di errori.
Nessuno, per definizione, può fare l’impossibile. Spero che fin qui siamo tutti d’accordo ( altrimenti devi necessariamente aprire il primo dizionario disponibile e studiare un po’ ).
Quindi rimane solo: il possibile. Ora, seguitemi nel ragionamento, che sono sicuro potete capire anche voi imprenditori questa cosa.
Se io, programmatore o team tecnico che sia, ho un compito da svolgere, devo valutare alcune cose, come:
  • cosa c’è da fare
  • in quanto tempo la cosa è fattibile con le risorse che posso allocare
Ad esempio, se è un task è realizzabile in 3 giorni di lavoro, di sicuro non sarà possibile farlo in 2.
Ma allora perché alcuni di voi ( ho sentito personalmente dire queste cose ), pensano che si debba
comunque trovare una soluzione?
“Devi farlo lo stesso”.
Mi sanguinano le orecchie quando sento queste cose!
Come diavolo si fa in 2 giorni, una cosa che ne richiede per forza 3? Ora, ammettendo che lo sviluppatore sa fare le stime e non abbia esagerato ( caso in cui invece è ovvio che si può ridurre il tempo ). Se ce ne vogliono 3, ce ne vogliono 3. Se riesci a farlo in 2, vuol solo dire che avevi stimato male all’inizio abbondando sui tempi, non che sei riuscito a fare in 2 una cosa da 3 giorni.
Chiaro, no?
Lo dico io perché parlate cosi ( e mi riferisco a voi imprenditori ): perché pensate che le persone possano sempre dare di più, sforzarsi ancora, fare delle ore extra, farsi il culo, lavorare anche di notte.
Ma cari imprenditori, vi rivelo un segreto: se la vostra piattaforma è uno schifo è proprio perché avete sempre ragionato cosi, invece che con la testa.
Spero di essere stato abbastanza chiaro! Perché qui le cose bisogna chiarirle per bene.
Se ci metto 2 giorni a fare una cosa che ne richiedeva 3, non sono stato bravo io che l’ho realizzata e nemmeno tu che mi hai spinto a farlo.
Siamo solo un tizio che esegue ordini ( io ) e un tizio ( tu ) che non sai quello che stai facendo.
Perché sicuramente il lavoro è venuto male. Perché per farlo in meno tempo, ho dovuto sacrificare qualcosa. Di solito si sacrifica:
  • qualità del codice
  • possibilità di scalare in futuro riutilizzando quel pezzo di codice
  • qualità del prodotto finale ( ad esempio: il frontend )
Capisco i discorsi sulla velocità: bisogna essere leggeri e fare le cose in modo veloce. È giusto, quando sei una startup.
Ma quando sei un’azienda con anni di storico alle spalle, questa cosa diventa solo un alibi per non investire in un lavoro
fatto davvero bene. E anche in una startup, bisogna fare molta attenzione a produrre cose che funzionano.
Lo ripeto: cose che funzionano. Nessuno è contento se consegnate un sito che funziona così così.
Alla fine con chi ve la prendete? Con il reparto tecnico, ovviamente.
Questa storia deve finire, dovete farvi un minimo di cultura tecnologica e di sviluppo,
perché queste azioni sono deleterie su più fronti: sia per la vostra azienda, che per gli sviluppatori,
che, se hanno un po’ di talento, presto vi manderanno a quel paese, trovando altri lidi in cui “divertirsi” con la programmazione.
Chiaro il concetto?

Ma allora quale è la soluzione?

Se c’è una cosa che ho imparato è che esistono sempre svariate soluzioni. Il problema è che a volte non ce ne accorgiamo.
La mia personalissima esperienza riguarda l’agile development, nel particolare ho utilizzato il framework Scrum.
Ma attenzione: sento dire da alcune azienda cosa tipo
“Anche io uso Scrum, io lo so già usare.. però non ho visto una gran differenza”
Beh, se non stai facendo una gran differenza, vuol dire che non lo stai usando correttamente.

Quali risultati ho ottenuto ( e puoi ottenere anche tu )

Cominciamo con il dire una cosa: non esiste la soluzione che prendi e usi senza modificare.
Scrum è un sistema potente, ma che va adattato. Infatti, sotto alcuni aspetti è molto rigido e,
il creatore stesso, Jeff Sutherland, dice che va adattato al tuo contesto e azienda in cui lavori.
Nel momento in cui scrivo, sto applicando nella mia attuale azienda Scrum da qualche settimana.
I risultati ottenuti in poco tempo sono davvero incoraggianti.
  • La realizzazione della grafica ( UX/UI ) dei siti e-commerce che produciamo è passata da 4 a 3 settimane, con un netto miglioramento della qualità sia in fase di grafica, che in fase di prodotto rilasciato al team tecnico
  • La realizzazione dello sviluppo frontend è passato da 1 mese e mezzo circa a 3 settimane +1 di check e bug fixing
  • La digitalizzazione dell’azienda cliente è passata da mesi a poche settimane
  • Ho progettato ed implementato procedure che sono state ingegnerizzate e standardizzare per essere adattate ad un miglioramento di tipo iterativo, proprio per migliorarle costantemente con il metodo Scrum

Come puoi migliorare da domani anche tu nel tuo team e nella tua azienda

Se hai la necessità di dare una sterzata decisa e raddrizzare le cose in azienda, puoi contattarmi scrivendo nell’oggetto “Aiuto Scrum”.
Sarò ben lieto di offrirti aiuto specifico per la tua azienda o per il tuo team!