Process and specification are just a guarantee tool, not a methodology.

Start with a purpose and clarify the meaning

There are no roads in the world, but when more people walk on it, it becomes a road.

The text written by Mr. Lu Xun is actually very meaningful regarding the so-called operating norms and operating procedures.

I saw a post on WeChat Moments a few days ago that made me laugh to death.

Your company has only 6 people, and Zhang Xiaolong's article "Beware of KPIs and Processes" is circulating wildly. You should study and reflect on it seriously. So, your first priority is to increase the number of people to more than 1,000?

I clicked the thumbs up happily.

Why?

First, many things may sound stupid when said by others, but become truth when said by Zhang Xiaolong.

Second, once some words become truth, believers will accept them without any discrimination.

For example, if one day I become half as awesome as Zhang Xiaolong, I guess many people will cite my article when arguing with others:

Look! The great god said so too!

But it is very likely that the conclusions of this article have been overturned by myself or even by others - it is also possible that you just don't know it.

To talk about the operation process and specifications, we must first clarify:

There is no absolute truth on this topic; processes and standards are born out of necessity, but they are not required at all times; there would be no standards if there had never been a pitfall; there would be no processes if there had never been a problem.

Then, you need to think about:

Are processes and regulations necessary for operations? What exactly should the process of establishing processes and standards look like? How can we make processes and regulations become enablers rather than constraints?

Next, I started talking nonsense.

No pitfalls, no regulations, no responsibility, no process

Standards are meant to prevent non-standardization; processes are meant to prevent unclear responsibilities.

If these two premises are not understood, then all discussions are meaningless.

Let’s use the specifications of an event planning proposal as an example.

If you’ve read Starting an Operation from Scratch, you’ll remember that I provided a standard structure for event planning proposals:

Event theme: A part of the event copy that allows users to understand the theme of your event and whether it is attractive to them. Target audience of the activity: Make it clear which group your activity is targeting, so that users can understand it, you can grasp it, and leaders can recognize it. Activity time: the start time and end time of the activity, the time when the reward is issued and the time when it is received. Event description: A part of the event copy that allows users to understand and decide whether to participate and how to participate. Rule details: Part of the activity copy is understandable to users and developers, part of the content is displayed on the front end, and the other part lets developers know how to implement the activity. Distribution channels: To make it clear to the market or to yourself, there must be a distribution time, selection of distribution channels, and budget. Risk control: Let developers understand what your risk links are and whether there are corresponding measures to solve them. Monitoring indicators: Cover most relevant indicators, including monitoring of delivery channels, monitoring of user participation, monitoring of reward distribution, etc. It can help you find problem points when viewing the data and inspire you to solve these problems. Cost estimate: How much does an activity cost and how much does it cost per person. It doesn't have to be very accurate, but you must be aware that there are activities that don't cost money, but if you do, you need to understand the capacity of an activity, how it will help the indicators, and how much money you need the company to support you in order to gain these benefits. Effect evaluation: Where there is cost, there is benefit. The purpose of your activity is helpful to the indicators of the website/product. You need to consider how to reflect it and get the approval of your leaders. FAQ: You can prepare a separate document and provide it to customer service or relevant personnel to help resolve any confusion users may have when participating in the event. FAQs should be detailed and standard. If the event is large-scale and FAQ alone is not enough, you need to prepare customer service training documents in advance and actively communicate.

In fact, this structure itself is the result of various pitfalls.

Activity theme, activity target, activity time, activity description, activity rules (actually there are also prize settings, but they are included in the cost for examination in the planning proposal). These contents are mainly for users, and some are for developers. If there are omissions or incompleteness in these parts, either the developer or the user will not understand it, and problems will definitely occur.

Distribution channels require operations staff to fully consider the event targets and related budgets when planning events and make corresponding distribution. If there are omissions or incompleteness, either you are a large platform with your own resources, or the promotion will most likely go wrong.

Risk control and monitoring indicators are for developers and operation and maintenance personnel to see. At the same time, you should know the reasons behind the abnormalities in certain monitoring indicators. Because once these two items are set, there will be an alarm mechanism in a relatively complete process. When an alarm occurs, you always need to know where the problem may be and who to find to deal with it.

