Wednesday, November 02, 2005 

Stop thinking "feature", think "value"

So, your project is going to be late and over budget. Does that make you and incompetent manager? An incompetent architect? An incompetent developer? Well, it depends.
No, it does not depend on whether your original plan was "right", but then requirements changed and new features crept in. That always happens. The critical question is: if we ship now, do we have enough value in our product?
Optimizing delivered value is not easy. It requires fundamental skills at every level:
manager: must be able to define the value of all features. Business value, marketing value, user value. Pick one (hopefully the most important) but be systematic along a project. Must be able to see the small value-delivering product inside a list of features. This ability is sorely lacking in many projects I see. That makes management's life easier, but this is not what I would call good management.
designer: must create a modular architecture, where features with low value can be plugged in later. Must avoid overambitious infrastructures which will postpone delivery of value. Or, must be able to provide real numbers on the risk and ROI of those infrastructures. Must design a system so that high value features can be implemented sooner than low value features.
developer: should tactically optimize for value. Should advise the designers and the managers on value-optimizing opportunities they may not be able to see. Should write working code, test it, and then move the next value-creating feature. Should avoid half-working code like the plague. Half-working features have no value.
At all levels, we must understand that we are embarking into a knowledge discovery journey. Customers will change their mind as they gain new knowledge. So will managers. So will designers. So will developers. We must be able to design some flexibility into our product, and change (even dramatically change) our plans throughout the journey. I still value the time spent planning and designing. But plans are a flexible, working tool, not a promise carved in stone.
So, your project is going to be late and over budget. But if we ship today, will we deliver enough value? If so, you did a good job, no matter what. Features can wait. Value can't.
See also the concepts of Incremental Funding and Minimum Marketable Features, that I've already mentioned elsewhere.

Labels:

Comments:
Caro Carlo,

l'impilamento dei ruoli

manager
designer
developer

oltre che rendere bene l'idea della gerarchia illustra magnificamente anche la distribuzione dei carichi e pesi da sopportare.

Come nel circo, chi sta sotto regge tutta la pila. Gli effetti mirabolanti li crea chi sta in alto, ma è chi sta sotto, apparentemente inattivo, che rende possibile lo spettacolo...

A più riprese vai sottolineando il valore del software rispetto alle caratteristiche anche se le due cose mi paiono fin troppo in simbiosi per poterne fare una netta distinzione.

Mi sento un po' smarrito come chi, agli inizi del novecento, sentiva per la prima volta le teorie relativistiche. Col tempo abbiamo imparato che la fisica newtoniana basta per il nostro piccolo orticello, ma se ci spostiamo nell'infinitamente grande (o infinitamente piccolo) quel modello risulta inadeguato...

Sicuramente le tue argomentazioni calzano meglio per progetti medio-grandi, per team di una certa consistenza. Ma per noi comuni mortali, che facciamo nascere soluzioni oggi e a fine settimana sono già consegnate al cliente, come trarre beneficio da tutto questo? L'equazione relativistica vale anche per le basse velocità, ma in un mondo meno vorticoso di quello prossimo alla velocità della luce basta la fisica newtoniana.

Detto in altre parole: questi concetti sono applicabili anche al software "piccolo"? Oppure il gioco non vale la candela perché irrilevante?

Dico questo perché la mia esperienza di sviluppatore è più bottom-up che top-down. Nel senso che i miei progetti software più che nascere da una visione dall'alto che poi viene calata nella realtà spesso sono celere risposta ad una semplice esigenza e poi nel tempo piccole donne crescono e si arricchiscono di caratteristiche non contemplate nella fase di gestazione.

In genere tutto bene, ma quando un software passa la decade ed è ben evidente che è nato in questo modo, qualche problema di usabilità lo pone anche se magari non trova eguali in numero di funzionalità od opzioni supportate.
 
lasciando perdere il ruolo del manager che e' al di fuori della mia esperienza,
la domanda che spesso mi viene di fare e': quanto si puo' essere dei bravi designer senza essere (o essere stati) dei bravi sviluppatori?

la mia personale idea e' che non lo si possa essere...

la vostra?
 
Rispondo a Pierluigi.

Ho un'opinione diversa. Un bravo architetto non necessariamente è un bravo muratore e viceversa un bravo muratore non è detto che sia un bravo architetto. Paragonare lo sviluppatore ad un manovale edile è sicuramente eccessivo però in fin dei conti noi softwaristi siamo artigiani. Se però non ci limitiamo a scrivere quanto pensato da altri, ma prendiamo parte anche al processo d'ideazione oppure il nostro contributo alla conduzione aziendale non è irrilevante, beh allora ci meritiamo giustamente i corrispettivi per le mansioni superiori che svolgiamo (designer & management).
 
Debugging activity - another story

Ho terminato l'implementazione di una nuova funzionalità in un programmino per la catalogazione e visualizzazione d'immagini jpeg ricevute da web-cam. Questo software implementa internamente un ftp server minimale con pool di thread.

Per soddisfare una nuova necessità ho voluto inserire la possibilità di abilitare una lista di distribuzione in modo che le immagini ricevute possano anche essere smistate verso altri server. In sostanza ho gestito internamente con apposito thread, anche un client ftp che si occupa della cosa. A lavoro ultimato ho pensato che se avessi utilizzato come host di destinazione questo programmino stesso, avrei dovuto scatenare un effetto ricorsivo dopo l'invio della prima immagine.

