Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • How To Fix Miscommunication Issues Within Your Team

    [01.07.21]
    - Ryan Sumo
  • Good communication is important in all game development studios, even the smallest ones. You may think that small teams are immune from miscommunication, but if you think about it, you can have miscommunications even with the people closest to you (just ask my wife).  The only way to avoid miscommunication within a team is to be like Eric Barone and make a game on your own. For everyone else, practicing good communication skills is the only way that you can reduce friction in your team communications.

    Good team communication may sound like a silly thing to be worried about, given all the things that can go wrong with a game. But I'm sure you don't have to go back too far in your memories to remember an interaction with a teammate that should have taken 5 minutes, but instead took 30 minutes and left the both of you exhausted.

    In the following case studies I'll lay out some of the communication issues I noticed within our team, and how we tried to rectify them.

    Mahirap ba to? (Is this hard?)

    Since no one is immune from poor communication, I'll use myself as an example. Often when new feature request would come in, I would ask our devs the question "Is this hard?" and receive some of the following answer.

    Answer 1 : "Not really."

    Answer 2 : "Yeah it's hard."

    Answer 3 : "It's not hard but it will take a long time to implement."

    Inevitably, this would lead to more questions as I tried to figure out the level of difficulty of the task. Eventually I realized I was actually asking the wrong question. The last answer helped provide me a clue to what the better question actually was.

    What I really wanted to know, in the context of my role as a project manager, was "How long will this take to implement" so that I can assess whether or not it is worth adding to the game, given its presumed impact. Since I came to this realization, i've been asking "how long" instead of "how hard", and saving the team around a minute or two everytime these conversations come up.

    Tatamaan Memory (The Memory Will be Hit) and Programmer Jargon

    A problem that often occurs when programmers speak with non-programmers is that there are things that are jargon or just presumed as understood by non-programmers. While jargon can be useful sometimes if its clear that both parties understand what's being said, once it become apparent that there is some misunderstanding, further clarification should be offered. It should be incumbent on the person using the jargon to be the one to clarify what it is they are trying to say.  The following are some common responses given to me by our programmers. Initially they were inscrutable to me, and took quite some time to have them explained to me. I still forget what they mean sometimes, but maybe that's a sign that I'm getting old.

    1. The memory will be hit : This basically means that this will add to the game's memory usage, and may cause some issues in the long run. It would still be useful to follow up on how much memory this will actually use and what the actual danger would be.

    2. This needs to be saved : This basically means added complexity to the game, and larger save files, which we are trying to avoid.

    3. We need to "keep track" of that : To be perfectly honest this still confuses me sometimes.

    The important thing to consider here is that while jargon can be a useful shortcut between two people who understand each other, there needs to be a clear understanding that if the jargon is not understood, then an explanation is needed. Speaking of which...

Comments

comments powered by Disqus