Cost estimation and effect expectation are for the leaders to see. Your leader is not Zhang Xiaolong, so the money will not be wasted. If you cannot reach the mentality and level of Zhang Xiaolong or Ma Huateng, it is inevitable for the leader to pursue ROI, and you must pursue ROI. If you have no awareness of cost control, you will be confused about cost estimation, and if you are confused here, it is estimated that in nine out of ten cases, you don’t know where the risks will appear, so you will not be able to design monitoring indicators, or you will design them randomly.

FAQ is for operation and maintenance, customer service, yourself, or colleagues who are working overtime. When someone encounters a problem or comes to you for advice, you always have to have an answer, right? If a person does not do FAQ operations, he is definitely not a senior operator, because he does not understand the relationship between activities and customer service. Therefore, he must not have been in this line of work long enough, otherwise the customer service would have beaten him to death.

You will find that the establishment of norms is often accompanied by errors, accidents and negative impacts.

If there are no such problems, then there is no need to establish the specifications. After all, Zhang Xiaolong said that a small team of 10 people is efficient. It takes less than 24 hours for a bug to be raised, modified, tested and released online.

Yes, that was because the product did not have the care of the top management at the time, so the small team was allowed to do so. Otherwise, if a release accident really occurred, who would be responsible?

Oh, sorry, I talked about process.

Let’s talk about the process.

The core of the process lies in "traceability" and "accountability".

You said, can't the developers package and update to the server after they have completed the development?

Yes, but who will do the testing? What should we do if something goes wrong because the common exception process is not covered? Who will be responsible for operation and maintenance? There are 100 servers in total. Should we develop and upload to each server ourselves? What should I do if I transfer the wrong version package?

Therefore, if professionals do professional things, at least when something goes wrong, the blame will be placed on the relevant nodes rather than on everyone.

For example, a scene like this:

A wanted to change the price of a product, but he missed a zero. The system did not have a function to automatically detect price anomalies, so it required approval from A's leader M.

M felt that A was always reliable. He was in a hurry to attend a meeting, and A urged him to put the product on the shelves. M thought it was okay as it had been approved.

As a result, the inventory of goods was sold out.

If the boss pursues the matter, A is doomed and M can't escape either.

Because M approved the process.

But if there is no process, it’s over, there will be no evidence.

Therefore, the process is to clarify who has the responsibility.

Efficiency and fairness

Norms and processes are often established based on situations where problems or impacts have already occurred.

Therefore, standards and processes are created to avoid the recurrence of similar problems, with the aim of ensuring efficiency and fairness as much as possible.

But in fact, the regulations and processes designed based on risk control will inevitably have an impact on efficiency, and no matter how powerful a company is, the result will inevitably be reduced efficiency.

This is normal.

Zhang Xiaolong also knows how to complain. If a team of 10 people encounters a problem, they can just walk a few steps to pull up the responsible person, draw some on the whiteboard, have a chat, and start working together. But a team of 100 people starts to need to make appointments for meetings to solve problems. Of course, this efficiency is not as good as that of a small team.

Not to mention anything else, in a team, there is one product, one operation, one development, and one design. At least everyone knows who to talk to if any problem arises.

Why don’t you try to become 4 products, 4 operations, 4 development, and 4 design? You might not even have the chance to see 16 people sitting at the same seat throughout the day.

But is there no solution?

Actually, yes.

The method is also very simple:

Treat standards and processes only as a tool for protection, and do not turn them into methodologies to operate.

To be frank, does the event plan I wrote above have to have this structure?

Not necessarily. As long as you can cover the possible pitfalls I mentioned, you can write it however you want.

If you are bound by rules, you are really stupid.

To put it bluntly, do we have to wait until the process is passed before doing anything?

Not necessarily. For some processes, you should treat them as a post-event record.

For example, you are an operator in charge of the SMS channel, and you receive other people's release requests all day long. According to standard procedures, you can only do anything after receiving the demand form.

But who stipulates that the demander cannot communicate the text with you clearly in advance, and then go through the process with the leader to sign and confirm?

Oh, of course, if you are already a large company with more than several thousand people, you can certainly do this, because the cost of initial communication is too high.

However, everything can actually be considered more efficient and simpler.

This is my opinion.

Mobile application product promotion service: APP promotion service Qinggua Media advertising

The author of this article @张亮 is compiled and published by (APP Top Promotion). Please indicate the author information and source when reprinting!