Indeed, this is a compelling testimonial on the importance of people in the software engineering process. And yet, all of us, from senior e...
Indeed, this is a compelling testimonial on the importance of people in the software engineering process. And yet, all of us, from senior engineering vice presidents to the lowliest practitioner, often take people for granted. Managers argue (as the preceding group had) that people are primary, but their actions sometimes belie their words. In this section we examine the players who participate in the software process and the manner in which they are organized to perform effective software engineering.
The Players
The software process (and every software project) is populated by players who can be categorized into one of five constituencies:
1. Senior managers who define the business issues that often have significant influence on the project.
2. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work.
3. Practitioners who deliver the technical skills that are necessary to engineer a product or application.
4. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome.
5. End-users who interact with the software once it is released for production use.
Every software project is populated by people who fall within this taxonomy. To be effective, the project team must be organized in a way that maximizes each person’s skills and abilities. And that’s the job of the team leader.
Team Leaders
Project management is a people-intensive activity, and for this reason, competent practitioners often make poor team leaders. They simply don’t have the right mix of people skills. And yet, as Edgemon states: “Unfortunately and all too frequently it seems, individuals just fall into a project manager role and become accidental project managers.”
In an excellent book of technical leadership, Jerry Weinberg [WEI86] suggests a MOI model of leadership:
Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability.
Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.
Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.
Weinberg suggests that successful project leaders apply a problem solving management style. That is, a software project manager should concentrate on understanding the problem to be solved, managing the flow of ideas, and at the same time, letting everyone on the team know (by words and, far more important, by actions) that quality counts and that it will not be compromised.
Another view [EDG95] of the characteristics that define an effective project manager emphasizes four key traits:
Problem solving. An effective software project manager can diagnose the technical and organizational issues that are most relevant, systematically structure a solution or properly motivate other practitioners to develop the solution, apply lessons learned from past projects to new situations, and remain flexible enough to change direction if initial attempts at problem solution are fruitless.
Managerial identity. A good project manager must take charge of the project. She must have the confidence to assume control when necessary and the assurance to allow good technical people to follow their instincts.
Achievement. To optimize the productivity of a project team, a manager must reward initiative and accomplishment and demonstrate through his own actions that controlled risk taking will not be punished.
Influence and team building. An effective project manager must be able to “read” people; she must be able to understand verbal and nonverbal signals and react to the needs of the people sending these signals. The manager must remain under control in high-stress situations.
