Sull’Interpretazione Dei “Giorni Uomo”

Nel contesto della consulenza software, la fatidica domanda “quanto tempo serve per terminare questo sviluppo” è più pericolosa di quello che possa sembrare, perché diversi stakeholder daranno diversi significati alla risposta. Così diversi che sarà anche sottointesa un’unità di misura diversa ad una risposta sia tipicamente espressa in giorni.

Ipotizziamo che il Professionista IT, che per conto della propria azienda di consulenza segue un progetto da un cliente affermi che “lo sviluppo delle nuove feature sarà terminato in 10 giorni”, intendendo un effort misurato in giorni uomo. Quindi immagina che lavorandoci saltuariamente con un collega, per portare avanti anche altre commesse, possa pubblicare in produzione le nuove feature tra una ventina di giorni, garantendo comunque che l’effort del reparto di sviluppo si attesti sui 10 giorni.

Il Collega del professionista, anche lui assegnato al progetto, capisce invece che si hanno ancora 10 giorni di tempo per lavorare al progetto, indipendentemente dal numero di persone che saranno coinvolte e questo lo rincuorerà poiché, vista la scadenza così prossima, e visto che quella routine proprio non sa come scriverla, sarà possibile delegare il gravoso compito a qualche altro collega.

Il Commerciale dell’azienda IT deve ovviamente assicurarsi che l’attività sia abbastanza redditizia per coprire non solo il costo di sviluppo ma anche una quota parte delle spese aziendali: l’affitto dell’ufficio, i costi di gestione, oltre che assicurare un’ovvia remunerazione. Il manager decide quindi di applicare un markup alla stima del professionista, proponendo al cliente una quotazione nella quale per trasparenza indica che l’effort sarà di 15 giorni uomo.

Il Manager lato cliente conosce il costo del progetto, e sapendo in quanto tempo sarà consegnato, con una rapida divisione calcola il costo giornaliero del professionista. Ottiene una cifra che tipicamente reputa troppo alta per il costo di uno sviluppatore e chiede quindi uno sconto all’azienda IT sulla quotazione del progetto perché comprende che la logica da sviluppare sia complessa, ma quel compenso giornaliero supera ogni limite di costo ragionevole.

Il PM del cliente, a cui il professionista riporta, pressato da più fronti, intende che le feature saranno rilasciate in produzione al massimo entro 15 giorni, che sarà considerato un lasso di tempo troppo lungo, quindi chiede di restringere i tempi di consegna a 10 giorni.

L’Esperto IT del cliente chiederà una riunione nella quale al professionista sarà chiesto di giustificare come mai lo sviluppo è stato quotato in 15 giorni, quando dalla sua esperienza, potrebbero tranquillamente bastarne 10. Il professionista, dal canto suo, sarà in linea di massima concorde con l’esperto del cliente ma dovrà arrovellarsi per ideare delle giustificazioni tecniche che giustifichino la stima comprensiva di mark up presentata dal proprio commerciale.

Tutto questo accade perché le varie figure coinvolte danno al concetto di tempo un significato totalmente diverso tra loro.

Per il Professionista la risposta è espressa in “giorni uomo previsti del team di sviluppo”. E’ una misurazione del tempo durante il quale gli sviluppatori dovranno impegnarsi per lo sviluppo del progetto. Il Professionista avrà anche incluso in questa misura un cuscinetto temporale per garantire di consegnare il lavoro entro il tempo espresso quindi più correttamente il Professionista intende la risposta come quel periodo di tempo che con una confidenza del 90% gli sviluppatori dovranno spendere nel progetto per garantire il rilascio delle funzionalità.

Per il Collega, i dieci giorni sono semplicemente dieci giorni di calendario. Se la consegna del progetto acquisisse una priorità altissima, egli sarebbe giustificato a pensare che l’Azienda dovrebbe includere nel progetto un numero illimitato di nuovi sviluppatori, a patto di rispettare la data di consegna, tra dieci giorni.

Per il Commerciale, la risposta da dare al Cliente, sentito il parere del Professionista, “è quell’ammontare di giornate che al costo per sviluppatore giornaliero preconcordato con il Cliente garantisce un’adeguata copertura dei costi e remunerazione”. E’ interessante notare come per il Commerciale, quindi, la “giornata” sia semplicemente un’unità di misura di valuta. Non euro, ma giornate, quindi.

