WeChat Spring Festival Gala Shake Project Experience Learning - R&D Process

[[128547]]

A good product must have very capable engineers to help plan the product, and also very capable products that respect, understand, and cooperate with technology. This is an important revelation to me from this project. As a product manager without a technical background, I am ashamed that I only have a superficial understanding of the deep-level architecture and technology of R&D. This article is about some of my feelings about the project R&D process. I will just learn from it.

[Keyword 1: Continuous practice and optimization, weakening the concept of demand change]

From mid-January, when most of the Spring Festival Gala Shake features were initially developed, the development side launched an exercise. Every Thursday from 8 pm to 12:30 am, the actual situation of the Spring Festival Gala was simulated for internal experience and testing. The scope of the exercise was initially dozens of members related to the project, and later gradually expanded to hundreds of members within WeChat. Each exercise can collect a lot of feedback, and the product and development will follow up and modify it after the exercise. It is worth mentioning that during the exercise, not only bugs were raised, but also experience problems that were not discovered during the product design phase. Faced with these experience problems, the developers did not think that they were changes in requirements and were unwilling to modify them. On the contrary, the developers embraced these experience optimizations with a very open and willing attitude.

Of course, before the development is implemented, the product is also carefully considered to avoid major product changes as much as possible. WeChat pays great attention to the logical thinking ability of each product manager. Product managers pay attention to the things they make to make themselves happy, and they must be able to clearly explain what makes them happy, so that they can convince the design and development, and also explain to the boss. For the entire Spring Festival Gala Shake project, basically the visual drafts or interactive drafts given to the boss can be approved in general. Therefore, when the Spring Festival Gala project is tense in the later stage, some not very big plans are developed first and then reported to the boss at the same time, because the boss’s time is difficult to arrange after all. In this case, the product first explains the situation to the developer, and the developer can understand it very well. Moreover, when the plan does not need to be changed after reporting to the boss, then the developer’s trust in the product is further increased.

There is another small detail that reflects the agility of the project. When giving requirements to the testers, the testers are most concerned about the interaction logic and development implementation methods, but not the wording. One tester said: "Don't pay attention to the wording for now. Who knows if your product will change the wording later? The product will check the wording experience." This is also a side reflection of the tolerance of demand changes. But the testers are not really unconcerned about the wording. When they see wording, typos, or even wrong symbols that affect the experience during the test, the testers will point them out. They are really reliable.

One week before the Spring Festival Gala project, we had one or two meetings every afternoon to discuss details. Each discussion would bring up new issues and lead to some minor changes to the plan. The next day was New Year's Eve, and we were still revising the requirements the night before. We worked all night, and the requirements went through funny name changes such as "Final Version", "Final Version V2", and "Never Change Version". But the developers survived. As long as the changes were not stupid and there were enough reasons, everyone was very cooperative. There is a tradition within the company that WeChat was still being revised until the last minute of the launch, and it is true.

[Keyword 2: No fixed project manager]

The project manager plays a very important role in software engineering management. In many teams, the role of the project manager is very important because it controls development and design resources, arranges the version rhythm, and coordinates manpower. The advantage of having this role is that when multiple projects compete for resources, someone will coordinate; when it comes to project progress, someone will control it to prevent the progress from falling behind. However, this will also lead to a problem. Each link is clearly defined, so people in each link are very sensitive and resistant to changes, which in turn leads to longer decision-making time for each link. Work will start only after it is raised to the boss, and work will start only after resources are allocated. In this way, the process becomes heavier. What we want to do is a good product, not a good process. The process serves the product.

In the Spring Festival Gala Shake project, there is no dedicated project manager role. Project managers are assumed by product managers or developers when necessary. At the beginning, the project manager is the product manager, who organizes the relevant departments to involve and develop the corresponding products. In the later stage, when entering the development stage, a developer is responsible for grasping the overall development progress. At the most critical moment, a developer who also serves as the project manager is responsible for synchronizing demand changes. In a project involving so many teams, there can be no project manager involved, provided that everyone in WeChat has a very protagonist spirit, everyone guarantees to do their own thing, keep up with the overall progress, integrate other resources, and inform others of their own resources. Therefore, throughout the process, the most important task of the project manager is not to follow up on the progress and allocate resources, but to synchronize information and keep everyone's information unified in order to make important decisions.

[Keyword 3: Not only developing complementary products, but also vice versa]

Before the Spring Festival Gala, on February 12, WeChat held a warm-up event for grabbing red envelopes. At that time, the red envelope war was just beginning to rise, and Alipay had started the red envelope event a day or two before. After WeChat held the red envelope event on February 12, public opinion tended to favor WeChat. It was said that WeChat was the winner of this red envelope war. At that time, many people did not know that WeChat's red envelope event was just a small test before the Spring Festival Gala. For internal staff, the first purpose was to warm up, and another meaning was to do a larger-scale real drill for the Spring Festival Gala in advance. When someone first proposed the idea of ​​a larger-scale drill, some people inside actually had concerns. But the boss who understood development better decided to do this real drill. If done well, the drill would also be a warm-up and a good product trial. Later, it was proved that his decision was correct.

After reaching the goal of doing a warm-up exercise, the product carefully thought of many solutions around the exercise, which should be able to verify the business logic and achieve the purpose of warm-up to make the user experience enjoyable. These two purposes are obviously a bit too much and interfere with each other. Later, we decided to use WeChat's usual thinking, starting from the user, and how to make the product the most enjoyable, regardless of whether it is for the purpose of research and development. After several versions of the plan, we finally chose the simplest product plan, which only does red envelope warm-up, does not do other interactive methods of warm-up, and does not do more interactive methods for this warm-up activity. Just grab the red envelopes and grab for a few minutes. Stimulate the user's most enjoyable point, and the gameplay is simple.

Finally, the red envelope grabbing activity on February 12th was successfully completed. From this example, we can see that the needs based on R&D purposes can also be made into good user needs.

What we learn from the R&D process line is ultimately about "people". Many theories of "demand changes" and "project management" in books have been proven to be wrong or unnecessary in actual operations, so the keywords I summarized above will also become wrong in some cases. Only a team composed of like-minded people can constantly create surprises through trial and error.