Come usare l’outsourcing e vivere felici #2

Per limitare l’overhead amministrativo-burocratico, proponi un contratto che preveda l’acquisto di un certo numero di giornate di consulenza annuali del fornitore e negozia uno sconto ragionevole.

Eviterai di dover richiedere un’offerta ed emettere un ordine per ogni singola attività.

Assegna un budget annuale di giornate di outsourcing a ciascun project manager e responsabilizzali nel gestirlo al meglio.

Come usare l’outsourcing e vivere felici #1

Mi rendo conto che non è facile negoziare una condizione come questa a meno che tu non sia HP o IBM, ma se vuoi veramente limitare i rischi dovresti vincolare il pagamento delle fatture al tuo fornitore all’accettazione del lavoro da parte del cliente finale.

Sui Pro e i Contro dell’ outsourcing

Riflettendo sui temi emersi nel post “Il vortice” mi sto domandando se esternalizzare lo sviluppo del software valga veramente la pena e se sia effettivamente compatibile con un business model come il nostro che ha come obiettivo la generazione di ricavi sia dalla vendita di licenze sia dall’erogazione di servizi di consulenza ai clienti per la realizzazione di personalizzazioni (tra le altre cose).

Mi riferisco a un approccio “black box” all’uso dell’outsourcing (che è poi quello che noi vorremmo implementare): scrivi delle specifiche di disegno software che invii agli sviluppatori e ti ritorna indietro il software, una definizione forse un po’ riduttiva visto che sono stati versati fiumi di inchiostro elettronico sull’argomento ma il concetto è quello.

Pro

1. riduzione dei costi
2. trasferimento del rischio: non funziona? non ti pago finchè non lo sistemi in modo che io possa fatturare al cliente finale
3. concentrare le risorse interne su servizi ad alto valore aggiunto per i clienti e meglio remunerati (project management, trusted advisors, ecc.)
4. facile reperibilità delle risorse: sviluppatori Java, Oracle, C++ si annidano notoriamente sotto ogni tombino
5. sgravio dei problemi organizzativi legati alla gestione del gruppo di sviluppatori: non è un problema tuo (più o meno)

Contro

1. overhead richiesto per la gestione dei contratti con i partner in outsourcing: sottoscrizione, rinnovo, negoziazione
2. aumento del volume delle comunicazioni
3. processi amministrativi aggiuntivi: emissione ordini, approvazione fatture, ecc.
4. effetto telegrafo senza fili: il cliente dice A, tu capisci B, lo sviluppatore in outsourcing capisce C
5. overhead richiesto per il training degli sviluppatori: si assume ovvia conoscenza delle tecnologie standard ma occorre addestrarli sul prodotto che vendi ai tuoi clienti
6. overhead richiesto per la verifica dei deliverables e il controllo di qualità
7. manutenzione delle personalizzazioni: non le hai sviluppate tu e allo scadere della garanzia o in caso di fallimento della società di outsourcing… bye bye baby
8. dissipazione del know-how, specie quando si esagera e si delega all’outsourcing anche attività di consulenza che faresti meglio a tenerti in casa (requirements gathering, scoping phase, ecc.)
9. sforzo aggiuntivo richiesto nella produzione della documentazione di disegno: del tutto inutile quando il cliente non ne ha bisogno, non ne comprende il valore aggiunto e non ha intenzione di pagartela ma tu sei costretto a scriverla comunque perché qualcuno ti ha detto che non devi più scrivere codice
10. rischio di corto circuito cliente-outsourcing: accade quando commetti l’errore di mettere in comunicazione diretta le due parti, cosa che può avere diversi esiti nefasti. Per esempio il cliente comincia a fare e disfare i requisiti utente al di fuori di ogni procedura di change control e lo sviluppatore gli va appresso lavorando allegramente sapendo che ti fatturerà time&material. Oppure il cliente mangia la foglia e si domanda perchè deve continuare a pagare il pizzo a te per fare il lavoro del passacarte quando potrebbe contrattare direttamente lo sviluppatore e risparmiare (in maniera piuttosto miope) un sacco di quattrini
11. “Diamine! Ho detto che si usa l’outsourcing!”, disse il capo. Ed ecco che lo sviluppo di un semplice report che stampa un barcode richiede tre volte il tempo richiesto se lo facessi tu

Per ora, Contro batte Pro 11 a 5 anche se non tutti i punti hanno lo stesso peso e ogni decisione dovrebbe tener conto di fattori peculiari di ogni progetto. Inoltre ognuno di quegli undici punti ha precise contromisure che dovrebbero essere messe in atto per poter utilizzare l’outsourcing in maniera efficace ed efficiente.

Un inizio di riflessione.

Il vortice

Per il nuovo progetto presso il cliente L. a B*, Spagna, hai deciso di affidarti a un ex-dipendente, D.V., che ora lavora come consulente freelance (e che finora è riuscito a trovarsi un solo cliente ma questi non sono problemi tuoi).

Piccola premessa: il progetto è uno degli scheletri nell’armadio lasciati da I.D.-C., il documento di offerta grida vendetta, la stima dei costi non c’è, le spese di trasferta non sono contemplate (ovvio, I.D.-C. abitava a B*) e… vabbè, fermiamoci qui.

D.V. conosce bene la realtà di L. avendoci lavorato parecchio quando eravate ancora colleghi. Risulta quindi la scelta più ovvia per consegnare presto e bene i 5 report Oracle che ti sono stati commissionati anche se si dichiara impossibilitato a lavorare direttamente presso L. . Già gongoli per le impressionanti performance che otterrai con il margine su questo progetto. Cosa può andare storto?

Un sacco di cose, perché hai sottovalutato tre aspetti fondamentali di questo progetto apparentemente semplice: la comunicazione tra le parti, la verifica del software consegnato e le procedure di validazione (L. è una società farmaceutica).