Per il PM i quindici giorni sono, nello scenario migliore, il lasso di tempo entro il quale potrà smarcare l’attività come completata. Essendo lo scenario migliore, tuttavia, il tempo di completamento sarà in realtà aumentato del 50% nel progetto come misura precauzionale, allungando quindi l’attività a 21 giorni.

Il Manager del Cliente intende i 15 giorni come il costo economico della sola attività di sviluppo, dimenticandosi che ogni attività con scopo di lucro prevede ovviamente un margine economico. Eseguendo una semplice divisione ottiene un prezzo legato all’attività di un singolo sviluppatore che ritiene troppo elevato.

Infine l’Esperto IT del Cliente, intende i 15 giorni come puro effort, proprio come il Professionista, che però ne aveva stimati solo 10. L’Esperto ed il Professionista si confronteranno quindi su uno scostamento delle rispettive stime del 50% quando in realtà sono d’accordo almeno sul significato da dare alla quotazione su cui stanno discutendo.

Questo è quanto può accadere, nel peggiore dei casi, quando non c’è univocità nell’interpretazione dell’effort o precisione nella definizione dei termini o chiari rapporti tra fornitore e cliente.

 

 

 

SSH Cheat Sheet

Task: login to remote host with username and password

Login to host:

  1. ssh  -l  [login] -p [port]

Task: login to remote host using a configured alias

First of all you need to configure the alias. The SSH configuration file is normlly stored in ~/.ssh/config. This is an example.

host
  1.  Hostname [hostname]
  2.  Port [port]
  3.  ForwardAgent [yes|no]
  4.  ForwardX11 [yes|no]
  5.  User [login]

Once you have an alias, you can specify the alias name instead of specify all the options as parameters.

  1. ssh [alias]

Task: login to remote host using key authentication

Affidabilità dei sistemi informatici bancari

Stavo lavorando in una banca ad un porting verso tecnologie attuali di un sistema esistente da qualche anno. Nell’ambito di tale progetto dovevo realizzare un modulo del sistema il cui compito era sostanzialmente quello di estrarre da DB dei record con un campo data maggiore o uguale alla data di odierna, eseguire alcune elaborazioni e scriverli in un file da inviare ad un sistema a valle per una successiva elaborazione.

Il campo che conteneva la data era un campo CHAR di 8 caratteri e ci era stato assicurato che tutte le date erano nel formato YYYYMMDD. In questo modo per selezionare i record con una data maggiore di quella odierna si poteva sruttare l’ordinamento alfabetico e ad esempio scrivere una condizione del tipo

data >= '20052310'

Facendo qualche test mi sono però accorto che in realtà nel db c’erano record con date nel formato DD/MM/YY. La condizione restituiva perciò anche record con valori pari ad esempio a “23/12/98″, “20/10/89″ ed in generale qualsiasi data il cui giorno fosse maggiore o uguale a 20. Questo perchè, in ordine strettamente alfabetico, “23/12/98″ segue “20052310″. I record che avrebbero dovuto essere stati estratti erano qualche decina, invece la presenza delle date nel formato inatteso, ne faceva salire il numero a qualche centinaio.

Dopo un consulto con un programmatore che lavorava alla manutenzione del sistema decidemmo di lasciare i dati scorretti sul DB ma eliminarli nella query di selezione. E quindi in dettaglio la condizione diventò…

data >= '20052310' AND data not like '__/__/__'

Tutto sembrava andare per il meglio, il file contenente i risultati divenne molto più corto e l’elaborazione successiva ne avrebbe certamente giovato.

Mi pareva comunque strano come per i sette o otto anni precedenti il sistema a valle avesse elaborato ogni giorno centinaia di record inutili senza che sollevare il minimo problema.

In fase di test un file campione genenrato dal nuovo sistema doveva essere caricato dal sistema successivo. Il giorno del test ricevetti una telefonata ed il tecnico all’altro capo del filo mi disse che il test era fallito poichè alcuni record contenuti nel file non trovano riscontro nei dati di altre tabelle. Pronto ad affrontare una noiosissima sessione di debug mi accorsi che nel file prodotto non trovavo minimamente traccia dei record errati a cui si era riferito il tecnico.

Dopo una ricerca trovai i record incriminati nel file che era stato prodotto non dal nostro nuovo sistema ma dal vecchio sistema correntemente in produzione. Insomma, per una svista, il tecnico aveva sottoposto a test non il file prodotto dal nuovo sistema, ma quello prodotto quotidianamente, ormai da anni, dal sistema in produzione. E ci aveva trovato pure degli errori!