Caso di studio: il CIO solitario

577 views

Published on

Come è possibile ricavare da un insieme di requisiti del business i requisiti determinanti per la comprensione della quota parte «informatica» di un problema?

Come è possibile ricavare da un insieme di requisiti del business una stima affidabile del costo dello sviluppo?

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
577
On SlideShare
0
From Embeds
0
Number of Embeds
245
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Potrebbe essere necessaria più di una diapositiva
  • Caso di studio: il CIO solitario

    1. 1. Caso di studio: Il CIO solitario Andrea Colleoni | Colleoni.INFO
    2. 2. Il CIO solitario Quando il CIO si trova a dover prendere una decisione e ha bisogno di un supporto indipendente.
    3. 3. Sintomi  Il business richiede un nuovo servizio ed espone i suoi requisiti al CIO.  Il nuovo servizio ha tutte le caratteristiche per diventare un nuovo progetto informatico, dato che il servizio non è erogabile dal sistema informativo attuale.  Il CIO ha bisogno di fare uno scouting delle soluzioni disponibili e di realizzare il progetto.  Che fare?   Introdurre un nuovo prodotto che eroghi il servizio out-of-the-box e sviluppare un’integrazione.   Personalizzare il proprio sostema informativo. Realizzazare un nuovo software integrato. Chi sono i cointeressati?  I fornitori, che proporranno le loro soluzioni; nessun fornitore dirà che la propria soluzione non va bene, ma che è la più adatta in quel contesto.  Il business o la proprietà, proporranno i loro partner.  Il CIO su cui ricadranno tutte le responsabilità se il progetto fallisce.
    4. 4. Problema n° 1: l’analisi  Come è possibile ricavare da un insieme di requisiti del business i requisiti determinanti per la comprensione della quota parte «informatica» del problema? Soluzione tipica:  Lasciare che sia il business a descrivere su un documento informale i propri bisogni e trasmettere o condividere con i fornitori questi bisogni. I fornitori faranno poi la loro analisi dei requisiti. La nostra soluzione :  Esistono metodologie e strumenti affidabili e consolidati per produrre in tempi brevi un’analisi completa dei requisiti in un contesto di sviluppo di software di qualità, comprendente: piano dei test, requisiti non funzionali, matrice delle competenze. Benefici:  L’analisi da parte di un soggetto terzo, garantisce l’indipendenza della scelta. Il fornitore tenderà a porre in risalto la soluzione che produce il maggior margine.  Il CIO non ha bisogno di avere un ingegnere del software nel suo staff, ma ne richiede i servizi on-demand.  Con un insieme ordinato di requisiti è possibile produrre una stima più precisa.
    5. 5. Problema n° 2: la stima  Come è possibile ricavare da un insieme di requisiti del business una stima affidabile del costo dello sviluppo? Soluzione tipica:  Chiedere quotazioni a tutti i fornitori conosciuti. La nostra soluzione :  Esistono metodologie e strumenti per produrre in tempi brevi una stima del costo industriale di un insieme di requisiti, a prescindere dalle tecnologie di implementazione. Benefici:  La stima da parte di un soggetto terzo, garantisce l’indipendenza della scelta.  Il CIO non ha bisogno di avere un ingegnere del software nel suo staff, ma ne richiede i servizi al momento opportuno.  Con una stima, si può discutere del budget; con un insieme di requisiti no.  Con una stima si può scrivere un capitolato più preciso su cui chiedere una quotazione ai fornitori.
    6. 6. Problema n° 3: la direzione dei lavori  A che punto siamo con lo sviluppo? Quando posso far vedere qualcosa al business? Soluzione tipica:  Tempestare di telefonate il PM del fornitore e chiedere incontri, SAL, verifiche e richiedere tempi certi. La nostra soluzione :  Una direzione dei lavori terza, che coinvolge gli stakeholders con SAL periodici; un unico interlocutore per progetti multi fornitore. Nessun rischio nascosto. Competenza tecnica nelle fasi dello sviluppo. Benefici:  La direzione dei lavori da parte di un soggetto terzo, garantisce un’informazione indipendente.  Il CIO non ha bisogno di avere un PM nel suo staff, ma lo richiede in modalità on demand.  Il CIO non ha bisogno di riporre illimitata fiducia nel PM del fornitore.
    7. 7. Problema n° 4: la verifica  Avevamo chiesto che fosse implementata questa funzionalità, ma nel software consegnato non è implementata come la volevamo noi. Soluzione tipica:  Il forinitore chiede un addendum al contratto e sviluppa la funzionalità richiesta; nella migliore delle ipotesi si può ottenere uno sconto commerciale dovuto all’incomprensione. La nostra soluzione :  Una verifica costante e in itinere rispetto al piano dei test. Mockups, deliverable frequenti e processi AGILE per anticipare i problemi di interpretazione tra fornitore e business. Benefici:  Si affronta il cambiamento, prima di aver affrontato il costo dello sviluppo di feature non richieste o non più utili.  Il fornitore è più motivato, e il business più coinvolto.  Oggettività dei test rispetto al ciclo di vita del progetto; minor probabilità di contenzioso con il fornitore.
    8. 8. Risultati finali  Proprio come per la consulenza fiscale, anche il CIO non è solo e può farsi consigliare da un consulente esterno on-demand.  Non ci sono costi fissi, ma variabili e funzione della dimensione dei progetti.  Non ci sono oneri di formazione, dato che i nostri professionisti sono esperti aggiornati.  Maggiore proabilità di successo dei progetti software.  Minor costo relativo dei progetti falliti.  Oggettività nella comunicazione con business, fornitori, proprietà, management.
    9. 9. Colleoni.INFO Ingegneria del software http://www.colleoni.info/wp/slideshare

    ×