D.V. ti consegnerà il software via email e tu lo girerai al cliente che eseguirà i propri test e ti segnalerà eventuali incongruenze a fronte delle quali tu preparerai un bel bug report chiedendo allo sviluppatore di correggere gli errori. Al termine di questa iterazione D.V. ti consegnerà la nuova versione dei report che girerai di nuovo al cliente, che provvederà a ripetere i test, a notificarti l’esito ecc. Non è difficile immaginare che con questo processo i tempi di accettazione (e quindi di fatturazione) si allungano enormemente. Per il cliente ogni minuzia (l’etichetta un po’ più a destra, questa scritta in grassetto, il logo sbagliato) è un errore che va risolto. Inoltre, quando gli errori sono particolarmente gravi (es. “non funziona niente” punto) il feedback dal cliente non è nemmeno significativo: devi essere là per capire cosa non funziona e mandare indicazioni chiare allo sviluppatore. Ed eccoti smarrito nel vortice no.1, quello delle email con i feedback che allegramente contribuiscono a intasare la tua povera inbox.

Un modo per limitare le dimensioni del vortice è quello di farsi mandare dal cliente quante più informazioni possibile per riprodurre i problemi: gli identificativi dei dati con cui sono stati fatti i test, per ciascun dato erroneamente visualizzato l’indicazione di che cosa dovrebbe comparire al suo posto, esatte indicazioni su come modificare il layout di un report (anche via fax con scritte a mano che dicano cose del tipo: “questa colonna un po’ più a destra, la scritta di 10 pixels più grande”,ecc.) possibilmente utilizzando per i bug report un template predefinito. Ovviamente ogni bug deve essere registrato e tracciato: potrebbe bastare un file excel ma sarebbe meglio un sistema di bug tracking (io mi trovo molto bene con Bugzilla)

Inoltre le verifiche effettuate dal cliente se possibile dovrebbero essere trasmesse in videoconferenza o webex in modo che sia possibile vedere con i propri occhi che cosa sta andando storto e annotare ogni dettaglio: tieni presente che molto spesso una videoconferenza o un webcast si possono registrare e analizzare i filmati in seguito con più calma.

Dicevo dei test: ovviamente hai commesso l’errore di pensare che D.V. fosse dotato di poteri sovrannaturali e in grado di rilasciare codice esente da errori al primo colpo. Hai pensato che l’avergli fatto avere una macchina virtuale VMWare con una copia del sistema installato presso il cliente fosse sufficiente a eliminare qualsiasi rischio al punto che non ti sei nemmeno preoccupato di procurarti tu stesso una copia della virtual machine.

La prima versione dei 5 report è un disastro: l’hai girata direttamente al cliente senza nemmeno verificarla (e come avresti potuto senza un ambiente di test?) . Com’era da prevedersi il cliente ti ha rispedito indietro un email con la madre di tutti i feedback (“non funziona niente punto”). E ti è andata ancora bene. Avrebbe potuto scrivere: “Divertente! Però ora mandami i report veri…”.

Ti alteri un pochino anche con D.V. che ovviamente è tutto un “Oopss! Ho dimenticato di ricompilare”, “Acc! Non ho installato quel tal package sul database”, “Quella cosa non funziona? Impossibile!”, ecc.

Da questo momento in poi si procede per approssimazioni successive e comincia il vortice no.2, quello delle versioni del software che spesso il povero D.V. ti manda a orari impossibili: tu stai dormendo ma lui lavora e, ahimè, con una percentuale di accuratezza non certo favorita dallo sviluppare report nel cuore della notte. I file che ricevi e mandi al cliente non sono identificati da un numero di versione e capita a volte che i test vengano eseguiti utilizzando revisioni obsolete. Tutto ciò contribuisce ovviamente ad incrementare l’entropia dell’Universo. La prossima volta ricordati di chiedere che il numero di versione del software sia chiaramente indicato sul report stampato e venga incrementato a ogni consegna ufficiale. E, per favore, deciditi finalmente a utilizzare il Software Configuration Manager di cui la società ha acquistato un cospicuo numero di licenze (usiamo Perforce).

Piano piano la lista di problemi si riduce, ne sono rimasti 4 o 5. Vedi la luce: hai deciso di farla finita e di correggere personalmente i bug. Ma non hai un ambiente di test e quindi sei costretto a connetterti via dial-up al server RAS del cliente per effettuare le correzioni e le prove. Velocità di connessione: 33.6Kbit/s . Tempo per ricompilare e provare un report dopo ogni modifica: circa 15 minuti. Ti sei giocato un giorno intero (per tacere della bolletta telefonica) per sistemare quelle 4 o 5 cosucce.

Ma sei felice perchè puoi mandare finalmente la versione definitiva dei report che girano come un violino. In quella che pensi sia la conference call conclusiva hai appena pronunciato il fatidico “Bene, allora… si fattura. Giusto?”. E ti senti rispondere un “Aspetta aspetta. Mancano ancora i documenti che certificano l’esecuzione dei test . A proposito, dovresti anche venire qui a firmarci i documenti di specifica”.

Una risata isterica ti si disegna sul viso. Ti vedi già preda del vortice no.3, quello dei documenti di convalida che forse dovranno anche viaggiare per posta ordinaria.

Mancano 3 giorni alla chiusura del trimestre fiscale: ce la farai a fatturare il 100% del tuo forecast su questo progetto?

La risposta tra qualche giorno.

Annoti distrattamente su un pezzo di carta: la prossima volta chiedere a D.V. di dormire la notte, lavorare di giorno e sviluppare i report direttamente dal cliente, cercando di compiacere in ogni modo la gentile responsabile QA che ha commissionato i report.