Perception

[Note: This entry was written for the module, CS3216]

Teamwork is a concept that is continuously expounded, and in the Second Lecture it was touched on briefly as an elementary yet critical foundation in software engineering. Like most concepts, the idea of forging interpersonal cooperation is easily digested in theory, but in practice, every team is likely bound to have problems which need resolutions that are more convincing than a chapter from a textbook.

My team for the Facebook application development assignment was not spared from this hypothesis unfortunately, and the lesson for me is that I’ll have to learn to pay more attention to certain aspects of team dynamics in future. One specific challenge is that while it is necessary to define roles, it is more important to define tasks.

Every member has a role to play, and what one contributes is a function of his or her value to the team. One’s value, as ambiguous as the term suggests, is subjected to being measured by everyone else, and the problem here is that the scale used varies across individuals. This leads to a certain degree of fragmentation by roles held by each member, and one is likely to value one’s work more than that of others.

Programmers probably find it easier to measure their work, either by lines of code or features implemented. It seems relatively straightforward when dealing with logic. Designers may find it more difficult, for if they spend long hours without a dose of inspiration and have nothing to show for it, then it’s hard to justify these hours. Business guys, too, may have their own challenges when it comes to quantifying their marketing or branding efforts, as these are not always easily measured.

Time may seem like a fair metric, but different people have different levels of productivity, and the amount of time a particular task requires is not always definite. Furthermore, as mentioned, it’s also hard to quantify the time spent staring at a blank Photoshop canvas, let alone time that is spent interacting with users for qualitative feedback.

What can be done to alleviate this problem is if the team members are upfront with what they can contribute, and to define or quantify it in a way that is meaningful in the overall scope of the project. Goals and milestones help define the work that is to be done, and every member in the team should have a measurable goal.

The programmer could aim to develop a specific list of features by a certain deadline, while the designer could talk about the exact number of mockups and design elements like icons or buttons that need to be done. Even the business person can quantify his or her tasks, such as the number of customer surveys he or she intends to do, to give one example.

If it looks like one has little or nothing to do, then I would argue that it is that person’s responsibility to step up and take on an additional task. There will always be work to do; handling administrative matters or updating documentation comes to mind. But beyond that, every member should let the team know just exactly what he or she is doing, and taking this initiative helps everyone get on the same page with regards to the work distribution. This also prevents confusion and subsequent responsibility-shifting.

So, while it is probably not possible to measure each individual’s contribution on a common scale, having specific, quantifiable goals and communicating clearly what one is doing helps everyone see the big picture better.