sono realizzate in modo tale da produrre gli effetti opposti a quelli che il cliente desiderava ottenere, per questo motivo ti spiegherò un metodo più efficace per scegliere un fornitore di sviluppo software.
Mentre la maggior parte delle richieste di preventivo sono focalizzate sul software da costruire e sui costi, penso che sia meglio concentrarsi sul fornitore e il suo team di sviluppatori, scegliendo il migliore e lavorando collaborativamente con loro per costruire il miglior progetto possibile.
Ritengo inutile concentrarsi sui dettagli del progetto nel momento in cui c’è la massima ignoranza su di esso come invece avviene tipicamente con le richieste di preventivo, costringendo sia il cliente che il fornitore a fare ipotesi di ogni genere.
Peraltro, se il progetto riguarda software personalizzato, è praticamente certo che i requisiti cambieranno in corso d’opera, rendendo ancora più inutile questo tipo di approccio. Inoltre quasi tutte le RFP si focalizzano sui costi (o anche solo su questi nei casi peggiori) ed è qui che vedo spesso gli effetti peggiori che producono in realtà costi maggiori, poiché in questo caso i clienti rischiano di sentirsi dire quello che vogliono da fornitori che hanno bisogno di prendere il progetto a tutti i costi e soprattutto i costi bassi non danno nessuna garanzia di ottenere il prodotto giusto (che potrebbe invece essere un ammasso di bug impossibile da mantenere).
I costi ridotti si ottengono invece costruendo il giusto software, con la minor quantità possibile di funzionalità, facile ed economico da estendere e mantenere.
Questo si ottiene da un fornitore con le giuste capacità, un processo di sviluppo efficace e un metodo per rimanere nel budget in modo affidabile.
Dopo aver scelto un fornitore di questo tipo puoi anche negoziare i costi ma ricordati che una richiesta di preventivo strutturata in questo modo ti ha aiutato a selezionare un partner altamente qualificato e referenziato che impiega personale di qualità; non aspettarti quindi le tariffe più basse del mercato ma un approccio che consenta di ridurre i costi complessivi e produrre software di qualità.
La RFP dovrebbe quindi concentrarsi su questi aspetti: azienda, persone, progetti (di successo e falliti), progetto proposto, altre referenze.
Informazioni sull’azienda
Nella prima parte della RFP dovresti chiedere alcune informazioni sul fornitore:
- Da quanti anni è sul mercato e una breve storia;
- Chi sono i proprietari e che ruolo hanno in azienda;
- Il turnover dei dipendenti;
- Il fatturato per dipendente;
- La redditività comparata a quella del mercato;
- La quantità di capitale circolante;
- La quantità di clienti serviti negli ultimi anni e il peso sul fatturato del cliente più grande;
- Come è impostata la cultura aziendale.
Non tutte le aziende sono disponibili a fornire questi dati, ma quelle che lo fanno vanno valutate positivamente perché sono disponibili a lavorare in modo trasparente.
Poiché la realizzazione di software non è (solo) un problema di tecnologia ma soprattutto di persone, è importante sapere con chi avrai a che fare (soprattutto se è un’azienda giovane), per quali motivazioni e ideali i fondatori hanno creato l’azienda e se sono attivamente coinvolti nella gestione. In particolare, la cosa più importante è ottenere le migliori persone che sanno già come lavorare assieme sul tuo progetto; i programmatori di maggior talento hanno molta scelta su dove andare a lavorare e la capacità di un’azienda di tenere lo staff (se di qualità) con un basso turnover è un ottimo segnale.
I dati economici sono importanti per sapere se il fornitore è finanziariamente stabile e di conseguenza produce profitti (indice di pochi errori e progetti falliti).
Ad esempio, un’azienda che ha sufficiente capitale circolante per sostenere fluttuazioni nella domanda non è tentata di prendere progetti per i quali non è adatta.
Un altro segnale importante è avere una base diversificata di clienti che riduce il rischio se uno di questi non c’è più; il rischio invece aumenta quando un singolo cliente rappresenta una grossa parte del fatturato (es. 40/50%).
Infine, la parte sulla cultura aziendale è altrettanto importante per tenere in azienda le persone migliori e avere un’attività sostenibile e la cosa migliore è visitare gli uffici del fornitore per “percepire” l’ambiente.
Persone
Le informazioni da chiedere sono:
- Staff di progetto e composizione (dipendenti, collaboratori, anni di esperienza professionale media, anni di presenza in azienda, educazione);
- Presentazioni, articoli di blog, premi, pubblicazioni;
- Attività per lo sviluppo professionale;
- Ore medie lavorate alla settimana per dipendente.
Le aziende informatiche che investono nella crescita del loro personale tendono ad avere programmatori sui quali si può fare affidamento nella realizzazione dei progetti software.
Alcuni segnali importanti sono quindi la partecipazione a conferenze, gruppi locali di sviluppatori, ecc.
Inoltre i programmatori di talento e gli innovatori tendono a scrivere in qualche forma e a condividere il loro know how; questo è possibile constatarlo nel blog aziendale, in eventuali talk alle conferenze di settore, ecc.
Infine, è utile sapere quanto lavorano mediamente i programmatori poiché nel settore del software è difficile trovare aziende che hanno un ritmo di lavoro sostenibile, ripetibile, affidabile e piacevole per chi ci lavora (tutti fattori importanti per produrre software di qualità).
Inoltre se il dato è disponibile significa che il tempo viene tracciato e probabilmente il fornitore è in grado di stimare e pianificare correttamente.
Progetti di rilievo
Il fornitore dovrebbe fornire i seguenti dati per almeno un paio di progetti di rilievo:
- Informazioni di base (cliente, contesto, obiettivi);
- Dimensione (ore lavorate per tipo di lavoro);
- Durata;
- Risultati ottenuti;
- Esempi di artefatti delle varie fasi (requisiti, progettazione, sviluppo, test, ecc.);
- Referenti del cliente (nome, azienda, telefono ed email).
Ricevere alcune informazioni dal fornitore su progetti simili al tuo può fornirti molte più informazioni di quante se ne possano ottenere chiedendogli di formulare delle ipotesi sul tuo progetto in forma di preventivo.
Le informazioni e i risultati dovrebbero essere formulati sia dal punto di vista tecnico che aziendale (es. aumento di ricavi, diminuzione di costi, ecc.).
I referenti del cliente andrebbero infine contattati per avere la loro opinione su come è andato il progetto.
Progetto fallito
E’ importante chiedere alcune informazioni anche su un esempio di progetto che non è andato bene:
- Informazioni di base;
- Dimensione (ore lavorate per tipo di lavoro);
- Durata;
- Retrospettiva: perchè è stato considerato fallito? Cosa e perchè è andato male? Qual è stato il risultato finale? Altro lavoro svolto per il cliente? Azioni effettuate, impatto per l’azienda?
Anche in questo caso quando un fornitore è disponibile a fornire questo tipo di informazioni e ammettere errori è segno di trasparenza e affidabilità.
L’analisi dovrebbe mettere in luce una responsabilità condivisa tra cliente e fornitore, come quasi sempre avviene nei progetti falliti.
Progetto proposto
Dopo aver presentato al fornitore il proprio progetto, queste sono le informazioni che il fornitore a sua volta dovrebbe fornire:
- Comprensione del progetto;
- Analisi dei rischi;
- Gruppo di progetto proposto (dimensione, ruoli, sede di lavoro, forme contrattuali, formazione, esperienze professionali, esperienza in azienda);
- Approccio (responsabilità, comunicazione, requisiti, stime, controllo dei tempi, reporting, delivery);
- Modalità di sviluppo (progettazione, programmazione, qualità);
- Modalità di supporto (manutenzione ed estensione, gestione bug e incidenti, tariffe, livelli di servizio e tempi di risposta, hosting, monitoraggio);
- Modalità preferita di ingaggio.
Il fornitore dovrebbe sintetizzare a proprie parole il progetto proposto e identificare i potenziali rischi, in modo da dimostrare che lo hanno analizzato e di essere familiari con la tecnologia e il dominio di riferimento.
Verifica molto bene il modo in cui il fornitore intende costruire il gruppo di progetto (che tuttavia potrebbe in parte cambiare se il tuo processo di scelta del fornitore impiega del tempo), ad esempio se le persone sono dedicate e se lavorano nella stessa sede (situazione da privilegiare).
Un altro aspetto importante è il processo di sviluppo e come il fornitore intende costruire il progetto.
Ad esempio, bisogna privilegiare i fornitori che garantiscono consegne frequenti di software testato da validare con brevi iterazioni (anche settimanali), che hanno strumenti adeguati per coordinare il team e i referenti del cliente, ecc.
Verifica anche come saranno gestiti i requisiti emergenti, le modifiche alle specifiche, come saranno effettuate le stime.
Nelle modalità di sviluppo dovresti invece controllare come il team intende realizzare il progetto nelle sue varie fasi e con quali tecniche: tecniche di progettazione, pratiche di sviluppo (è basato su un approccio test-driven? Il software è tenuto sotto controllo di versione con strumenti come git? Il team segue dei flussi come git-flow?), testing (sono previsti test unitari automatizzati?), validazione (vengono effettuate delle demo frequenti sulla base di software funzionante e non di semplici slide powerpoint?), ecc.
E’ necessario anche approfondire come verrà supportato il progetto in futuro una volta che è stato messo in produzione.
Tutti i progetti di successo richiedono infatti del lavoro in futuro e hanno bisogno di essere adeguatamente supportati.
Attenzione: non tutti i team di sviluppo si occupano di gestire l’applicazione una volta consegnata. Come saranno gestiti gli incidenti e i bug? Con quali tempi e livelli di servizio? Dove sarà ospitata l’applicazione? Chi la terrà sotto monitoraggio? Infine, chiedi al fornitore qual è il suo modo preferito di impostare la relazione contrattuale: ogni processo di sviluppo ne ha una meglio allineata. Quanto faranno pagare? Quando emetteranno le fatture? Chi accetta il lavoro consegnato? Ecc.
Altre referenze
Il fornitore dovrebbe indicare ulteriori referenze assieme ad una breve descrizione del loro contesto e dei recapiti dei clienti.
Sebbene siano certamente referenze positive, i rispettivi clienti andrebbero comunque contattati per sapere come effettivamente viene seguito il processo descritto e come è lavorare con il fornitore.