The front end early chat conference, the new starting point of the front end growth, held jointly with the Nuggets. Add wechat CodingDreamer into the exclusive inner push group, win in the new starting line.

The 14th | front-end growth promotion, 8-29 will be broadcast live, 9 lecturer (ant gold suit/tax friends, etc.), point I get on the bus 👉 (registration address) :

The text is as follows

This article is the fourth session – front-end career planning lecturer – Yuanzhou sharing – “how to make expert level technology and technology product planning” :

Contents summary

Hello, everyone. I am very glad to share with you my thoughts and experiences on front-end technology and technical product planning in the early planning session.



Let’s get an overview of what we’re going to share todaywhy.How to do“And, for example, chestnutsThe specific idea of planning.



1. Get acquainted




  • In 2010, he started his own business with several older brothers after graduation.
  • Later, due to my interest in front-end dynamic effects, I joined Ali at the end of 2011 and became a subsidiary of The Light Cavalry business of Alibaba.com.
  • In 2012, he began to participate in the DPL system construction of Alibaba.com.
  • 14 years later, I became the DPL director of Alibaba.com and was promoted to senior front-end engineer.
  • At the end of 2015, I started Fusion Design.
  • 16 years, promoted to front end expert.
  • In 18 years, I left the B2B zhongtai team to join the new retail one line hema
    • Build the store digital business and front end team from 0 to 1
    • Build shelf visualization from 0 to 1
    • Multi-end multi-role workbench
    • Decision task flow
    • Online and offline experience system, etc.
  • In 2019, considering my own development, I left Hema and came to the B-side of Tax Friends, responsible for the big front-end team and exploring the commercial value of experience technology in b-side for digital transformation and upgrading.

2. Why plan

2.1 a shortcut?

Do you want to know the quick way to grow from the front end to the front end expert? As the saying goes, there is a path to the book, I want to write code.



Let’s start with two examplesLittle of the newtomasterAnd then we’ll see if there’s a shortcut on the front end.



King of glory may be many of us have played, bronze players is biubiubiu, gold players have a little bit of operation, platinum players know to Gank outflanked, diamond players will look at the lineup, king of players can basically judge where the enemy is doing what. Here’s a feature I don’t know if you’ve noticed:The competencies required at each level are differentAlthough the king is also in biubiubiu, the king is obviously more than biubiubiu.

Let’s look at another example of going from a piece of code to a technical product. Front end first reusable code should be similar to the reset, normalize code, to a greater degree of reuse and decoupling, after a modular, templates, such solution form scene, then in order to let the “material” to be able to better use, more convenient to use, so there will be a cad development platform tool for these materials, Norms, mechanisms. There is also a characteristic here: the types of problems to be solved at different stages of development vary not only in quantity, but also in capacity.

So I want to ask you, how long do you need to go from bronze to king? One year or three years? From page cutting to front end expert, 5 years? 10 years? Different people will be different. But if we know in advance what skills and abilities are required for each stage or level, and deliberately practice those skills as we practice and write code, we can speed up the process of moving from the current stage to the next.

Therefore, the shortcut is to take fewer detours, is to know the requirements of the next stage earlier, actively avoid some unnecessary pits, we need to write code from good to have a good plan to write code, so a good technical planning, is a shortcut.

2.2 What is the use of planning

What’s the point of planning?



  • From the perspective of value, if you are the leader of a team, or you are the core student of a team, then if you can make plans, the team will have a more focused sense of goal, and the collaboration will be stronger. And then the overall output will be more complete, and there will be less duplication, and then when you’re designing the whole solution, you’ll be more thoughtful, rather than saying you’re going to think about this one today, and you’re going to find another problem tomorrow.
  • In terms of my own ability, at the beginning, everyone may solve some short-term projects, but through planning, I will gradually change to how to solve long-term complex problems. Then in terms of scale, we can only focus on their own problems, but if the problems of its own, we slowly will involve others, also encountered similar problems, or problems met me, or meet some problems I don’t have, until you can solve the problem of people, planning can make us more early to recognize these problems.
  • After that is from the point of view of their own thinking ability. In fact, as the speaker mentioned just now, in P8, his thinking dimension is different. This dimension actually comes out of here, and when you first think about your problem, you might think about it as a single point and a scatter of single dimensions. Let’s start with the single point, and then you’ll see that there’s some logical relationship, or some commonality. We are likely to think about these problems from horizontal, vertical, global, long-term in-depth, multi-perspective, multi-dimensional direction.
  • Finally, I will gradually establish a thinking framework of my own, so that my thinking process will be more complete and orderly.

