- Domain knowledge value
- Process knowledge value
- The value of freedom degree
The first two values are well known to us: when you find out how to solve a puzzle, you need less time to solve it again. This means that you learned something about the domain of the problem and the process you've applied to solve it.
Consider the Tangram, for instance: it is a visual puzzle and the domain is geometric, therefore you need to learn several geometrical properties (translation/rotation), memorize some geometrical patterns. Moreover (and this is process knowledge!) you experience different strategies to solve the puzzle.
Philip Armour talks about it in his book "The Laws of Software Process: A New Model for the Production and Management of Software" in terms of Orders of Ignorance.
All this works in a perfect world, anyway, where communication processes are error free and people, like computers, are never mistaken.
But in our World it is common to:
- forget to mention
- make implicit reference to
- disguise
- conceal
- distort
- misinterpret
- under/over-value
features, concepts, in a more general way, THINGS.
When you're working in team, the presence of these communication errors can produce disastrous results. Let me tell you a story:
A rich shipowner orders a fantastic sailship to the best engineering team. In order to avoid any misunderstanding, he specifies everything in his request plans: materials, construction techniques, processes, etc.
At the launch, the ship sank in few seconds.
The shipowner furiously asks the project manager why it sank, and he calmly replied: "you did not specify the boat had to float".
The loss of feedback between the shipowner and the project manager produced the disaster. How can you prevent this? You need to deliver something earlier.
If you deliver earlier you are not going to produce a fully working (or real size) thing, anyway you can always produce something that's intermediate, incomplete, full of errors and somehow raw.
"The next delivery will be better", you've to think while collecting feedbacks from your client.
The equilibrium is delicate, anyway: if you deliver too early or too late, you can waste all the work:
- deliver too early: lots of continuous feedbacks, overheads, and loss of priority in change requests produce a bad product and out of time.
- deliver too late: projects took an erroneous path and there's no time to go back an restart
It's really worth noting that there is NO optimal point. Every project has its inertia, and, most important, every person has his/her rhythms.
The challenging part of project management is to adapt the project to the rhythms of the development team and the client.
Remember: "to err is human, to iterate is good" ;-)
Technorati Tags: cernio, development, process, feedback,
