martes, 13 de junio de 2006

Peopleware (Parte I)

Este libro es excelente en mi opinión, así que he decidido colocar los extractos que me parecen más resaltantes. Todo programador, desarrollador, líder técnico, funcional, arquitecto o jefe de proyecto debería leerlo. Mejor aún si lo compran. Aquí va lo más resaltante de la primera parte:


The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work.

The project that has to be done by an impossible fixed date is the very one that can't afford not to have frequent brainstorms and even a project dinner or some such affair to help the individual participants knit into an effective whole.

The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.

The Eagle project at Data General is a case in point. The project was a Spanish Theory triumph: Workaholic project members put in endless unpaid overtime hours to push productivity to unheard of levels. At the end of the project, virtually the entire development staff quit.

People under time pressure don't work better; they Just work faster. In order to work faster, they may have to sacrifice the quality of the product and their own job satisfaction.

We all tend to tie our self-esteem strongly to the quality of the product we produce, not the quantity of product, but the quality. Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.

Managers jeopardize product quality by setting unreachable deadlines.

The nation (Japan) that is an acknowledged quality leader is also known for its high productivity. The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.

Hewlett-Packard is an example of an organization that reaps the benefits from increased productivity due to high, builder-set quality standards. The company makes a cult of quality. In such an environment, the argument that more time or money is needed to produce a high-quality product is generally not heard. The result is that developers know they are part of a culture that delivers quality beyond what the marketplace requires. Their sense of quality identification works for increased job satisfaction and some of the lowest turnover figures seen anywhere in the industry.

In some Japanese companies, notably Hitachi Software and parts of Fujitsu, the project team has an effective power of veto over delivery of what they believe to be a not-yet-ready product. No matter that the client would be willing to accept even a substandard product, the team can insist that delivery wait until its own standards are achieved. Of course, project managers are under the same pressure there that they are here: They're being pressed to deliver something, anything, right away. But enough of a quality culture has been built up so that these Japanese managers know better than to bully their workers into settling for lower quality.

In a healthy work environment, the reasons that some people don't perform are lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. In none of these cases is schedule pressure liable to help very much. When a worker seems unable to perform and seems not to care at all about the quality of his work, for example, it is a sure sign that the poor fellow is overwhelmed by the difficulty of the work. He doesn't need more pressure. What he needs is reassignment, possibly to another company.

"In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group. She was a walking example of much of what I now think of as enlightened management. One snowy day, I dragged myself out of a sick bed to pull together our shaky system for a user demo. Sharon came in and found me propped up at the console. She disappeared and came back a few minutes later with a container of soup. After she'd poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do. She gave me her patented grin and said, Tom, this is management."

Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

No hay comentarios.: