Continuando con mi humilde selección de lo más resaltante de Peopleware, aquí esta lo correspondiente a la segunda parte del libro. Revisen también el post anterior.
PART II
Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It's only when you're in flow that the work goes well.
Unfortunately, you can't turn on flow like a switch. It takes a slow descent into the subject, requiring fifteen minutes or more of concentration before the state is locked in. During this immersion period, you are particularly sensitive to noise and interruption. A disruptive environment can make it difficult or impossible to attain flow.
If the average incoming phone call takes five minutes and your reimmersion period is fifteen minutes, the total cost of that call inflow time (work time) lost is twenty minutes. A dozen phone calls use up half a day. A dozen other interruptions and the rest of the work day is gone. This is what guarantees, "You never get anything done around here between 9 and 5."
If you're a manager, you may be relatively unsympathetic to the frustrations of being in no-flow. After all, you do most of your own work in interrupt mode -that's management- but the people who work for you need to get into flow. Anything that keeps them from it will reduce their effectiveness and the satisfaction they take in their work. It will also increase the cost of getting the work done.
What matters is not the amount of time you're present, but the amount of time that you're -working at full potential. An hour in flow really accomplishes something, but ten six-minute work periods sandwiched between eleven interruptions won't accomplish anything.
Management, at its best, should make sure there is enough space, enough quiet, and enough ways to ensure privacy so that people can create their own sensible workspace. Uniformity has no place in this view. You have to grin and bear it when people put up odd pictures or leave their desks a mess or move the furniture around or merge their offices. When they've got it just the way they want it, they'll be able to put it out of their minds entirely and get on with the work.
We are trained to accept windowless office space as inevitable. The company would love for every one of us to have a window, we hear, but that just isn't realistic. Sure it is. There is a perfect proof that sufficient windows can be built into a space without excessive cost. The existence proof is the hotel, any hotel. You can't even imagine being shown a hotel room with no window. You wouldn't stand for it. (And this is for a space you're only going to sleep in.) So hotels are constructed with lots of windows.
Even if there is a higher cost per worker to house people in the more agreeable space, the added expense is likely to make good sense because of the savings it provides in other areas. The real problem is that the cost is in a highly visible category (space and services), while the offsetting advantage is in poorly measured and therefore invisible categories (increased productivity and reduced turnover).
Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.
lunes, 26 de junio de 2006
Peopleware (Parte II)
martes, 20 de junio de 2006
El auge y la caida de CORBA
Este artículo me parece interesante. Habla de por qué fracasó CORBA como tecnología distribuida. En resumen, según el autor, se debió a graves errores técnicos y políticos (OMG):
The Rise and Fall of CORBA
Como para que los profes de algunos cursos de mi alma mater le den una revisada... no?
The Rise and Fall of CORBA
Como para que los profes de algunos cursos de mi alma mater le den una revisada... no?
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:
PART I
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.
PART I
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.
Suscribirse a:
Entradas (Atom)