Compromessi e non soluzioni

Nenhuma nota no slide

Il talk non vuole insegnare una metodologia di lavoro, nasce da esperienze personali e si riflette su situazioni personali. Non è detto che la strada intrapresa sia la migliore, la più agevole o la più redditizia. E’ semplicemente una strada che porterà, probabilmente, ad un nuovo percorso di crescita, di adattamento e di revisione.

C’erano una volta tre sviluppatori freelance, anzi un sistemista, uno sviluppatore puro ed uno più vicino alla figura di consulente. I tre, che già collaboravano da tempo, decisero di unire le forze e crescere professionalmente, insomma di fare impresa.

Anche se i tempi erano non sospetti il germe dei processi lean stava già maturando e decisero, anche come vuole la sana arte dell’arrangiarsi, di iniziare in piccolo. Coprendo loro stessi figure che non avrebbero potuto permettersi di assumere (e pagare) oltre al lavoro vero. Come se, nella loro concezione, queste figure (o almeno due di queste), non facessero in realtà nulla di particolarmente rilevante.

Il primo che prese la parola fu il sistemista: “tanto sono solo log”, esclamò guardando bilanci e buste paga. “Se riesco a leggere quelli di sendmail non vedo perchè non dovrei poter leggere questi ed interpretarli in modo da analizzare e tenere sott’occhio il nostro flusso di cassa.” E così affiancò al suo essere sistemista l’essere il responsabile finanziario.

Lo sviluppatore puro, che aveva già lavorato seguendo metodologie agili, disse che per lui (e per l’azienda) la cosa importante era poter garantire in qualsiasi momento qualità del codice e controllo sullo stesso. Decise quindi di fare il CTO di formarsi ulteriormente con il supporto di un coach, in modo da poter permettere all’azienda di avere una figura che formasse ed indirizzasse il, futuro, team di sviluppo.

Il consulente, invece, che aveva già lavorato come responsabile ITC in una piccola impresa, aveva competenza nel gestire clienti e fornitori e, soprattuto, una buona rete di conoscenze si propose come commerciale tecnico. “Non voglio essere uno di quelli che vende aria fritta, voglio aiutare i nostri futuri clienti a fare la scelta giusta.” Disse, e iniziò a studiare il mercato per capire che direzione far prendere all’azienda.

Questa è la storia di come un tecnico si è, lentamente, trasformato in un commerciale (anche se atipico).

Il primo approccio che il neo-commerciale decise di avere con il suo nuovo ruolo fu molto zen. “Aumenterò la visibilità mia e dell’azienda ed aspetterò che i clienti si facciano vivi da soli.” ed effettivamente funzionò,

ma tutti i nuovi clienti in un modo o nell’altro gli rinfacciavano il fatto di non essere un commerciale. Non parlava come un commerciale, non era affabulatore come un commerciale, e soprattutto non cercava di vendere nulla che non fosse effettivamente necessario. Insomma, la sua credibilità da tecnico era superiore a quella da commerciale e la cosa dava fastidio, in qualche modo a lui ignoto, ai clienti.

Decise quindi che avrebbe dovuto studiare cosa significa essere un “agente di vendite” e quale era il modo più “consono” per portare avanti il proprio incarico. Lesse quindi libri squisitamente etici che gli spiegavano come sfruttare le insicurezze del proprio cliente per mostrargli il superfluo come necessario, e venderglielo, o che spiegavano come approcciarsi al cliente, come parlare o cosa dire per catturarne l’attenzione e le simpatie.

Insomma sarebbe dovuto diventare una figura a metà tra Sberla dell’A-team e Stan di Monkey Island. I valori dell’agile c’erano tutti... ma leggermente distorti. Il coraggio come faccia tosta, la comunicazione come dialettica, il feedback come strumento di controllo. Ma soprattutto il rispetto, per il team e/o per il cliente, non era contemplato.

Data natura del nostro eroe, brutalmente, pragmatica e (tendenzialmente) onesta (potremmo definirlo legale neutrale) tutto questo gli provocò non pochi bruciori di stomaco.

Fortunatamente, ciò non era necessario ad essere un bravo commerciale (ma solo ad essere un eccellente commerciale). Ciò che era veramente indispensabile era conoscere il proprio dominio di competenza, il mercato nel quale ci si muove per adattarsi ad esso ed alle richieste dei clienti.

