Some examples of inefficient technical communication
1 Unclear description of technical problems, inefficient resolution
Classmate A encountered technical problems at the delivery site and asked for help from classmate B in the project group.
Classmate A: Big guy, after the cloud architecture is changed, the database cannot be planned.
Classmate A: The solution cannot be exported.
Other classmates CDEF: Discussing other issues disrupted the context.
Classmate A: The database cannot be planned, and the risk is reported.
Classmate B: First describe the problem clearly.
Possible mental state of classmate A: This is a product problem, not mine. I have posted the log and screenshots in the group. You can climb the stairs to see for yourself.
Possible psychological state of classmate B: What is the problem? I have to climb the stairs to see. I am not free now, so I will not deal with it. ...... N hours later, Nani, which group was in @我 just now, there are too many groups to find, there is no phone, it seems not in a hurry, go for a meal first.
Classmate A's mentality and methods need to be changed: Whose question is not the most important thing, the most important thing is how can I let the interface person in the next link understand what this problem is in the shortest time? Let him know that I am anxious waiting for the rice to be cooked.
Feasible questioning methods: For example, you need to nail the fragment information that you need to climb upstairs, and then ask after refining it: "There is a problem that needs to be solved by you. The problem phenomenon is xxx, our expectation is xxx, what we actually see is xxx , Does not meet expectations. From the log and error report, it may be that there is a problem with xxx. Our xx project is online and needs to be resolved urgently.
2 The scheme is too abstract and has limited reproducibility
An online technology sharing live broadcast, after the meeting, some students consulted on training details.
Lecturer C: In our solution, the controller calls apiserver for scheduling, and then apiserver queries the database for metadata configuration information, and then sends a request to the business server. Barabara, I won’t waste too much time for everyone, speak quickly.
The training ended, a round of applause.
Classmate D: I need to use this plan to communicate with customers. I have to clarify the principle a bit and add some text descriptions to make it easier for customers to understand.
A telephone conversation
The possible mentality of Lecturer C: I have already painted it clearly, and I have also given training. After listening, I have to think and digest myself.
Classmate D’s possible mentality: these frames are easy to draw, without corresponding instructions, the effect of communicating with customers may be poor, and you need to find different people to cross-validate, and then re-complete the materials.
Lecturer C's mentality needs to be changed: the best way to learn is to teach others in plain language. If you can't make it easy for others to understand, it means you haven't mastered it thoroughly.
Feasible ways of communication: The time for sharing last time was relatively limited, and I didn't say it thoroughly. Using a popular example, it may be better to understand....500 words are omitted here. Then combined with the customer scenario, the two parties had a more detailed discussion, each with its own results.
3 The core issue (technical decision point) is not prominent, and the efficiency of technical review is low
Classmate E introduced a three-computer room solution to the customer, requiring the customer to make a decision to choose the physical third computer room or the logical third computer room, but after listening, the customer did not get the decision point?
A decision report meeting
Feasible communication methods: After the introduction of the plan, sort out the advantages and disadvantages of the two candidate plans, and mark the red and bold decision points.
In the above scenario, there are 2 problems to be solved:
- Not enough empathy. I only considered what I needed, without considering the other party's interests and risks.
- Did not use language that the other party can understand.
Two solutions
- Empathy is a change of consciousness. This change is easier said than done. There is a core point in the book "Lifetime Growth": Compared with the idea of "proving that I am better than others" and "this is not my problem", the idea of "solving problems together and learning more" is more Contribute to growth.
- Borrowing Feynman's learning method to solve the problem, the core point is "If you think you have learned a certain professional knowledge, see if you can teach this knowledge to a 10-year-old child."
Feynman himself is a Nobel Prize winner and a famous educator. His learning method is divided into four steps:
1 Choose a concept
Pick a concept you want to learn.
2 Teach this concept (the soul of Feynman technique)
Imagine that you face a rookie in this field, or even a ten-year-old child, trying to explain the concept clearly and let the other party fully understand it.
On the one hand, deepen your understanding, on the other hand, find nodes or stuck points that you don’t understand.
3 Check for leaks
When you can't explain, look back for the answer.
Go back to the book, go back to find classmates, find teachers, find people who already understand, and re-study this concept.
The result requires that you be able to interpret this concept fluently again.
4 Simplify language and try analogies
Continue to sublimate. If it is an academic or abstract word, try to explain it with concise words and compare it with other things. In particular, the purpose of the category is to better understand the core point of view, allowing small differences from the original technical intent.
Three experience the process of Feynman learning method
When the author first heard someone introduce the function introduction and implementation principle of the registry in microservices, I felt a little confused about the terms RPC, RS, SessionServer, DataServer, and MetaServer. The author had an idea at the time. If I introduce microservice products to customers, how can I make them easier to understand? So I started to find the official website documents and the documents of the R&D team after understanding, and then introduced them with small stories in life.
1 What is RPC?
Technical explanation
The essence of RPC (Remote Procedure Call) is to shield the details and complexity of the network, provide easy-to-use APIs, and allow users to implement remote calls just like calling local functions. Therefore, the most important thing for RPC is to implement it "like calling local functions". Remote calls do not allow users to perceive the underlying network at all. The effect of "high cohesion and low coupling" is achieved through RPC calls between different containers in the Sofa product.
Popular introduction
A few of my best friends were shopping, and some people said that they suddenly remembered the confiscation of the courier and wanted to go back to collect the courier. Another person said, just call back and collect the courier for her husband. Explain to your husband the information of receiving the courier in advance (which courier company, where is the courier, what is in the courier, the recipient's name and phone number), call the process of remote operation of the husband to receive the courier, called RPC.
2 What is a registration center?
Technical explanation
Registry refers to a highly available service registry with the ability to carry massive service registrations and subscriptions. The Registry service registry is divided into four roles: client (Client), session server (SessionServer), data server (DataServer), and metadata server (MetaServer). Each role combines different capabilities to provide external service capabilities.
The main components of the Registry service registry are:
- Client: Provides basic API capabilities for applications to access the service registry. Application systems rely on the client JAR package to programmatically call the service subscription and service publishing capabilities of the service registry.
- SessionServer: Session server, provides client access capabilities, accepts client service publication and service subscription requests, and acts as an intermediate layer to forward the published data to DataServer for storage. SessionServer can be infinitely expanded to support massive client connections.
- DataServer: The data server is responsible for storing the data released by the client. The data storage performs consistent hash storage according to the data ID, supports multiple copy backups, and ensures high data availability. DataServer can be infinitely expanded to support massive amounts of data.
- MetaServer: Metadata server, responsible for maintaining a consistent list of SessionServer and DataServer in the cluster, and timely notifying other nodes in the cluster when the node changes.
Popular introduction
Registration center products can be understood as second-hand housing intermediaries. Service registration/discovery/invocation in the microservice architecture can be compared to the process of buyers and sellers completing real estate transactions through intermediaries.
- Client: The client can be the buyer or the landlord.
- SessionnServer: Similar to an intermediary store, it is responsible for receiving buyers and landlords. Stores can be added based on business growth.
- DataServer: Similar to the back-end database of an intermediary company, which records customer data of all stores, including buyers and landlords.
- MetaServer: Similar to the store system of an intermediary company, maintaining store and customer data, which is invisible to buyers and landlords. When there is a change in store or customer information, all stores are notified in time. For example, if a house suddenly drops by 200,000 yuan for urgent sale, it is necessary to notify all stores to find customers.
Service registration process (landlord sells house)
Service subscription process (buyers buying houses)
Service invocation process (buyer inquiry)
Four build your own scene library
1 Maintain a glossary of its own and identify high-frequency terms in the customer communication interface
The knowledge that passes through the body belongs to you, even if you see material written by others, copy it again.
2 Prepare an introduction with life scenes for high-frequency terms
Usually observe the relationship between people/things/things in life, the way is natural. Many design models, such as agency model (example: patent application agency), chain of responsibility model (example: submit an application for house purchase qualification, don’t care which commission will handle it, and finally get the qualification for house purchase), observer model (example : After a bank publishes a project bidding requirement on the bidding website, all kinds of Party B manufacturers subscribe to a new project bidding, swarming), etc. can find similar shadows in life. The author is dull, and I cannot list all design patterns here.
3 Take notes in time and keep updating
Preparing stories or scenes for high-frequency terminology is not something that can be perfected over a period of time. Sometimes it is inspiration that pops up suddenly in the middle of the night, and sometimes it happens to be better written in a document.
This article is the original content of Alibaba Cloud and may not be reproduced without permission