Throughout this semester, team communication has been one of our biggest learning experiences. When we began this project, our communication skills were less than ideal, but I like to think we’ve made a great deal of improvement over the past couple months. I thought I should share the biggest lesson about team communication I learned this semester: be aware of how your work affects others.
Working on a single product with such a large team means much of the work is interconnected. In a given day one person might design a UI layout, another person writes the code to implement the design, a third person writes the text that will appear on screen, and so on. Each one of these steps is challenging work, and it is easy to get so focused on your task that you forgot to consider how your decisions will impact the other steps in the process. If the layout designer creates a design with space for only two lines of text, but the text writer needs four lines, the designer must spend time to revise the design. Now suppose several people had already begun implementing the original design in code. This code must also be revised and more time is wasted. Something as simple as adding a couple extra lines of text to a screen can often take several hours of team effort to accomplish. Lack of communication is one of the biggest impediments to team productivity.
The solution to these communication breakdowns is to be cognizant of how your work will affect others. When making any decision (art, design, CS, or anything else), take a moment to consider the “ripples” that decision will create. If I change this section of code, will it conflict with changes another developer is making to the same section? Will my change interfere with the UI layout someone else is designing? Will it force some art assets to be modified and resized? Asking these questions to yourself will sometimes reveal consequences you hadn’t considered before, but often you will still be unsure of what your change will affect. This is a sign that you need to go talk to other people. Ask the other developers if they are working on the same class you are, show the layout designer the change and listen to their opinions and suggestions, and ask the artist if the change will force the assets to be modified and if this really is the best course of action. Not only will these quick discussions save time by avoiding later revisions, they also show how other disciplines approach problems differently and that your approach may not always be the correct one.