Inoltre è necessario essere veloci nel dare risposte, ma pazienti nell’ottenerle.

Un altro fattore determinante scoprì essere la capacità di dare certezze al cliente, daltronde chi vorrebbe comprare una macchina che forse funziona? O un biglietto aereo per un probabile volo? I clienti vogliono essere rassicurati, cullati con promesse di futuri radiosi e progetti entusiasmanti. Vogliono prodotti che gli risolvano i problemi.

Prodotti.. purtroppo l’azienda aveva come unico prodotto “il servizio” di sviluppo applicativi. Come avrebbe potuto vendere servizi che per di più non erano stimabili a priori?

Nello sconforto più totale decise di partecipare ad eventi e conferenze sul mondo agile per trovare una risposta. Ma l’unica cosa che ottenne fu un ulteriore senso di smarrimento vedendo che la maggior parte delle altre aziende viveva la sua stessa situazione.

Come posso fare un preventivo se gli story points non sono associabili a giorni di lavoro, ore, o qualsiasi cosa fatturabile? Come posso chiedere un budget al cliente se non so cosa effettivamente andrò a realizzare per quest’ultimo nei prossimi 6 mesi? E soprattutto è giusto mappare un processo di lavoro relativo alla creazione, ed evoluzione, di prodotti per una azienda di servizi?

Infine cosa sono i clienti? Spesso non hanno nessun background tecnico, non sono i fruitori finali del prodotto e non hanno tempo e possibilità di entrare nel processo di sviluppo. Ogni cliente ha una propria sensibilità/attitudine al lavoro che va rispettata. Non è quindi possibile applicare una metodologia unica di lavoro per tutti i clienti.

Con questi, ed altri, quesiti decise di affrontare il problema da un’altra prospettiva. Decise quindi di gestire il processo di vendita come una trattativa. Una mediazione tra l’aspettativa del cliente e la rigidità metodologica del team di sviluppo. Tra il tutto e subito del primo al poco per volta del secondo. Tra un voglio un costo preciso ed il non posso stimarlo.

Il primo passo che avrebbe compiuto sarebbe stato quindi quello di ribaltare il processo di vendita non presupponendo posizioni ben definite (tu cliente, io fornitore) ed, anzi, di proteggere il cliente dal team di sviluppo. Per far ciò avrebbe però dovuto, con il cliente, lavorare sulla separazione tra l’effettivo problema da preconcetti e desiderata ininfluenti allo scopo finale e di guidare, dove e quando possibile, il cliente stesso in un processo di “riduzione ed oggettivizzazione del problema”.

E’ quindi un processo euristico che si conclude solo con l’accettazione da ambo le parti di un processo di lavoro comune. UNA TRATTATIVA. Questo permise, inoltre, di far capire al commerciale quali clienti, o quali progetti, potevano essere validi per la propria impresa e quali invece dovevano essere indirizzati ad altri lidi. Evitando lo spreco di mettere il team di sviluppo in possibili progetti fallimentari.

“E’ poco da commerciale”, gli fecero notare alcuni veri commerciali. Effettivamente questo approccio risulta, alcune volte, controproducente per l’azienda in quanto il cliente compra meno o, addirittura, decide di affrontare (sotto suo consiglio) il problema lateralmente e senza l’uso dell’informatica (o dei servizi offerti dalla sua azienda).

Controproducente nell’immediato ma vincente nel lungo termine. Il commerciale decise che il suo scopo non era solo vendere, ma farlo solo se si poteva massimizzare il valore per il cliente ed, ovviamente, per la propria azienda. Valore che può essere una riduzione degli sprechi per quest’ultima, evitando lunghe e costose riunioni per progetti fumosi. O dando al cliente un partner, più che un fornitore, pronto ad aiutarlo a migliorare il proprio business creando inoltre un circolo virtuoso tra tutti i clienti al fine di creare opportunità di lavoro per loro (e tra di loro), e quindi di riflesso anche per la propria azienda.

Una sorta di decrescita positiva abbinata al processo di sviluppo di software. /-> riduzione costi nel breve termine -> possibilità di reinvestimento su altre attività minori sprechi -> il superfluo è rimosso -> il software fa solo quello che deve fare | \\-> riduzione dei consumi -> ottimizzazione processi <-/ | \\-> porta vantaggi nel medio/lungo termine <-/

Compromessi e non soluzioni

Francesco Fullone

Compromessi e non soluzioni