Of course, everyone may think in different directions, but if you have your own framework of thinking, you will be much more effective in thinking and solving problems. So, technology planning itself is actually a framework for thinking.

3. How to plan

3.1 Planning thinking mode

And then we say, how do we plan?

So first of all, let’s look at the difference between the way you think about planning and the way you don’t think about planning. The whole planning process, it’s a process from divergence to convergence.



When we do the planning, the beginning is divergent, divergence in the process, you may have a lot of good idea, may analyze all kinds of data, online all sorts of problems, and then the user’s jokes, team classmate teasing, your speech, there will be a lot of this information, we all regard it as a sensitive information.

What we’re going to do is we’re going to converge this information in a structured way into a thinking frame, and this thinking frame, like the one on the right, is the core of what we’re going to talk about today, how to do planning.

  • The first one is the phenomenon and the fundamental problem. The first step is to clearly identify the problem to be solved. In many cases, identifying the problem is more important than solving the problem.
  • Then there’s positioning and targeting, which is what we’re going to do and to what extent.
  • And then, for such a location and a target. We define the solution, which is the architecture and the solution.
  • Once we have the core solution, how do we do the solution well, we need to have a strategy.
  • Through some project management project operation, we can guarantee the operation of our strategy.
  • If it’s a relatively long term project, you need to estimate what risks you might encounter in the middle.
  • After we’ve been doing this for a while, we need to go back and see if we need to do some directional fine-tuning.

So the whole process, in plain English, what problem are you going to solve, how are you going to solve it, what is your solution, what are the technologies and products involved in it? If you want to do it, what are his priorities, entry point, and grasp, what kind of people are needed in the team, who will do what at what time, what problems may be encountered in the process, and how to solve them. Finally, we went back to look at the target, to rectify the deviation, to see if there was any deviation in the middle. This is a general mode of thinking, and I will go into detail later.

3.2 Identification of phenomena and problems

First look at the phenomenon and the problem, it will determine the integrity of our planning. If I only think of this one problem at the beginning, or only think of a part of the problem, not complete, then at this time you make a plan is only around solving this part of the problem, at this time the things you do may be biased or slanting.



In this process, if we say “this” is our plan or our current position, then we will have some questions raised by ourselves. To make these questions more complete or more comprehensive, there are some common methods:

  • The first one is the question method, for example, the sky is blue, why is the sky blue? There is a lot of refraction of light in the sky. Why does it refract? So step by step to cross-examine go down, want to cross-examine at least commonly 3 layers.
  • The second is the keyword association, we usually may encounter some technical problems, even I do not know where this problem comes from. At this time, I can think of some of its keywords, take a piece of paper to write it down, and then search for its related content. As we get this information, we start to form a kind of map in our mind, which clears away the fog in our mind until we know the full picture.
  • The third is to think in different dimensions, which is to expand the thinking along this dimension from different perspectives or attributes.
  • The fourth is a principle, that is, do not repeat the problem, do not omit.

Some common analysis dimensions, such as what stage of the development of this thing, with you through some data analysis found, user value of the future forecast and so on, from these perspectives to do thinking can help you more complete thinking problems, here to throw out some for you to refer to. Here are a few common problems you may encounter with this process:

  • Typically, no problem, no problem found. Finding the problem itself is actually a kind of ability. Most of the time, we don’t find the problem, maybe we don’t ask and associate deeply, or maybe we don’t know a better solution, so we feel like there is no problem. But if that’s the case, then you’ve already finished what you started.
  • Then, a second, more common problem is to treat appearances as problems. It looks like a problem, but in fact it’s not a problem, it’s a superficial phenomenon. Most of the time, we may only think about one layer. At this time, if we want to think about the problem comprehensively, it is necessary to ask. It is necessary to dig at least three layers to go down, so that you can gradually have a sense of the problem.

About the phenomenon and the problem, I recommend you to read the book are your Lights on? In fact, this book is to help you to establish a way to identify and think about the problem of a book, I think it is good, but also quite a primer for a book.

3.3 positioning

The first part is we’re going to diverge as much as we can, from our current problem number one, to diverge a lot, until we get toThe phenomena and problems are clear and clear. Which brings us to step 2:Do positioningWe’re going to converge when we’re doing the positioning, and assuming that the four directions on the right are the directions in which we’re diverging, then we need to go from these four directions,convergenceTo a problem domainintersection.



At this point we actually form the one we’re going toAddress the scope of the problem domain, and then we’ll find our position in this range, when we need to abstract the positioning of a description of time, we still need to do some work, we need to go to the convergence problem domain from us to think about, we will go to solve the core problem is what, we want to provide solution for what type of users or scene, What is the general vision of the solution and what value it can bring to the user?

