I was sitting in a meeting last week on a WebEx call where the person on the call was describing some UI functionality in an application. Video and all. The behavior was a surprise to me (not in a good way) so restated my understanding of the operation to make sure I understood. A very common practice of mine, but it can make me sound dumb at times. On my statement, others around the table gasped and stated that I was wrong and the behavior was something else. I had heard wrong!
Others around the table saw the same screens, video, heard the same words and had come to very different conclusion. This only became apparent when I restated what I had understood. To the shock around the room, my understanding was correct. Their faces spoke surprise that what they thought was true was false.
This was a simple version.
When you apply statements made by developers to managers or QA to developers, the repercussions grow larger. As we like to think that software development is engineering, much of the details of a project are only verbal. It's hard to capture every nuance and detail in documents that others can and will read and understand. Heck, even with words and video the details can be lost!
What does "Done" mean coming from a developer?
What does "Bug ridden" mean from QA?
What does a developer hear when PM describes how a feature works?
I run into this every day while working and I almost always need to respond with my understanding of the topic. With some people you may need to cycle around 3 or 4 times to gain a common understanding of the issue at handle.
I've not seen a protocol or process that provides the communication and understanding to avoid this happening. It's built into us to hear what we want or are expecting to hear.
You have to verify.
Others around the table saw the same screens, video, heard the same words and had come to very different conclusion. This only became apparent when I restated what I had understood. To the shock around the room, my understanding was correct. Their faces spoke surprise that what they thought was true was false.
This was a simple version.
When you apply statements made by developers to managers or QA to developers, the repercussions grow larger. As we like to think that software development is engineering, much of the details of a project are only verbal. It's hard to capture every nuance and detail in documents that others can and will read and understand. Heck, even with words and video the details can be lost!
What does "Done" mean coming from a developer?
What does "Bug ridden" mean from QA?
What does a developer hear when PM describes how a feature works?
I run into this every day while working and I almost always need to respond with my understanding of the topic. With some people you may need to cycle around 3 or 4 times to gain a common understanding of the issue at handle.
I've not seen a protocol or process that provides the communication and understanding to avoid this happening. It's built into us to hear what we want or are expecting to hear.
You have to verify.
Comments
Post a Comment