Siccome la connessione client di smistamento può avvenire sfruttando il comando PASV oppure no, ho voluto provare la cosa in entrambe le modalità. Utilizzando il modo PASV si scatenava l'effetto ricorsivo; senza invece no. Questa asimmetria m'é subito parsa strana ed indagando a fondo ho scoperto che nella parte che si occupava di ricevere l'immagine senza modalità PASV avevo dimenticato d'inserire il codice d'inserimento immagine nella lista di smistamento.

Da qui due osservazioni.

La prima. Mai sottovalutare le asimmetrie di comportamento la dove invece ce le aspetteremmo.
La seconda. Evitare di duplicare il codice e tendere il più possibile ad unificarlo. Spesso ci si dimentica di questo aspetto e in successive implementazioni si rischia di non applicare le modifiche in tutte le parti necessarie.

(Ovviamente non era una lezione per Carlo ;-)
 
L'impilamento dei ruoli e' solo un artefatto della rappresentazione testuale, che rende quel tipo di rappresentazione piu' semplice di una orizzontale, o di una tridimensionale :-) che piu' di ogni altra evidenzierebbe la mancanza di gerarchia. Infatti non condivido l'idea che chi sta sotto regge tutta la pila. Succede nelle (tante?) aziende disfuzionali, ma la verita' e' che se non c'e' idea di marketing sul prodotto, se non c'e un buon design, se c'e' solo produzione di ottimo codice impossibile da vendere, la pila crolla lo stesso. Sono 3 aspetti che devono cooperare; che poi succeda di rado, e non solo nel software, e' in parte a causa di una generale mancanza di buoni manager, ma anche di programmatori che [a scanso di equivoci: non e' un riferimento diretto :-))] mantengono una visione conflittuale verso le altre figure aziendali, anziche' crescere ed imparare ad avere a loro volta anche una visione di marketing.
Per quello che dicevi piu' oltre, ovviamente sotto una certa scala non c'e' necessita' di nulla: ci si siede davanti al pc e si scrive il codice. Fa molto XP :-), anche se XP e' molto di piu'. Pero' un progetto che va avanti da 10 anni a consegne settimanali, e che per forza di cose sara' un po' complicato sia da usare che presumibilmente da capire per chi arrivasse fresco fresco, e' davvero un progetto cosi' piccolino? Detto in un altro modo, se domani chiedessero alla tua azienda di portarlo sotto una piattaforma diversa, e gia' che ci siamo di renderlo un po' piu' user friendly ecc, pensi davvero che non ci sarebbe bisogno di una buona gestione del progetto, dove tutti i vari nomi arcani :-) che ogni tanto cito, a partire dal self-funding project, dovrebbero essere sapientemente utilizzati?
Per un esempio elementare ma non so quanto ovvio di separazione valore-feature, vedi la mia recente risposta ad un commento sul thread Semantic Blog
 
Pierluigi:
Un buon progettista, qualunque sia il suo campo, a mio avviso deve avere alcune conoscenze, caratteristiche, "sensibilita'":
- una conoscenza dei materiali che utilizza. Un architetto non puo' non cononscere le proprieta' del legno, del cemento, della pietra. Proprieta' funzionali (volendo sollevare una vecchia diatriba potrei dire "ingegneristiche" :-) e non funzionali, di forma.
- una conoscenza di come i materiali interagiscono quando vengono plasmati e combinati.
- una conoscenza sui principi e le leggi che governano questi materiali.
- una conoscenza, sistematica ma anche intuitiva :-), dello sforzo che richiede la realizzazione di cio' che sta progettando.
- una conoscenza di come gli altri progettisti affrontano i problemi.
- la capacita' di ricevere feedback dal progetto mentre lo si sta creando (cio'che Donald Schon chiama dialogo riflessivo con i propri materiali).
Ora, premesso che non amo l'equazione programmatore = manovale che ogni tanto emerge, quello che mi sento di dire e' che attualmente l'unico modo per un progettista software di acquisire le conoscenze e le sensibilita' di cui sopra e' attraverso una lunga esperienza di programmazione "intelligente" (ovvero non di codifica bruta copy&paste), unita ad una base teorica buona e ad uno studio piuttosto costante.
E' altresi' indispensabile, a mio avviso, che il progettista riesca ad astrarsi dal livello di codifica, ed e' per questo che io incentivo l'utilizzo di notazioni come UML (usate, ovviamente, nel rispetto di quella M per Modeling).
Per completare il quadro, posso dire che molti neolaureati si sentono magari prontissimi a progettare sistemi complessi, ma la realta' e' che con le solite, rare eccezioni, non hanno ancora maturato le conoscenze di cui sopra, e non riusciranno a maturarle senza immergersi molto a lungo nel codice (enfasi, comunque, sulla programmazione intelligente di cui sopra).
Collateralmente: su come la teoria di Schon possa essere trasferita nel dominio del software sto (da tempo :-) scrivendo un articolino, diciamo di epistemologia della progettazione, che prima o poi vedra' la luce da qualche parte...
 
Post a Comment

<< Home