Here is a simple template to help us comb and locate. You can refer to it:

  • What scenes are we facing and around
  • And in what way
  • What solution or product does the implementation build
  • And what kind of user to help provide what kind of value?

There are some key points in this process, which is the process of finding positioning, which can be understood as the process of finding differentiated value. For example, Xiaomi does mobile power supply, Huawei also does mobile power supply, and then for example, our industry has a lot of component library solutions: ANTD, Fusion Design, ElementUI, all kinds of, at first glance look very similar, but in fact they are different, because they have to solve the core problem is different. At this time, its core difference is its positioning, otherwise it will be easily replaced by other things.

In addition, the process needs to focus on thinking, which things you must do no matter how difficult, which things you do not do no matter how simple, if you think clearly about these problems, then your positioning will be too. If you can’t ask these questions, or haven’t thought of them, then your position is very unclear.

In fact, the third question is similar to the second one. If you know your position clearly, you will have such a problem that what we do not do has a lot to do with my position. It will have some impact on my technical system or product.

There are also two recommended books, one is “Positioning” and the other is “You Need a Storyteller on your Team.” The previous is about positioning, this book is very famous, partial marketing, to help you understand the concept of positioning. The second book is how you understand what you’re going to do and its value in terms of storytelling.

In fact, we can also have some feelings from the process of business requirements or projects we usually do. For example, the product manager brings a demand. He needs to tell me what our users are like. What was he trying to solve with that thing, and how? Maybe normally he’s just telling the process, but when it comes to telling the story, he’s talking about his value, his role. At this time you may have a feeling that if I do this thing, there is indeed such a role and value. At ordinary times, if you are so to think about the problem, to comb your positioning, in fact, is very helpful.

3.4 the target

When we determine our position and what problem our solution is likely to solve, we need to define how far we want to go, or how far we want to go at what stage. This is the process of setting goals.

In this process, we usually need to disassemble goals in two ways:

  • One is a tree subtarget. It’s the one on the left, G > A > A1, A2, A3, where I have A global goal G, so let’s say my overall activity is going to increase by 20%, and if I take it out of G, product A is going to increase by 10%, product A1 is going to increase by 5%, product A2 is going to increase by 5%, so it’s A tree, and all the goals add up to the overall goal.
  • Another type of goal is the milestone goal. For example, I think my business has reached this point, which is a very critical event. Once I reach this point, I will form a process from quantitative change to qualitative change, or at this point, our business will enter another stage.

Good goals are simple. It’s that as soon as I see this thing, I know what you’re going to do, and it’s very focused. Sometimes our goals are hard to set. If you think this is not good, then it is not, or set 30 set high, set 50 set low. Sometimes we need to shoot a rough one, because when it comes to setting goals, we first need something to focus on, so that we can go toward the goal together, and then how far we can go.

3.5 Technical Architecture/Technical product architecture

The third part is about an idea when I do technical architecture and technical product architecture.

First of all, if you are going to draw an architecture diagram, you need to know what your architectural goals are. This architecture goal is to follow up on what was defined by the previous positioning and goal.

Architecture diagram because there are so many kinds of different types of architecture drawing method is different also, from a simple abstract figure to explain here I understand, I understand the architecture design of the objective is to clarify relationships, for every point to reasonable placed in a system, make the system as a whole can be efficient and stable operation, and the relationship will be varied, Our design patterns are all about describing the relationship between A and B, or multiple roles, and how to refactor those relationships to solve the problem.

The first step is to come up with solutions to the problems you’ve identified, and list the solutions in different dimensions.

Maybe you start out with something like the bottom left corner, where ABCDEF you throw around, you throw around, you throw around a bunch of various solutions, or features, or technical capabilities, like a tag cloud, and then you start thinking about the relationship between them in different dimensions. There may be many different kinds of relationships, but you only need to define the relationships that need to be explained around your architectural goals. The sorting out of these relationships may lead to the dismantling or merging of certain solutions or capabilities. Of course, if there are some design patterns or architectural models out there that fit your situation, just go for it.

As long as your logic is consistent and the relationship between content and characters is clear, it’s fine. Does not mean that seems like a lot of people to draw all kinds of architecture diagram, see you feel very reasonable, but you may be in another way, or from another Angle, you draw is reasonable, also can speak clear, in fact is the same, that’s all right, no one of the so-called standard answers what must be said. For example, an MVC, if you draw M on the left and C on the right or if you draw it the other way around, the other way around, it’s an MVC, as long as each module of your MVC is clearly defined, and the relationship between them is clear.

