挺好的一篇文章-Being your own boss，转发
Being Your Own Boss—Part I: The Ideal Job [2007 | 3]
WATTS S. HUMPHREY
This is the first of a series of columns on our work as developers and how we can have truly satisfying jobs. This first column in the series discusses ideal jobs, what developers like about their work, and what they find annoying and unpleasant. It then describes how the developers’ and managers’ views on project success differ and what this means for both developers and their organizations. In subsequent columns, I will discuss how to turn almost any job into an ideal job, some of the issues you will face in trying to do so, and the level of support you will need from your managers and peers to be successful. While there are a few basic conditions that must be satisfied before you can expect to transform any job into this ideal, it is surprising how many jobs can be rewarding when you approach them in the right way.
Job Satisfaction
In discussing job satisfaction, we must first answer the question: “Satisfaction for whom?” One would expect the characteristics of a satisfying job to be different for the person doing the job and for the person for whom it is done. However, there is one condition that is common: the job must have been a success. This, of course, leads to the next question: “How do managers and developers view project success?”
This question has been researched by Kurt Linberg [Linberg 99]. He studied the views of developers about project success for his PhD dissertation. In this study, he asked groups of developers to identify the most successful and least successful jobs on which they had worked. Then he examined the characteristics of the most successful and least successful projects.
Successful Projects
From the developers’ perspectives, the most successful projects had three common characteristics:
The project was a technical challenge.
The final product worked in the way that it was supposed to work.
The team was small and performed well.
Some typical developer views about these successful jobs were that
the product was well designed and implemented
it was well tested
the team members enjoyed working with each other
they didn’t feel pressured by management
In addition, as long as the project manager protected the team, conflicts with other groups or with senior management didn’t seem to bother the team members. They also thought that the work was innovative, that there was a high level of trust among the team members and with the project manager, and that the team was highly motivated.
In general, the developers attributed their high levels of motivation to five things:
a sense of making a contribution
an orderly and well-managed working environment
frequent celebrations of even small successes
positive feedback from both management and marketing
the autonomy to do the job in the way that they thought best
It didn’t seem to matter how important the project was to the organization or how well the team worked with other groups. In fact, it didn’t even matter whether the job was completed on time and within its budget.
Unsuccessful Projects
Conversely, the team members viewed the least successful projects as unrewarding, as having poorly defined requirements, and as having inconsistent or even nonexistent marketing support. Typically, these worst performing projects were perceived as
not achievable from the outset
under excessive management pressure
requiring unreasonable levels of overtime
technically frustrating
having frequent conflict among team members
operating in a chaotic environment
In summary, the developers’ views of project success were largely independent of cost or schedule performance. The team members viewed a project as successful if it was a rewarding and enjoyable experience, even if it was late and over budget. In other words, a successful project was a personally satisfying project.
Management’s Views of Project Success
Linberg also found that management’s views of project success or failure almost entirely concerned cost, schedule, and quality performance. Table 1 summarizes his findings on the definition of various levels of success or failure for both completed and cancelled projects [Linberg 99]. This study found that developers view some projects as successful even when management does not and vice versa. Having been a manager for many years and having seen how hard developers worked to meet their schedules, I thought this conclusion contradicted everything I have seen in more than 50 years of development experience. I have worked with hundreds of teams and supervised groups of thousands of developers who worked around the clock to meet their deadlines. Every team I have ever worked with has always made an extraordinary effort to meet cost and schedule commitments, and many of them were consistently successful in doing so.
Project Outcome
Completed Projects
Cancelled Projects
Failure
A product that causes customer discontent:
Not meeting user expectations.
Not learning anything that can be applied to the next project.
Time and money wasted with no return.
Low Success
Below average cost, effort, and schedule performance.
Barely meeting user expectations.
Learning can be minimally app-lied to future projects.
Time and money wasted for limited return.
Success
Average cost, effort, and sche-dule performance.
Meeting user expectations.
Learning can be applied to future projects.
Some artifacts can be used.
High Success
Better than average cost, effort, and schedule performance.
Fully meeting all user expectations.
Substantial learning can be app-lied to future projects.
Significant number of artifacts can be used.
Exceptional Success
Meeting or exceeding all user quality, cost, effort, and schedule expectations.
A cancelled project cannot be called exceptionally successful.
A little reflection, however, shows that Linberg’s conclusions do not conflict with my experience. I never asked the teams how they viewed their projects. They were paid to meet management’s goals, and when they did, management was happy and everyone got paid. So, in summary, management views a project as highly successful if a team delivers a quality product on schedule and within its committed costs, regardless of how the team feels about the job. Conversely, development teams view projects as highly successful if they are professionally challenging and technically successful and if they provide a rewarding and personally satisfying working environment.
Common Management and Team Goals
While no rational managers would object if developers enjoyed their work, that is not one of the managers’ highest priorities. Similarly, developers universally would like to deliver quality products on schedule, and they even strive to do so, but they do it because they know it is their job. What they really want, however, is to have a rewarding experience.
While these views don’t necessarily conflict, they are not mutually supportive. This situation is what is called cognitive dissonance, where our views of reality differ from what we experience. In the case of a project, the developers know what success feels like. Many of them have experienced it on sports teams where a winning performance is an exhilarating experience, the coach congratulates the players, and the fans cheer. Everybody then helps in the celebration.
But development is different from competitive sports. Developers know that the managers’ kind of success is what the organization wants, and that what developers value most is not a management priority. Sometimes the team wins and nobody seems to care, and other times, it feels as if the team loses but management cheers. Cognitive dissonance is demotivating and debilitating; it is not the stuff that builds winning teams or ideal jobs.
Congruent Management and Team Goals
This raises the next question: “What would happen if the managers’ and developers’ views of project success reinforced and supported each other?” One team’s experiences illustrate what could happen. On their last project, members of this team had put in more than 70-hour weeks, worked under enormous pressure, and managed to deliver their product to test on time. Testing, however, took longer than anyone had expected, and the product was delivered late. It was delivered, however, and at the time I met with the team, it was being installed by the users. While this job wasn’t a complete failure in Linberg’s terms, it certainly wasn’t a big success from either management’s or the team’s perspective.
On the next project, however, the team members had a realistic plan; they did high quality work; they had capable leadership; they had clear, agreed-upon goals; and they believed that the team owned the project. This was their job and they were going to make it a success both for the team and for the business. They not only delivered their product to test on time, but it was of such high quality that testing was finished early. They only worked 45-hour weeks and were home for dinner with their families every night. They said it was the best project they had ever worked on, and management was full of praise.
How did they do it? The answer is that they and their management made a real effort to make this project a success for both the developers and the managers. More on how to do this in the June column.
