Reflection: Language Communication and document communication in project development

Reflection: Language Communication and document communication in project development

Problem: A mentor arranged to develop and implement some functional modules or small applications during the trial period of the company. After all, you need to add code under the framework of the entire product. After reading the source code of nearly 1 GB of the entire product, it is quite vast. Although we do not need new personnel to make overall planning, we need to know at least the position of the current module, as well as its interface and call relationship with the upper and lower modules. My current task is arranged by the tutor orally, because I am not familiar with the product framework, Module Interface, and so on, which leads to the problem of language communication, the instructor thinks that every time I have made a very clear explanation of what the requirements are and what functions need to be implemented, I need to know a little about the background to implement it. Because of the tight project, I quickly thought about writing code after communication, did not list the ideas, did not form a concise document to feedback to the tutor for confirmation, so I had to repeat the work and took a detour.

Reflection: In addition to oral communication in the project, does it delay time or improve efficiency for necessary document exchange confirmation?

Personal thinking: I attended a management training course four years ago. The lecturer is the "Turtle" of MIT. He gave a case study and tested the communication and understanding abilities of the team. In this example, he drew an irregular figure on the paper (of course, it is not very messy, and the language must be clear), and then he chose one audience member to come to the stage to describe the figure in a language, the rest outline the Image Based on the man's description below. Finally, you can submit the image "work ". How far is the difference between the original graph I drew and the instructor's original graph?

The personnel directors with strong communication skills and other management talents were chosen on the stage. What are the results? Actually, each person draws a different picture, which varies greatly from the position, proportion, and shape of the image. But the colleague who was chosen to describe the image felt "it is already very clear that there should be no such big difference ".

Yes, this may be a problem caused by communication and different understandings. That is to say, each person has different expressions, verbal expressions, and comprehension abilities for the same thing.

Single communication without feedback is actually terrible and the results are unpredictable. Everyone thinks they have made it clear. However, due to the differences in communication methods, expressions, and center of gravity, the ideas of the listener may be different or even different.

My personal conclusion: if the above communication involves an interactive reverse validation communication with the speaker at each key point, such as the location of the whole piece of paper, the size of the image, and the inflection point, the graph difference is not that big.

This means that communication is necessary in the case of tight time and heavy tasks during project development. Confirm the task, the goal to be achieved, and how to break down the task through communication. However, if you do not write these things down, unless the speaker's idea is very clear, unless he has previously implemented this function and is "easy to learn", it is easy to see deviations. When you wait for a while, you will find that the ideas of the speaker have changed, and there are problems with your understanding.

We believe that the following feedback communication is necessary: Language Communication (assigning tasks) -->
After receiving the task, establish a general process, form a concise Number of documents, think about marking several possible core points --> communicate with the Speaker, confirm the core points of the document -->
After confirmation (that is, the speaker has recognized the ideas and solutions of the listener), implement the Program and write the code.

Of course, this process may be repeated, but at least it is much better than single-item communication, and the improved efficiency is more than just a little bit.

Another point is that, in the development after the transition, there will be all the processes in the software engineering, such as requirement analysis, overall summary design, detailed design, coding, testing, and maintenance, as a programmer, I will write summary design and detailed design documents, or refer to other people's documents to complete coding. The above documents should all be a document solution that has been communicated, fed back, and negotiated by the team, there may be no such detours.

Have you ever encountered a similar problem? How did your team solve the problem? Is there a good solution? We are looking forward to communicating with you. Thank you!

Am8: 07 on the bed (I have been entangled in this problem, and I have to write it down for a reason. It will be smoother in the future !)