L'analisi che deve essere svolta per fare un preventivo al cliente deve essere retribuita. Se vi interessano le ragioni, e per avere ulteriori informazioni, continuate a leggere sotto.

Spesso, quasi sempre, i clienti (e i potenziali clienti) mi chiedono dei preventivi per i loro progetti. Tuttavia, pochi di loro sembrano essere in grado di capire fino in fondo un fatto fondamentale: Un professionista nel settore informatico è - appunto - un professionista nel settore informatico e, con molte probabilità, non ha alcuna competenza nel loro campo. Personalmente, ho sviluppato progetti per i settori di telecomunicazioni, di circuiti elettronici programmabili e connessi, GDO, turismo, web, gestionali di tutti i tipi, programmi per il settore finanziario, analisi di genomi e di proteine nel campo della bioniformatica, ecc. Posso essere esperto in tutti questi settori? Assolutamente no. Ma i clienti, esperti nei loro domini, avevano le idee chiare sui progetti dei quali avevano bisogno e mi hanno fornito tutte le informazioni necessarie, e a volte anche l'analisi funzionale completa. E io, di conseguenza, sono stato portato nelle condizioni di poter fare l'analisi tecnica, scegliere le tecnologie più appropriate, e realizzare i progetti.

Un preventivo per un progetto informatico complesso - se vogliamo parlare di un preventivo serio e non uno campato per aria - richiede un accurato processo di analisi funzionale e tecnica, che a sua volta richiedono - sia da parte del cliente che da parte mia - competenze, impegno, collaborazione stretta, lavoro e tempo. Io questi - di sicuro - non li regalo e, salvo nei casi che si tratti di un progetto veramente triviale, uno di quelli dei quali ne ho fatto parecchi (poco probabile, data la molteplicità e la trasversalità dei settori nei quali prest(av)o consulenza), io l'analisi svolta per fare un preventivo la fatturo. L'alternativa sarebbe "sparare" una cifra spropositata, in modo di essere sicuro che io ci possa stare dentro a prescindere dai fattori che si possono verificare strada facendo (spesso dovuti ai cambiamenti di rotta richiesti dal cliente il quale, nei casi più estremi e anomali che possono capitare, ne all'inizio ne in seguito, ha mai avuto ne mai avrà le idee chiare su quello di cui ha effettivamente bisogno) e che possono portare al prolungarsi dei tempi di sviluppo. Ma questo tipo di approccio risulterebbe antipatico anche a me, figuriamoci quanto potrebbe risultare antipatico al (potenziale) cliente. Pertanto, rimango alla prima opzione, quella di fatturare l'analisi svolta per la stesura del preventivo. Questo vale, in primo luogo, per clienti nuovi, con quelli pluriennali spesso ci capiamo già al volo e sono di solito meno pignolo su questi aspetti (ma anche i clienti lo sono, dunque, va bene così).

Di conseguenza, se uno mi chiede un preventivo, salvo, ripeto, progetti triviali per i quali posso fare preventivi al volo, deve essere pronto a:

1. Definirmi chiaramente gli obiettivi del suo progetto
2. Fornirmi una pre-analisi, esaustiva ma non prolissa
3. Definirmi gli eventuali vincoli tecnologici (programmi preesistenti con i quali avrebbe bisogno di integrazioni, piattaforme di sistemi operativi, ecc)
4. Collaborare attivamente alla stesura delle specifiche funzionali, allo studio di fattibilità e all'analisi funzionale
5. Ogni parte del progetto definita deve essere messa per iscritto (e approvata da entrambe le parti) in modo che ne sia garantita l'integrità e la non modificabilità (posta elettronica con la firma digitale, oppure testi sottoposti al sistema di controllo versioni: Git, Mercurial, ecc. Questi mi assumo il compito di configurare io per il cliente nel caso lui non ne abbia competenze)
6. Retribuirmi per il lavoro di analisi svolto (importo consuntivato, per lavoro a giornata)
7. Solo dopo l'analisi fatta si passa al preventivo che conterrà la cifra complessiva per un progetto "chiavi in mano".

I punti 1-3 non sono un imperativo, possono essere assimilati al punto 4, ma dai punti 4-7 non transigo. Solo dopo si passa alla realizzazione del progetto vero e proprio.

Il vantaggio che il (potenziale) cliente ha da questo approccio è che, a prescindere dall'esito delle trattative di collaborazione con me, nel caso il mio preventivo non dovesse risultargli accettabile, gli resta l'analisi svolta che può passare a un qualsiasi altro professionista o una qualsiasi azienda nel settore, che gli potrà fornire il proprio preventivo. Un altro vantaggio per il cliente è quello che, se strada facendo l'analisi dovesse produrre informazioni in base alle quali il cliente dovesse valutare che la complessità o la potenziale redditività del progetto non dovessero superare (o superare in modo sperato) l'importo dei fondi stanziati, si può ritirare dall'analisi senza penali, retribuendomi solo le giornate effettivamente lavorate. Se, poi, si dovesse trovare un accordo economico sulla realizzazione dell'intero progetto, al cliente detrarrei il costo dell'analisi dal costo complessivo del progetto. E sembra che i miei clienti (e qui parlo di "clienti" non di "potenziali clienti") siano stati (più o meno) tutti soddisfatti di aver accettato questo approccio, perché raramente ci siamo fermati a un solo progetto.

Se, poi, uno obietta che la maggior parte dei professionisti informatici gli hanno fatto un preventivo gratuito (cosa neanche sempre vera...), e anche subito (a parte che questo dovrebbe fargli suonare un campanellino d'allarme, ma lasciamo perdere) io gli rispondo: "Benissimo, si rivolga pure e loro, così non perdiamo tempo e soldi ne Lei ne io. Tanti saluti e in bocca al lupo".
Aggiungo che, se uno ha tempo da regalare (e io del tempo da regalare non ce l'ho), ci sarà sicuramente qualche motivo per questo, e se poi al (potenziale) cliente capita di trovarsi nelle mani della bassa manovalanza informatica che improvizza progetti senza cognizione di causa, di quelli che - per pura disperazione - accettano progetti per i quali non hanno competenze (sperando, forse, di acquisirle strada facendo), e se poi il progetto si protrae a dismisura o falisce completamente, si assuma anche lui le sue responsabilità, perché ci sarà un evidente concorso di colpa. Ma io mi tiro fuori a priori dalle situazioni così, senza pensarci troppo. Quella fetta di mercato la lascio volentieri ad altri.
Ci sono anche quei casi dove ne il cliente, ne il consulente, hanno le idee chiare e procedono con la collaborazione senza definire i requisiti dettagliati. Nulla da ridire se sono entrambi consenzianti e consapevoli che i tempi di realizzazione si possono protrarre e i costi lievitare ma, di nuovo, se il progetto fallisce, prendano atto entrambi del concorso di colpa e del proprio ruolo in quello. Ma di nuovo, io cerco di evitare (con ottimi risultati) le situazioni di quel tipo.

Concludendo, se il (potenziale) cliente non è in grado di conformarsi alle mie richieste esposte sopra, gli chiedo la gentilezza di non contattarmi affatto. E' per me un'opzione altretanto gradita quanto quella soprariportata.