If you carefully observe the daily work of Song Xiaocai technical students, you will find that they like to talk about a word, that is “ability”. Whether in system architecture planning, technical solution design, development problem discussion or even PRD review, the word “capability” is constantly on their lips. What is it about this word that makes it appear so frequently in conversations with developers?

I. What is “Ability”

Before I go into the details of what “ability” is, I want to keep you in suspense, but I want to introduce you to another word — the Age of VUCA.

VUCA is a new word with the first letter of four words — volatility, uncertainty, complexity and ambiguity. VUCA first appeared in military language, but now it appears more and more frequently in our daily life, because people find that these four words are very suitable for our society and times. Our life, our work, our society, and this age of rapid development are full of changeability, uncertainty, complexity and ambiguity.

When we go back to the daily work of technical students, we will be surprised to find that the requirements, product solutions, visual drafts, operation plans and even the framework technologies we are used to, the services we rely on and the middleware tools we use are also full of VUCA characteristics. So here I really want to and technical students (especially in the start-up company, business is in the rapid development of the company) say, do not indulge in the “kill not to change the PRD” or “change to kill a designer to worship the heaven version of the UI” war or quarrel. Because when you review it, you’ll find that the conclusion of all the Shouting and bickering must be “should change or should change”. The reason is simple. VUCA is a characteristic of our time. If we don’t adapt to him, but try to resist him in every way, it’s not worth it, and often your efforts will become futile.

With all this thinking about VUCA, it’s time to introduce the word “capability.” Because what we’ve found is that no matter how fast a company’s direction changes, or how many businesses die, or how many innovative projects are born, there is something that remains relatively constant and that we can precipitate: capabilities. This may seem abstract, but I’ll give you two examples that might give you a sense of what’s going on:

1. With the development of business, the company has more and more systems or applications, and each system always needs to have a login process. At the beginning, the login processes may all be independent. System A has one login process (using email and password), system B has one login process (using dynamic SMS), and system C has one login process (using login name, password and verification code). This is where we find the “capability”, the login process, that we need to precipitate the “capability”. Because the login process can be enumerated, and once a certain login mode is solidified, it can be quickly output to other systems for use (highly reusable), as shown in the figure below:

2. Businesses are always diverse and complex. In business X, there is a scenario that requires email notification to the supervisor for approval; in business Y, there is a scenario that requires SMS notification to the sales that a customer has placed an order; and in business Z, there is a scenario that requires pushing coupons to the customer to expire soon. At this time we found the “ability”, the message notification center, is the “ability” we need to precipitate. Think of it the same way as the first example, because the notification approach is solidified, and once a notification approach is precipitated, it can be quickly exported to other business scenarios (highly reusable), and then these notification capabilities can be combined, as shown in the figure below:

After seeing the introduction of the above two examples, many technical students will feel that these are not very normal, in our company is not designed in this way. These two examples are not intended to give you an advanced technical solution, but to illustrate the word "capability." Because the design of capability is more like a model of thinking, that is, "abstraction and stability sink, variable and uncertainty float up." This thinking model, whether in interface writing, architecture thinking, technical solution design or even in daily life and work, will play a great help, and is also a beneficial skill to adapt to the ERA of VUCA.Copy the code

Key points of designing “capabilities”

2.1 Distinguish between “business” and “capability”

Many students just graduated or work experience is still shallow development students, when receiving a demand or task, often make a common mistake, what is it? You just can't distinguish between "business" and "capability." They tend to be "business programming only". Note that the word "business programming only" is used here. Many developers listened to the product manager describe requirements and features while their brains were racing. By the end of the requirements review, your mind is so full of table structure design and field meaning that you think you are in development if you haven't decided on a development branch yet. There is no problem that can't be solved by adding an interface or a table. If there is, add two. "Talking about this, will it cause a lot of development students smile, this stage is estimated that all programmers have experienced. Why do I summarize this problem as a failure to distinguish between "business" and "capability"? As I mentioned earlier, the key is that there is no mental model that "sinks abstractions and stabilises, and floats variable and uncertain". The most common label a business has is fluid, vague, and uncertain, which is the nature of the business. Most of the time, operation students are also exploring while running, and revising the strategy and tactics of operation. This situation is more obvious in start-up companies. At this time, if the technical students do not think in the development process, the development of the function of the soldiers will block the water, keep adding tables and interfaces, it can be imagined that if this goes on for a long time, the results will be terrible. This is song xiaocai business rapid development for three years, we have made mistakes, but also brought us considerable thinking. Here's an example of a similar mistake we made: As the business grew rapidly, more and more roles were incorporated into our business links, such as "trading customer", "supplier", "driver", "stockholder", and so on. Because different project teams undertook corresponding requirements development, so the design results can be imagined, can only be described as "very close to our business". What are the problems? For example, as the business changes, the identities of users can be diversified, for example, some users may be both "supplier" and "driver", some users may be both "supplier" and "hoarder", etc. The question then arises, "How do I know who he really is?" ", "Some identities need to be able to log in to system A, some identities need to log in to system B and C, and some identities do not need to log in to our system.Copy the code

In fact, after the emergence of two or three identities in our system, according to the way of thinking introduced just now, we should sound the alarm in our hearts. It is time to distinguish between “business” and “capability”, so that “capability sinks and business rises”. According to the business abstraction, we precipitate the user-centered “capability”, including account system, user system and identity system, and output in the relatively abstract “attribute” and “label” expansion capability to support high-speed business change.

