A proposito del time to market

Cover image

A proposito del Time to market

Pare incredibile, ma in vent'anni di esperienza sul campo, in diversi mercati, uno dei problemi che più spesso mi è capitato di affrontare nei team di sviluppo di cui ho fatto parte è la gestione del tempo. Ovviamente, framework come SCRUM tendono ad aumentare il throughput obbligandoci a una maggiore focalizzazione, pragmaticità e pianificazione a breve termine e qundi ad arrivare a un time to market più veloce, predicibile e quindi remunerativo, ovviamente, tutto questo è vero se viene fatto bene (tutti insieme: e cerchiamolo 'sto margine, diamine). Anche in progetti in solitaria, R&D e tutta una serie di situazioni operative in cui non sempre ha senso strutturare un perfetto approccio SCRUM, ci viene in soccorso il pragmatismo, l'empirismo, ma proprio quello base base, barebones, insomma, come diceva mia nonna, "il sale in zucca", dai, un po' ce l'abbiamo tutti e non serve solo a destreggiarci sui motori di ricerca per trovare il porno migliore in rete.

La prima domanda che dobbiamo porci, quando affrontiamo qualsiasi task, deve essere sempre: "Può essere fatto più velocemente?", cercate, studiate, datevi il tempo per farlo e non nel senso indefinito che sembra avere questa frase, ma veramente: fissate una quantità di tempo per rispondere alla domanda, senza svaccare, ma fatelo e poi, questo know how, strutturatelo dentro a un componente (libreria, gem, pip, etc.) self contained, che riuserete sicuramente molto spesso.

L'osservazione in tanti anni di lavoro mi ha portato a identificare due metodi (e due problemi, vè che dualismo):

  1. quelli che, dato un progetto, uno sviluppo, piccolo o grande, partono a sprone battuto, senza chiedersi nulla.
  2. chi si pone LA DOMANDA (precedente, ndr), ma non fissando un tempo.

Entrambi svaccano, uno perchè si trova con una soluzione non modulare, l'altro perchè è ancora lì che cerca la perfezione. Non siate perfetti, ma pragmatici e fatevi aiutare dalle risorse esistenti integrabili nel vostro progetto, potreste imparare tantissimo.

Teniamolo sempre a mente, specialmente se sviluppate soluzioni custom: non perdiamoci. In ogni progetto personalizzato sbatterete sicuramente contro tecnologie che non conoscete, fissate un tempo preciso, che con l'esperienza saprete valutare sempre meglio e poi prendetevi quel tempo per cercare: github, gitlab, stackoverflow, sono piattaforme amiche e ogni volta che dovete fare qualcosa di nuovo. Chiedetevi se non sia già stato fatto prima, strutturatelo in voi stessi questo approccio, fatela vostra LA DOMANDA e fatevi un favore, non partite a sviluppare a testa bassa reinventando la ruota, so che lo facciamo tutti, è un istinto primordiale, un po' come per i lemmings, ma frenate la voglia di buttarvi dal dirupo e guardatevi intorno, dandovi un tempo preciso per farlo e vedrete che dopo potrete lanciarvi dal dirupo con più consapevolezza, magari quel paracadute trovato nella scuola di volo nel dirupo a fianco, renderà il vostro atterraggio meno faticoso, doloroso e splatter. E lo sappiamo da sempre, un software splatter è come un zombie: fa davvero paura, specialmente quando tocca riesumarlo e rimetterci le mani.

Ora, oltre che aver raggiunto un time to market più predicibile, avete anche un approccio più sano allo sviluppo, tutto però a una condizione: l'applicazione delLA DOMANDA e del tempo fissato deve diventare un mantra che scatta in automatico. Appena vi viene chiesto se sapete fare una cosa, non importa quanto piccola, anche il binomio Domanda&Effort è una best practice propedeutica allo sviluppo di applicazioni di qualità.

Stay KISS&DRY