Then, for the fourth, which is really critical, design solutions to the core problems in the relationship. If you’re an architecture, then you don’t just say you have a solution for ABC, you have to think, why did YOU put ABDE together? Putting them together, what kind of solution do I offer to support their combined relationship? Is it a container? Then what protocol did the module of ABDE and the module of GH connect with each other? For another example, CFI is placed at the bottom, does it support the relationship with the top? And how does he support the upper floors? Process? Interface? Service?

Finally, step 5 is when you put in an actual case or problem. This case and problem is still from the front of your planning, is your phenomenon, problem, positioning, goals, set out.

What happened to the story? You tell a story that asks the question, “What’s step 1? What’s step 2?” and see if your architecture works. Do you think there’s a hitch? If they all work, the preliminary test is passed and you can move down. Again, do architecture design often encountered in the problem.



  • The first possible problem is copying. I probably started out looking at all the structures that the big guys drew, so I’m going to draw them that way. But in fact, if you think from the previous problem to the positioning to the process, then you are not likely to copy a thing over, generally you have a complete own thinking first.
  • And then the second one is logical self-consistency. This is what I just said, the relationships in the architecture are logically self-consistent, and if you put them together, the results are not clear, or they are mutually exclusive, and you put them together, this is problematic.
  • The third is lack of clarity. For example, it is found that the relationship with your previous problem, or your positioning target is weak, or the relationship is biased, this time will also appear problems, because your architecture is not to solve the problem in front of you, that architecture must be a problem.
  • The fourth is ** only frame without structure. ** The logic is ok, but when you fall into the relationship between the key modules, there is no effective solution to support it, or the architecture looks logical, but does not effectively solve the problem you have before. This is a very difficult structure to build.

These four are very common problems when I do architecture design.

Then there is the technical product architecture. In fact, the technical product architecture is the product architecture, and the core of the product architecture is product Sense. If you start from the solution, when you think about a thing, think about its value first, you will gradually build your own product Sense.

Technical product architecture is more oriented to the functional architecture based on the domain model. It is derived from the abstract clustering of business requirements, problems and user processes. What are abstract services, what are concrete functions, and what is the relationship between functions? For example, to do domain abstraction with the user as the entity, or to do business abstraction with the commodity as the entity, and then look at the product function relationship between the user and the commodity, we find that it is not just a simple user browse the commodity, so we need a product list interface. If you can tell what your product positioning is from the product architecture, it’s basically a product architecture.

It is clear that different users and roles need different layers of service functions and different ways to undertake them in architecture. Generally, C is the pyramid and funnel, and B is the decision, process and task, such as: facing the customers in the browsing stage and the customers in the transformation stage; Facing decision-makers and task-makers.

3.6 Playing methods and strategies

Then talk about the playing method and strategy, to this stage, we may have a relatively complete positioning and scheme.



When we do technology, we often think it is easy for me to design and develop something, but it is difficult for me to push it to the ground in the company or in the team. Always feel I do do, as if there is something delayed today, and then I do a long time, feel his value can not come, the boss does not agree, I can not do it again.

This time is actually need to pay attention toPlay style and strategyOf, how do you make this thing better to complete and push the landing.

First, for example, if I want to build a monitoring system, shall I first build the COLLECTION SDK or the visualization service?

I can first put up the service, pull some pseudo data, and then the boss see the demo is very clear, seems to be what we want, ok, you start to work!

I can also do the collection SDK first, save the data first, if there is no data, what do I analyze? Isn’t it? That’s probably neither of them. It may be to design the field model according to the business requirements first. What should I analyze? Shall I analyze performance or user behavior data or business transformation data? Based on what I’m trying to analyze, I look at what my model looks like, what the fields look like, what the Schema looks like, define the Schema, and then if I want to add or subtract fields, I can easily expand.

Secondly, for example, do you plan to complete all these functions and spread them out in all business lines after the documents have been perfected? Or do I plan to make a prototype and go directly to a business line, then go to the human flesh to do analysis and solve his problems first? Are you going to try landing on a low traffic page first, or are you going to try landing on a very low performance page with a lot of traffic?

This time is also more exquisite, if you do this thing all done, done very perfect, then go to the landing. And the good thing about this is, your users, they’re going to say, oh, this thing works so well, grab it and use it. If you start out half-baked, he’ll think you’re a bad thing here and a bad thing there.