2.2 Don’t Start talking about “competence”

When the development students gradually understand the role and value of "ability", it often brings a new problem, that is, to talk about "ability" in the beginning. "Ability" is not a fantasy, it must be through some business form of observation and abstraction, can be precipitated. For example, at the very beginning, we talked about "let's build an inventory center first, since we are an e-commerce model, we will certainly use it", "at this time, we need a commodity center, because XX company said they have, our business has many similarities, there will be no mistake to have a commodity center" and so on. Core "capabilities" such as commodity centers and inventory centers certainly do not appear in this way. Remember, "power" is not meditated out of thin air, nor is it designed by experience. Must be consistent with the specific business scenario, continuous thinking and abstraction, in the appropriate practical precipitation down. It is time to tell the painful lesson of Song Xiaocai: Song Xiaocai's business in the first two years, logistics business has been in inter-city distribution, such as from a place in Hangzhou city, distribution to the target site in Hangzhou city. At this time, we made a unified scheduling and logistics platform, hoping to export it as a "capability" to all logistics scheduling businesses of Song Xiaocai. Looking back now, I can only blame that I was too young and saw too little business. After that, the complexity of our logistics was far beyond our imagination at that time. For example, we connected with backbone logistics and began to deliver goods from the upstream base. For example, the big carts in the city cannot pass, so they must be backed up by the big carts to several small cars. For example, a semi-trailer will first send to Hangzhou, then to Jiaxing and finally to Shanghai for cross-city business. The logistics scheduling center designed at the beginning could not undertake such a changeable and complex business scene, and now, the data model abstraction at that time is problematic. Therefore, if you can realize the design idea of "sinking ability, rising business", and understand its value and power, it is only the first step, do not fall into the pit of meditation "ability", so designed "ability", often only in the fog, just a good vision.Copy the code

Iii. How to Build “Capacity”

3.1 Precipitation of “capacity” in the project Process

If you decide that a particular ability is particularly important and you want to settle it, what do you do next? Set up a dedicated development team to work hard and produce fast? That’s fine, but startups often don’t. We prefer to see a project form like this: the birth of “capability” from 0 to 1 must be closely attached to a specific business J, and output the highest priority function requirements to the business J. When other businesses Q and K know that we are starting to produce capabilities from 0 to 1, they will make a wide variety of demands on the capabilities producers. At this point, the “capability” producer needs to have a point in his mind, because now the “capability” is born from zero to one, you can’t satisfy all the features, you can’t even judge whether those requirements are reasonable or not. So we have a principle: “ability” from 0 to 1, only one business service. What are the advantages of this: 1. The “ability” must be closely related to a certain business, so that the “ability” designer is not confused, in case the final “ability” can not serve a scene; 2. 2. To serve only one business scenario, it also prevents the “ability” designer from having too strong appetite, thinking that all needs are reasonable and all needs should be satisfied, and finally becoming a bottleneck; 3. Give the “ability” designer enough time to think. Because successful service to the first business, will be more effective to help “capability” designers to abstract and think “capability”;

3.2 Optimizing “capacity” in infrastructure Reconstruction

The ability to go from zero to one must be the hardest, and you may have to block out some business requirement development tasks or talk to others about the benefits of the ability until they agree with you. However, the birth of “capability” is often just the beginning of the Long march of the Red Army, and “capability” needs to keep iterating and building. Where do these points of iteration, or points of construction, come from? Access from an endless stream of application scenarios. It’s time to introduce our second principle: a truly recognized “capability” is one that serves more than three business scenarios. This principle forces capability designers to constantly think about the nature of the business and abstract the true value of capability. Such iterations are often arranged in some infrastructure projects, so that the designers of “capabilities” have clear goals and missions to optimize their “capabilities”.

Fourth, concluding remarks

When I communicate with friends in the industry or students who come for interviews, I often talk about “You are in charge of a XX center. Do you know why you need a XX center?” “The answer is often” The architect feels the need “or” Isn’t that normal? Other companies have it too “. If you ask me that question, this article is my answer.

About how to set up efficient raw B2B platform, because of the large contents, also is very complex, unable to give you an article, this article is just beginning, the following will be divided into several articles from industry present situation, the situation of business and product overview, technical team building, the server-side technology platform, the front-end development, such as multiple dimensions to tell, We will be more than three years in the B2B field of the precipitation of core products and technology platform to open, hope that more people in the industry can have a deeper understanding, less detdetments, hope to help you, the distribution of this series of articles is as follows (will continue to update) :

1, “How to build an efficient FRESH B2B platform (B2B technology sharing the first article)”

2, “Song Xiaocai how to enter the fresh B2B market (B2B Technology sharing second)”

3, “fresh B2B platform product system iteration (B2B technology sharing third chapter)”

4, “fresh B2B how to build an efficient technical team (B2B technology sharing fourth chapter)”

5, “how to build fresh B2B technology system from 0 to 1 (B2B technology sharing fifth chapter)”

6, song Xiaocai technology how to deal with the rapid change of fresh B2B business (B2B technology sharing sixth chapter)

7, “fresh B2B technology platform front-end team how to build (B2B technology sharing seventh)”

8, Song Xiaocai about “Ability” design and Thinking (B2B Technology Sharing chapter 8)

9. Design and Thinking of Service Separation (B2B Technology Sharing chapter 9)