Technology serves business.
If a technician wants to go further, he cannot just limit himself to technology. He needs to have a deep and comprehensive understanding of the business field in which he is engaged.
The so-called business field is when everyone introduces themselves. They don’t just simply say that I do C++, I do JAVA, but game backend C++, advertising engine C++, e-commerce backend JAVA, big data JAVA, and the games in it. /Advertising/E-commerce/Big data is a large business field. What we usually come into contact with should be smaller and more specific businesses in the business field. For example, in advertising, there are display advertising, search advertising, and feed advertising, and these businesses (domain knowledge) are still changing and evolving.
Product managers (product experts, senior product experts, senior product experts, product directors) constantly think about the development of the business, and then convert these thoughts into individual requirements, and then generally present them to technical staff in the form of projects, expecting to think about the product. It can be implemented quickly and get usage and feedback (as well as analysis data) from users as soon as possible.
For technicians, they may spend a lot of time in the process of receiving product requirements, analyzing the requirements, considering/writing technical implementation plans, scheduling, working hard, rushing to go online before the deadline, calling it a day, and repeating the cycle.
Over time, we are in such a cycle without knowing it, and become a demand fulfillment machine. Although for technicians, the most important thing is technology, and the main focus is on system architecture, system stability, system availability, system operation and maintenance, rapid iteration capabilities, traffic peaks, etc., but as we said before, in order to To go further, you need to have more understanding (and control) of the business.
Recently, I have had some input and thoughts on how technicians can improve business sense (deepen their understanding of the business), and I would like to share it with you here.
1. Focus on the business problems to be solved behind the requirements, rather than the needs of the product manager
Many times the product manager proposes a solution (having made his or her own understanding of the business problem to be solved and converted it into a solution that he thinks is the most appropriate), rather than the original business problem to be solved.
Technical personnel need to find the original business problem to be solved by themselves, understand and analyze the problem themselves, consider it from a technical perspective, and evaluate whether the solution given by the product manager is the most reasonable/suitable. If it is unreasonable/inappropriate, Then give the solution you think is most appropriate.
When you receive a requirement, you must first make a basic judgment yourself whether what you receive is a business problem to be solved or a solution.
What people engaged in technology development must avoid is to receive a requirement (solution) and immediately start to evaluate the workload and schedule, and then finish the work and go online. Then, the next (demand).
for example.
The product manager put forward a request to the technician and asked for the construction of a ladder. The requirements are very clear, what materials need to be used to build the ladder, what length is required, what width is required, and how much weight it needs to be able to bear.
Once the technical staff received this requirement, they began to evaluate how much material would be needed, how much construction and testing period would be required, and then work would start.
Actually we should stop for a moment. "Build a ladder" is a solution, not a business problem to be solved.
You might as well ask the product manager what the ladder is used for. Used to replace the bulbs in the central chandelier in the room. Why change light bulbs? Because the light bulb is not bright enough, the room is too dark during the day. So the business problem to be solved was lighting in the house.
Then there is no need to go to the trouble of building a ladder. Maybe we can lift the thick blackout curtains and the room will be bright. Well, no need to waste time and money building ladders, you are happy, I am happy, everyone is happy.
2. Technical personnel must have business curiosity
I recently heard a point of view about technical personnel, which I found very interesting, because I was immediately struck by the idea: Give technical personnel a deadline, and all their energy/attention/efforts will be focused on the deadline, and their entire thinking will be concentrated. How to complete the project before the deadline.
I made up my own mind: a dog, no matter what it was doing before, as long as you let it notice the meat bones in your hand, its eyes and energy will be focused on the meat bones, no matter you are holding the meat bones Hold it high, or throw it out. Deadline is the meat and bones that technicians focus on.
It seems to be an instinct to pay full attention to the flesh and bones, but people need to overcome this instinct to achieve more progress and growth.
After participating in a project, you cannot just assess the workload, schedule, and kickoff, and then focus on the deadline to rush the work and finish the work quickly. You must be curious about businesses other than technical solutions. On the basis of ensuring that the project is completed on schedule and with high quality, you should take time to understand the business issues and business changes behind the requirements, expand your knowledge of the business, and deepen your understanding of the business. . Many projects generally involve multiple teams/departments, which are rarely seen in normal times. It is a good time to communicate and understand other than the work you are responsible for.
The biggest difference between people is the way of thinking. Only by continuously upgrading our way of thinking can we stand higher and go further, and encourage you all.