But on the other hand, if you start with a half-finished product and try it out. Pilot after you found before I found my original idea is to have a problem, I’ll verify and is similar to the steps run ah, fast iterative way, I go to verify it, what’s the problem I went to repair it immediately after repair let user to use again, so quick to verify, can avoid I had a lot of effort to do a finished product, It’s not uncommon for the product to turn out to be something you didn’t want, or something you didn’t need, and a lot of resources were wasted.

Then do you want to try it on a page with low traffic, or do you want to try it on a page with high traffic but poor performance? If you land on a high-traffic, low-performance page, you may need to validate your solution for a short period of time, and then you need to add value to the business as soon as possible. At this time you can try this way, but if you are unsure at the beginning, you think you may have a lot of problems with this scheme, you first in a small amount of pages, first to try not to affect the business, so that you landing pressure will be a lot less.

Third, are you going to write the documentation while you’re developing, or do you want to complete the documentation later?

It’s probably a problem for a lot of people. Because in the process of writing, you may often change later. At this time, you need to change the document after you have written it, you will waste a lot of time, you can choose according to the situation, I think my design before is very complete, so I write first to save the later forget. But most of the time it’s probably just that AFTER I’m done with development, I’m filling in the documentation, and when the product is more stable, I’ll fill in the documentation. In fact, all of them are about how to better bring your solution, or this thing can be pushed forward. Or in order for you to achieve your goals more smoothly and effectively. What form are you going to take? What people? What do they do first?

3.7 Project Plan

The last part is about the project plan. After we have the previous strategy, we can vaguely know what our general rhythm is.

If you take Honor of Kings as an example, it’s who you’re going to catch at what time and who you’re going to catch with, after deciding whether you’re going to catch people first or develop them first. This is what project planning is for: ensuring that the process is completed on time and with quality.

A brief introduction to the project plan, you may also know that there are two mainstream models, one is Waterfall Flow, on the left, and the other is Scrum, Agile Iteration. These two models have their own advantages and disadvantages.


Now a lot of people are talking about how Internet companies are talking about Scrum agile iterations, biweekly sprints or four-week sprints, and then going out and getting an MVP that they want to release, and then going out and giving it to users, and then I’m going to update the iteration.

Waterfall actually means the traditional idea of large-scale software development, where I would deliver a very complete product, and at that point I would take all the modules out, all the plans out, and then work on it step by step until the end of the launch.

No matter which form you use, you don’t have to think about it so much at the beginning, just go to the tool, use which one you think is good, and then refine the project management process if necessary. Like WBS, Omniplan, Teambition, Redmine, all are very useful tools, slowly you know, this need not deliberately to learn, what certificate is not necessary.

4

4.1 Business challenges to experience technical demands

Finally is on my side, for example, this is my a business challenges from our company, and then disassemble challenge to the corresponding products, to experience the technical challenges, to experience, technical skills may need such a apart, this is a very broad, and docking of a dismantling business strategy level.



Let’s say the first oneLow tool value, many competitorsThis may be a very big feature of the B-side industry.

I’m going to talk about one of them here, instead of talking about each one, because that would take a long time. Low tool value, more competitors, you do this function I also do this function. At this time, we will put forward requirements for our product experience, experience is my core competitiveness, we are all the same, but I experience better.

The reason we now say that experience is the last category of SARS, and that it is becoming more and more important, is that it is gradually generating its commercial value.

In our current development stage, the core problem of product experience is consistency, efficiency and stability. At this point, in terms of experience, in terms of experience technology, that involves our experience system, performance, monitoring, stability. Then there’s the experience data, then there’s the experience analysis, then there’s the consistency of the brand and so on.

Then, the tag cloud of experience technology capability is deduced based on such experience technology challenges. At the same time also need to have a complete organizational ability, to ensure, to do this thing to go on.

4.2 Experience technical ability to architecture design

The next step 2 is how to disassemble or structure the appeal tag cloud of experience technology capabilities into an experience technology architecture.



In fact, isIdentify capabilities first, and then organize them through connections.

And then there isTell a story and get in there. For example, my performance problem can be solved from multiple perspectives including problem discovery, problem solving, problem monitoring, research and development stage and online stage.

Engineering system is a research and development ability of the underlying here, for example, the perfect degree of the engineering system itself to determine whether the research and development ability can run up, research and development ability of the container, the component material is the core of fu can raise efficiency, to the upper visual construction ability, homogeneous/SEO skills, experience and provide material support, through business architecture governance after assigned to specific lines of business, Lines of business then build specific solutions based on their business characteristics.

QA&Contact

Time is limited, so that’s all for today. Welcome to follow up with us.