|Software Developer's Guidebook|
Teams and Communications
Almost all software is created by a development team. The size and complexity of the system and the time allowed for development are usually the basis on which the team is assembled and staffed. It's important to get the right mix of team members for the project and to insure that all team members can work together.
The first step to take in creating a team is to analyze and understand the roles and responsibilities of team members. The members of the team are then selected and assigned duties to fulfill the various roles. Some projects may not need all team roles to be filled. The team manager will have to determine who is needed and when. Cost and time constraints will also affect selection of the team members.
Roles and Responsibilities
Each member of a software development team has one or more roles that they fulfill. Each role defines a set of responsibilities. A team member may take on more than one role and may even change roles over the course of the project. It is not unusual in small teams for one person to be architect, designer and coder. Likewise, the team manager may also be technical lead and customer advocate. Roles are not the same as job titles either. Whatever the person's job title, the roles he fulfills may vary considerably. Multiple team members may also fill a role. For example, most teammembers will be coders at some point in the project.
In larger organizations, one person may take on the same role for multiple teams. This is often the case for analysts, specialists, architects and technologists. These roles are most important early in the project, or are only needed for a short time during the project's schedule. Once the project is further along, their responsibilities and workload declines allowing them to concentrate most of their effort on new projects.
The names given below are commonly used. We don't have unique names for software developers and thus usually borrow names from other fields. However, the names have specific meanings in software development and shouldn't be confused with the use of the name in other fields.
The order given below is not intended to indicate importance. Roles will have different levels of importance depending on the specific project's needs. For example, a maintenance project may have little need for an architect or designer, but will rely heavily on coders and testers.
The moment you have two or more people working together you have a need for effective communications. It's not enough to just tell the team members they have to communicate with each other. There must be systems in place to allow for effective communications. Communication between team members becomes increasingly difficult as the size of the team increases. In addition, if the teammembers are geographically separated communication of information may become a major block tothe team's success.
Communication is much more than simple face-to-face conversation or e-mails betweenteam members. It includes any specifications or documentation that are written and any presentations of requirements or design to team members or customers. Unfortunately, very few programmers have any training in writing and speaking. When required to communicate information, they fall into a rambling technical discourse that only they can understand. It is beyond the scope of this book to teach effective writing and speaking, but the following principles may be of some help.
The first principle to understand is that you must communicate what the audience needs to hear not what you want to say. Most people assume that writing or speaking involves determining what you want to say. As a result, the listener often ends up with the feeling that nothing of importance was said and, quite possibly, that the speaker or writer is incompetent. Any effective communicator will tell you that you must "speak to your audience." This means that you adjust your language, technical level, mannerisms, and even the clothes you wear to fit the expectations and level of understanding of the audience.
The second principle is that you don't write or speak in a way to be understood. You must communicate in a way that you cannot be misunderstood. If there is ambiguity in what you communicate you can assume that at least some of your listeners will misunderstand. Thus, you must be precise and complete.
Next, use lots of diagrams. A single diagram can often demonstrate a complex system better than pages of text explanation. It simply helps to "see" the system. Diagrams don't need to be complex and are usually better if they are simple and direct. In addition, where possible you should use standard symbols and figures in the diagram. If a circle has a standard meaning, you should not use a circle for anything else. Sometimes a standard diagram doesn't cover the area you need to describe and you have to use some non-standard symbol. In those cases it is important to explain what the symbol means within the context of your diagram.
The next important principle is to be prepared. This is especially important if you are not familiar with speaking in front of groups. Don't just try to "wing it" with a lot of jargon and complexity. Make an outline of what you will say, review it and then stick to your outline. When communicating in writing, get your facts together first, make an outline, and then fill it in. When possible, have someone else review your outline or complete presentation.
Finally, you always have to be ready to say "Honestly, I don't know," or, "I need some time to think about that before I give you an answer." For some reason technical people seem to think they have to always have an answer or that if they don't know the answer immediately they will look incompetent. Most people understand that there are open questions that need careful investigation and appreciate someone who will communicate their ignorance rather than just feeding them a line that later proves to be false.
Each member of the development team brings a unique perspective, background and set of skills to the team. Often there will be vastly different personalities involved as well. These differences are of great benefit to the team if they are understood and managed. Otherwise, conflicts due to different personality and perspective can lead to serious conflicts that interfere with the team's success. It is always important to remember that just because you disagree with someone doesn't mean that his idea has no merit. Usually, the combination of ideas that different team members suggest will result in a better overall result.
The greatest difference in personality is usually between technical and non-technical people. Programmers will develop a view that everything is binary: yes/no, on/off, possible/not-possible. After all, you can't negotiate with a computer. It does what you instruct it to do and nothing more and nothing less. Non-programmers in general, and salesmen especially, usually solve problems through negotiation. Each side presents its opinion and then attempts to find a compromise position that satisfies both sides. To non-technical people, programmers will appear obstinate, arrogant and uncooperative. To programmers, the rest of the world appears ignorant and unwilling to understand the complexities of what they arerequesting. Programmers cannot expect people who are not programmers to understand these complexities. Otherwise they probably would not need the services of the programmer in the first place. Often, a non-technical person will have heard of some technology or learned a little bit of the programmer's jargon and then attempt to talk to the programmer on those terms. Programmers need to be especially alert to this. In the end, it is the programmers that have to learn to be better negotiators. Rather than just responding, "No you don't understand, that's not possible" you will have to explain the problems in non-technical terms and ask questions to get a better understanding of what the other person is requesting.
Among the technical team members the biggest difference in personality is between abstract thinkers and detailed thinkers. Abstract thinkers tend to "look at the big picture" and are very good at seeing conflicts between various parts of the system. Unfortunately, abstract thinkers accomplish this by ignoring details. The person who tends to be more detailed in thinking will tend to worry about how all the problems will be solved at the lowest level. They often miss inconsistencies at a larger scope because of this. However, the detailed thinker's ability to question small details can bring the abstract thinkers "down out of the clouds" and help them restrict their designs to what is doable. Once again, the combination of the two types yields a better result. However, if team members are not aware of these different thinking patterns, the team can end up with endless disputes and frustration.