Author | Shi Jianning
"The most important thing is to choose, the most difficult thing is to persevere."
I joined Ele.me in 2014, from the front end and PHP to the back-end architecture and team, from 2014 to 2017 successively responsible for the company's customer service, sales, agency, payment, settlement, order these business production and research and team; in 2018 from the business research and development team, 6 people teamed up a group to devote themselves to machine learning, trying to combine the actual business scenarios through technology to transform the business; in 2019 returned to the platform (middle office) research and development, responsible for trading, finance, Marketing three middle offices R & D and team work. Based on my 4 years of R&D experience at Ele.me and 2 years at Alibaba, I would like to share some of my thoughts from the technical, business, management and architectural levels.
Technical aspects
For development students, technology is the foundation of the establishment, although often interview to build rockets to screw, but it is undeniable that technology is the cornerstone of your career. Whether it is basic hands-on ability or problem analysis ability, including your thinking logic and even the ability to recognize things, technical thinking will always affect you. The most obvious effect is that when you are faced with the nails of countless problems, technology is not the hammer that you are most comfortable with.
Technically, I focus on a few aspects:
Basic skills (language, coding level, mainly hands-on ability)
Hands-on experience with large distributed systems (RPC, SOA, MySQL, Redis, MQ)
Projects (DB Design, API Contract, DDD Abstraction, Link Design, Project Risk Control)
Stability (Available & Loss)
1. Stability
Stability is a matter of consciousness and then ability. I remember that in early 2015, after Zhang Xuefeng joined Ele.me as CTO, one of the most common words heard from his mouth was "research and development should have reverence for the production environment."
In the second half of 2014, all parties began to enter the takeaway market, Ele.me launched the 100 cities plan for business expansion, covering from 10+ cities to 100+ cities in a short period of time, and the daily order volume quickly rose from 100,000 to 1 million. At the same time as the business is blowing up, the technology is not yet fully prepared. I have the impression that in the second half of 2014, the transaction volume at noon almost every day was a new high, but it was also accompanied by system downtime, current limit expansion, emergency tuning, customer service bursting, and technical overtime.
I once saw some customer service students in xinxiang customer service center suddenly crash, headphones directly fell down to leave the workstation, because every day will receive a large number of users to ask, just at that moment in fact, you will clearly and intuitively feel: every line of code you in the editor, every release you publish on the server, will have a direct impact on many living people in the real world, you will suddenly realize that your work is more important and meaningful than you thought before.
The so-called research and development should have reverence for the production environment, that is, you know that your work will have a bad impact on others, and you will feel ashamed and guilty about the bad results, which produces awe. There is a basic principle of emergency handling: "Focus on the least business impact, give priority to recovery as the core purpose, and do not dwell on means and root causes." ”
Don't reflect your remorse, determination, stability thinking, all kinds of wonderful ideas and execution at the accident review meeting, the safety production of the system is the same as the fire, it is meaningful beforehand.
2. Link design
Most of the production and research lack the perspective of the whole link, often see the point of their own responsibility, but for a line or even the entire surface is not visible, there is no opportunity to think about these, and for some large projects and long link systems, this is fatal.
My advice is that for the system you are responsible for, its key upstream and downstream, core business links must be familiar with, including data, interfaces (calls, functions, logic), various exception handling and special design. The easiest way to help you achieve this is to draw, draw, draw! The important conclusion is said three times, you must be able to draw the big picture of the system, and then you can zoom in and out at will according to the big picture. Zoom in to draw the link into the business scenario, highlight the business logic and upstream and downstream interactions, and narrow down to what the processing logic of a certain call is and how the data changes.
Draw pictures often, do not have to tangle with forms and standards, it is important to form a framework for your own understanding of the system, a way of thinking, which can be used at any time when needed.
Whether it is talking about needs or doing system design, habitually drawing out the picture, it is half achieved. The remaining half has to look at the picture to think and find problems.
3. Technical debt
Never lie to yourself that you should dig a hole for this need now and fill it in after a while (refactoring or redoing).
Technical debt, like financial debt, must exist and will always be relied upon like a scoundrel, erupting every three to five minutes. With the passage of time and the development of the business, you will find that the architecture is becoming more and more chaotic, the domain boundaries of different systems are becoming more and more blurred, the mapping of systems and requirements and organizational relationships is becoming more and more complex, the coding risk control within the service is becoming more and more inconsistent, and the repetitive wheels appear one after another hidden.
"Too busy to sort out which problems", "to change those problems need to be changed upstream and downstream together, time-consuming and laborious, push can not move", "now there is no problem, and is sorting out, do not urge." This is a sound we hear a lot. In fact, technical students are more or less a bit of code cleanliness, there are many problems not to deal with is not subjective reasons, but objectively because of energy, time, ROI and other factors, often after the problems really broke out, everyone can deal with those problems.
My previous approach to technical debt was to have a checklist, and I would regularly review all the systems and sweep all the mines in conjunction with accidents from my own team and other teams. The system itself is a balanced product, the result of a balance of time, function, risk, future possibilities, etc. Therefore, the test of technical debt for R&D students is not how you ensure that the system technical debt is 0 in your daily work, but you have to evaluate which problems are urgent and which problems can be put backwards under limited resources and time.
It's hard to imagine a team without technical pursuits developing a robust, maintainable, and scalable system. On the contrary, this kind of business code stacking may be "faster" to achieve business requirements in the short term, but in the long run, the increase of such rotten systems will greatly hinder the development of business and form a black hole application, and engineers are wrapped between business needs and rotten systems, tired of coping, exhausted. This will lead to the corruption of the system, the technical debt will become higher and higher, and the ugly code will grow wildly, consuming all your energy like a tumor, and finally killing you.
4. Be wary of big projects
Not everyone has the ability to operate a big project, not all people can balance the delivery pressure, on-line quality, product logic and time window, which is a very challenging job, requiring a lot of soft capabilities in addition to pure technical capabilities to assist, such as the organization's communication and collaboration capabilities, the ability to hold the power upwards, the ability to balance product business expectations, and the ability to change unexpectedly. The larger the project, the higher the requirements for Owner, and there are very few who can really do a good job of big projects without leaving big pits.
The time taken from the start of a large project to the establishment of the project is often far beyond the actual development cycle of the project, and the smooth progress of the project requires "compromise", but the success of the project needs to be adhered to. Many projects fail because they are constantly compromised in all aspects of the process, and the final thing is far from what they wanted to be in the first place.
Business level
In addition to technology, R&D students also need to improve their awareness and attention to the business level.
For R&D, business is like a foreign language, you don't understand business is like people in a foreign country, incompatible with the surrounding environment, and easy to lose! Compared with other types of work such as products, business, and operations, technology prefers to deal with technology, and business is chaotic and lacking order in the eyes of most students, without the clear implementation path and stable consensus knowledge structure of technology. And technology is relatively easy to falsify, and business is often constantly trying, research and development hate "uncertainty". But in a large organization, if you want to do a good job in technology, you must deal with the business, after all, the business is the core value of a company's existence.
1. Make technical planning based on business planning
Many students are accustomed to equating planning with planning. Ali is a commercial company that respects technology, all the teams are talking about business, planning is business planning, weekly reporting is business projects, reporting is business results, and when promoting, you must also highlight your "battle achievements". Compared with the technology itself, everyone pays more attention to what the technology has changed, and the reason why the technical team plans in the business part is this, which is the starting point (purpose) of the company's operation, and there is specific technical planning and organizational design as a solution.
Deeply understand the business and design the strategy, dismantle the campaign and the project, through the organization and various mechanisms to ensure the implementation and landing of the project, and finally get the business results, this is the standard strategy execution method of a large company. When R&D students do technical planning and team planning, we must take into account your environment, what the company wants to focus on this year, what are the goals of the major departments, what is the status quo of the corresponding products and businesses, and where are the benefits of pure technical iteration in the business. In addition, what force majeure the team currently has, or resistance to the progress of the plan.
Many students will habitually follow this idea when making plans: summarize the current situation (pain points) and the corresponding solutions and strategies to look forward to the future. Sometimes the order of the sum is reversed. Many times people find that the final departmental plan and their own planning are not related, do not know how to force in which direction, or simply continue to follow their own plan first.
For most of my classmates, I recommend planning realistically. Before doing technical planning, talk to the R& D team around you, talk to your corresponding products and operations, know what their goals are, know what the company's key points are, and then combine your current pain points to find a balance before the present and the future, and find the part that has benefits now and in the future.
The plan needs to contain some hard content, such as what problems this goal wants to solve, how to determine that it is solved, whether it is solved well, and who recognizes the good results. Planning must have a focus, without a focus that is not called planning, that is a schedule plan. Many students do not invest in planning, but also have their own "ideas", such as the company's business or strategy changes too quickly, organizational adjustments are too frequent, in the second half of the year in which team to work or even do nothing is not certain, so the planning is not serious. I don't deny the existence of frequent changes and the impact of this organizational change on planning, but if you think about it all the time, you can never get value from change because you keep it out of it.
2. R&D is more business-oriented than product
Lei Jun once said: "Never try to cover up your strategic laziness with tactical diligence." "For R&D students, you must understand business better than business students to find a space for technology and business balance." For most students, it is often only familiar with the system they are responsible for, but for students who want more space and more growth, I can give a clear conclusion: it is not enough to be familiar with the system for which they are responsible.
First, different people have different definitions of familiarity. Familiarity with systems where you are responsible, you contribute code, you design, and requirements are delivered is not enough. You must not only know its past and present lives, think about its growth, and tangle with its future development, but also be clear about its risks and hidden dangers, its life and death.
Based on your most aware core system, it starts to do the extension of the business scenario, so as to understand your upstream and downstream, and can be combined with the business scenario to dig. From the perspective of business, from the link of the product, from the technical tuning and hidden dangers of multiple perspectives to cut, let their design dimensions and perspective continue to rise, so that you have the grasp or control of the scope will be larger and larger, the future will have more opportunities.
Management level
The team is a macro and micro coexistence of things, macro we say organization, strategy, planning, to line up, microscopic we pay attention to communication, growth, emotions. The reason why most students are frustrated on the micro level is because they have not been able to grasp the macro rhythm. The company is a profitable organization, the technology center is a cost department, and the reason why the technology center has an organization must be: "The company expects this organization to solve a certain type of problem and solve it to a certain extent." ”
So here you have to understand a key word, "outcome and KPI" does not depend on how you define it, but gives you the goal of the organization and managers what expectations of you, your GAP is often not necessarily the difference in results, but the gap in expectations.
1. Embrace change
In fact, most of the time you don't need to hug, the change will suddenly hug you, tighten your neck and make you feel breathless for a moment. The reason why Internet companies change quickly depends largely on their business attributes, compared with traditional companies, Internet companies can feel the degree of compatibility with the market faster and clearer, and adjust strategies in a timely manner.
Combined with the experience of these years, to join Alibaba in the past two years, my core feelings are two:
The first is to be sensitive to changes in the development of the business and the environment. If you can initiate change proactively before it comes, it is best to turn passive into active. Even if you can't, you must clearly feel and think about where the motivation behind the change is, and find the key point of strength so that you can adapt to the change.
The second is the adjustment of work content, the adjustment of the reporting line, the change of the team, etc., whether good or bad, in a period of time are relative, rather than absolute in a person's working life. In the case that it is impossible to do everything well, adjusting your mindset, allowing yourself to jump out of your emotions, and paying more attention to things in itself will be a better choice.
2. Adding people does not solve the problem
Even if you say "no" in your mouth, you will be very honest in your actions, and you will still want HC as much as possible, hoping to build more "core" systems within your responsibilities. In fact, from a management point of view, you can see if you have "effectively added people", some technical Leader does not pay attention to the landing of newcomers, which is equivalent to only focusing on quantity and not focusing on quality, and the final result is definitely a mess.
From an absolute theoretical point of view, adding people is definitely helpful, your resources become more, the turnover space and the room for operation are abundant. But from experience, in most cases, the canadian does not produce a final change in value (the outcome of the project, the success or failure of the business). Because the development of the system and the promotion of the project are not simply resource accumulation, the system of 1000 people's day is made by 1000 people in one day. In the real world, we are often not defeated in the use of resources, but in the direction of the use of resources and the efficiency of use.
3. Consciously manage upwards
This problem stems from two points of past experience: First, I have experienced countless organizational relationship adjustments, and I have found that whether it is myself or my teammates, everyone pays more attention to their own reporting lines than what they do and how many people they do without people. Who I report to, who is my Leader, I can't get along with others, can he let me improve and grow. Second, many students will be confused about their relationship with Leader.
Based on these two points, I added upward management as a separate topic, first of all, the conclusion: yes! want! want! A must! A must!
Even Teacher Ma said that one of the three major elements of employee departure is not to get along with Leader, how can you still ignore it with peace of mind. If everyone still stays in the attitude of obedience or even flattery to deal with your relationship for upward management, I can only say that it is too childish. I have not systematically learned upward management, nor have I systematically read books on this subject, so I will only say my understanding.
If an individual wants to get paid and benefits in an organization, the basic way is to promote the growth and improvement of the organization, and improve themselves at the same time, so that they can share their share of the benefits. This requires that the results you produce are positive spillovers to the organization, but this direction and standard are not clear or accurate for everyone.
Students who often have poor performance are frustrated and even complain that they often work overtime, even the latest in the department, and have to deal with work on weekends. Without discussing the background, if you hit the above one, I will give you a piece of advice: except for the per-piece factory, there is no obvious direct relationship between physical effort and the final result. Just like when you go to school, there must be a few other people's children, either they are particularly hard at studying very well, or they seem to play with you every day, but the grades always crush you. From school to society, this phenomenon has not disappeared, do not believe in overtime and physical efforts, most people as long as they can not think, physically willing to make a contribution, far beyond your imagination.
Getting along and communicating with Leader is essentially about agreeing on goals and mutually recognizable outcomes. This is a very key intention, I sometimes joke with the team of classmates, saying that you have to take a good look at what my Leader really wants to do, so that you can make it, I can report. The focus of direction, rhythm, and results is crucial to the development of the work and the achievement of the results, and at the same time you need to get more information from him to facilitate your own judgment and decision-making and learning, and constantly draw nourishment from them.
In some environments, physical effort is a must, but only physical effort can only touch yourself in the end, and your team does not want to accompany you every day until 11 o'clock or post until 2 am, and there is no interest in pulling a call at 1:30 a.m. to discuss the plan. So be sure to do a good job of "expectation management", Leader's expectations of you, expectations of the project, your expectations of the space and support you give him, everyone must focus clearly and have the same goals.
Architectural level
Another point that I think is also very important is to have a clear understanding at the architectural level, including business architecture, technology selection and detailed implementation.
1. The most critical issue is the issue of definition
Albert Einstein said, "It's more important to ask questions than to solve them!" "Defining a problem is a mental exercise, solving a problem is a physical job. People are often accustomed to seeing a problem and rushing up to hammer it, from the probability point of view, it is very likely to fall into a black hole to solve the problem, that is, you are constantly solving the problem, but in the end your situation does not get better.
When you are faced with a difficulty or a situation, the first important thing is to define the problem, what exactly it is to solve, what benefits it is to solve, and how to determine how to solve it. The second is to define the structure, the key points of the problem, what is your corresponding solution, how to weigh the gains and losses, and how the effect of the final solution runs through and penetrates, from point to surface.
A team can work non-stop, but it may not be able to achieve results. Most of the habits are used to listing the problems they face, but they have not done a global analysis and combing of these problems, in fact, the most difficult thing is to "find the problem".
2. The essence of the problem is not so profound
Sometimes we do a project, there may be a product demand, everyone feels that it is difficult to do or can not do it after reading it, because the system is not supported now, the cost of transformation is too high, and there are many uncertain technical risks. I believe that few people in this situation will brainlessly ask for additional people and processing periods to solve this problem. In most cases, we will see if there are shortcuts or other solutions to make the product effect achieve, even if the technology is dirty and around.
In fact, at this time, dig more horizontally and vertically or ask more questions, and there may be different answers. What problems this need is solving for users, whether this solution is currently the only one in the business (product, technology), what costs and new problems this solution will bring, whether other projects that are currently being promoted will be related to this problem, and whether there are other teams that are solving similar problems or have been solved.
3. Achieve your goals
In the work, from talking about an API contract, to going online to a demand, to completing a promotion, everything has a successful method. Identifying shortcomings, setting a plan, resisting setbacks, repeated training, and tuning according to feedback can solve any problem. Dalio, CEO of Bridgewater, author of "Debt Crisis", summarizes a five-step success method that is interesting:
The famous great mathematician Polya has a famous book "How to Solve Problems", which gives a four-step solution method, which may be more feeling from the perspective of research and development:
4. Continuous learning is fundamental
The times are constantly developing and changing, and now is the era of great waves, in such an environment, no matter how the current accumulation, it is possible to fall to the bottom in a short period of time with the changes in development. The company can develop, must be in a certain period of time very in line with the requirements of the environment, but with the change of time, if its changes can not keep up, then it will only be abandoned by the times. The so-called success that makes you successful will eventually make you fail, such as Kodak, Nokia can not be spared, and individuals can not escape such a law.
In this case, the ability to continuously learn and change oneself is the biggest and strongest advantage of R&D students. The rapid development of technology itself requires you to continue to learn, the same habit radiates to various fields, will slowly learn from each other's strengths, optimize themselves, so if the research and development of students need what is the most, I think the continuous learning ability is the most critical.
As Wang Yuan, the founder of Hungry Mo, had a sentence in a previous interview that made me unforgettable: the most important thing is to choose, and the most difficult thing is to persist.