Tuesday, May 02, 2006 

Knowing your real capacity

There is a magic step in most companies, when estimated effort is transformed into a schedule, and so in a delivery date.
In some companies the step is trivial - management is mandating the delivery date without even looking at the estimate. That's obviously a recipe for failure.
In most cases, however, the effort is somewhat allocated to multiple resources, a few external factors like holidays :-) are accounted for, and you get a schedule. I mean, an unrealistic schedule.
Indeed, most schedules are unrealistic even when the estimate is realistic. The reason is that most schedules assume that resources will be allocated 100% on the project, although it's pretty obvious to every reasonable soul that they won't be.
Resources are routinely distracted for several reasons. In many cases, those factors are collectively called "emergencies" or "crisis", but they are just the natural consequence of bad planning. Here is a (highly simplified) effect diagram (a la Weinberg) that I've drawn so many times for so many companies :-).

It all starts with some problem on the field: for instance, a customer experiencing some troubles. Since the schedule for the current project assumes 100% availability, resources are distracted. Note that having someone investigate the issue is a (sensible) management choice; it's the fact that no one is available (because the schedule assumes 100% availability) that causes resource distraction. Distraction leads to delay, and therefore to pressure to complete on-time; this is a natural consequence. In many cases, when the deadline approaches quality is compromised; this is a management choice (although in more than a few cases, the decision is taken at the development level). Here is the catch: if you compromise quality, you'll have problems on the field, creating a self-sustaining loop.
Now, we can try to break the loop with different techniques. We may artificially pad estimates; we may try to convey the message that "quality shouldn't be compromised", and so on. We can also face reality and understand that people won't be available 100% of their time. Ideally, we should measure their average availability: it's easier than it seems, if you don't get yourself carried out too far. We should also create a plan that it's both realistic (will deliver with good quality even if resources are distracted as usual) and aggressive (will make good use of resources if they are not distracted). The A/B/C metric from Todd Little would help here.
This will gradually reduce the amount of resource distraction (as you'll get less and less problems from the field once you don't compromise on quality), and therefore you'll be able to assume an higher availability of resources. Again, don't overshoot, as working on the edge is always dangerous.

Labels:

Comments:
E' sicuramente vero che lavorare sotto pressione mina la capacita' di conferire qualita' alla produzione software, ma secondo me in maniera trascurabile; cio' che ha un maggiore impatto sulla qualita' e' a mio avviso la competenza degli sviluppatori!
Inoltre credo che un buon professionista sia in grado di resistere alle pressioni del management (del resto credo che sia naturale in ogni campo che richiede un'elevata competenza tecnica avere dei manager preparati solo superficialmente e quindi impossibilitati a valutare tutte le sfumature di carattere tecnico di una problematica), e che possa "lavorare BENE anche quando il telefono squilla di continuo": la mia personale opinione e' che il circolo vizioso del diagramma che presenti sia quantomeno incompleto nella relazione effettuale tra "programmatore sotto pressione" e "compromesso sulla qualita'".
Contestualizzando il discorso alla mia realta' lavorativa: se e' vero che il management ha la responsabilita' di pianificare correttamente un progetto, credo che per quanto concerne la qualita' sia tuttto nelle mani degli architetti e dei programmatori! Poveri noi!!
Per terminare: un buon progettista/programmatore puo' spezzare il circolo vizioso!

Michel
 
Nel mio caso parto sempre da stime "ballerine", dalla fattibilità fino al design. Poi tutto si stabilizza. Naturalmente anche lo schedule varia di conseguenza.
In questo quadro (molto semplificato...) nella pianificazione tendo sempre ad inserire una contingency che varia per cliente/dominio che generalmente mi consente di assorbire le distrazioni.
Inotre un manager che è superficiale relativamente alla qualità e a cui sfuggono certe sfumature è semplicemente un manager sovravvalutato.
 
Michel (ma non Michele :-)) :
come dicevo "Here is a (highly simplified) effect diagram " quindi sicuramente mancano dei pezzi che di solito disegno per catturare una realta' piu' complessa; qui mi interessava mettere in luce un aspetto specifico.
Sul fatto che un buon progettista possa cambiare la situazione, cio' e' in parte vero, dipende in larga misura dai reali spazi di manovra che ha. Nota comunque che la freccia tra pressure e quality e' decorata con un quadratino, ad indicare che e' un effetto causato da decisioni di management, non da cause naturali.
Per Michele: concordo piuttosto ampiamente sul sopravvalutato. La contingency (sarebbe un discorso lungo ed una volta o l'altra lo riprendero') e' un modo "occulto" di gestire questi problemi, e come tale meno efficiente (ma piu' semplice da praticare :-) di un modo "palese" di gestirli. Come dicevo, ci torno su una volta o l'altra :-).
 
Post a Comment

<< Home