Compromises and not solution
•
2 likes•1,772 views
One of the biggest problems perceived in the agile's world is "how do I make it clear to the sales dept. that I can't sell an application to the client without having discussed (and evaluated) it with the development team?". One of the biggest problems perceived by agile salesmen is: "How can I make it clear to the development team that without an economic evaluation I can't sell anything?". Bargaining is necessary not only to customers but also within the company. This is the talk / confession of a former developer passed to the dark side ...
Recommended
More Related Content
Similar to Compromises and not solution
Similar to Compromises and not solution (20)
More from Francesco Fullone
More from Francesco Fullone (20)
Recently uploaded
Recently uploaded (20)
Compromises and not solution
- 1. Compromises, not solutions! Francesco Fullone ff AT ideato.it
- 2. Who am I Francesco Fullone aka @Fullo - PHP developer since 1999 - President - and Open Source Evangelist - CEO @ - founder @ - conference organizer - Nerd and geek
- 3. Warning! «works for me» talk
- 4. Once upon a time...
- 6. Sysadmin to CFO and HR, webops, ... … a Log, is a Log...
- 7. Dev toProduct Owner, ... and Coach, CTO All for code... code for all!
- 8. Consultant to CEO and Sales, Mkt, ... Do things, see people...
- 9. Consultant to CEO and Sales, Mkt, ... Do people, see things...
- 10. Study, Do, Repeat do less, get more
- 11. The Zen approach “Floating customer, river sitting”
- 12. Upsell! You don’t love us!
- 13. Study, Do, Repeat sharpening the blade
- 14. The perfect Salesman Half Templeton «Faceman» Peck - half Stan
- 15. Agile... What?
- 16. Be a good salesman, is enough (at least for me)
- 17. Clienti? Customers?
- 19. Stime e story points Just pick two and don’t get too cocky
- 20. Prompt reply, Patient in getting it
- 21. Customers want products Or a service that is sold as a product
- 24. Study, Do, Repeat Salesaman as company MVP
- 25. Lean Manufacturing for a salesman
- 27. Search the true goals are sometime hidden, even to clients
- 28. Avoid the «imprinting effect» Don’t let your clients lose the focus
- 29. Getting to yes needs euristic approach
- 30. You are not a real salesman!
- 31. Business Synergy As Partners not Client-Vendor
- 32. companies
- 33. What about Contracts? ad hoc: starto, time&mat, fixed price, fixed scope, etc...
- 35. jsDay + phpDay 2013 16-19 Maggio 2013 Verona www.phpday.it / www.jsday.it
- 37. Francesco Fullone ff@ideato.it @fullo via Quinto Bucci 205 47023 Cesena (FC) info AT ideato.it www.ideato.it
- 38. Credits Once upon a time Mario by www.AntonioTajuelo.com Imprinting photo by LIFE Extended Venn Graph by http://www.jonathancrossfield.com phpDay and JsDay are TM logos from GrUSP.org Kerning Conference Logo TM from Kerning Conference Stan is a character from Monkey Island TM OpenFont Lobster Two, Source Sans Pro
Editor's Notes
- 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.
- “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.
- “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.
- 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.
- 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.
- 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 su una azienda di servizi?Credits: http://www.jonathancrossfield.com/blog/2012/06/time-versus-money-versus-quality-content.html
- è necessario essere veloci nel dare risposte, ma pazienti nell’ottenerle. Ciò può diventare un problema per la pianificazione. Ma bisogna sapersi adattare...
- 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? Vendere un servizio come un prodotto significa innanzitutto avere un listino chiaro.
- Purtroppo le aziende vedono gli sviluppatori come un «prodotto» che possono comprare e mettersi in casa.
- 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.
- Con questi, ed altri, quesiti decise di affrontare il problema da un’altra prospettiva.
- Più «lean». Diventando esso stesso un MVP per la propria azienda e capendo di volta in volta come gestire gli utenti/clienti
- 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”.
- Evitando però di trasformare il cliente in una persona che segue ciecamente il commerciale, ma ricordandogli sempre il focus di quello che deve fare. E predispondendolo ad una sorta di illuminazione su quello che necessita effettivamente
- 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 <-/