-
The review system is an important means of Internet product management. The review system runs through all aspects of product management such as strategic planning, product design, technology implementation, product operation, and product marketing. It can be said that an efficient review system is an important measure of a company's product management capabilities. Let’s briefly list some of the values of the review system:
The review system can help stakeholders reach a consistent understanding of product construction goals;
Through the review system, the quality of product planning plans, product demand plans, technical plans, operation plans, marketing plans, etc. can be checked to improve product quality;
Through the review system, key points and risk points in the product planning and construction process can be checked to reduce the risks of project implementation.
The evaluation system can effectively improve the capabilities of the participants;
Check the plan through the review system to ensure that the spirit of system product architecture and architecture design is consistently implemented
Although product review is so important, it seems that no company's review system is efficient. Everyone is complaining about the numerous evils of the review system. The review meeting has either evolved into a formality or evolved into a PK between major camps. General Assembly. Regarding the review system, it is covered in various software engineering books and methodologies. The focus here is not to discuss the general principles of the review system (such as product review). The main point here is to discuss the operation process of a platform-based product. How to check through the review system.
1. Construction phase projects VS. Operation phase projects
For Internet products (product platforms) that adopt the product platform concept, such as payment platforms and open platforms, the project management of products in the construction period faces different challenges than the project management of products in the operation period.
The reason for emphasizing these product platforms is that for many Internet products, the main logic is the front end of the website, so the review of these websites is relatively easy and only requires a prototype-driven approach. But for these platform products, it is not just a simple website page development work. The most complex logic of these systems generally lies in the back-end business rules and business logic, and these cannot be explained clearly by a prototype.
1). Project characteristics during construction period
The project cycle is relatively long, such as more than 1 month
Project resources are relatively abundant and can be operated as a separate project team
Project management can use traditional project management methods or agile project management methods
Pre-project preparation work is relatively sufficient, such as relatively complete product documents, complete prototypes, complete project plans, project establishment seminars/demand seminars, etc., market research/competitor product analysis, etc.
The project is relatively independent and less constrained by other projects
2) Project characteristics during operation period
The cycle is short, most of which are less than 2 weeks
Resources are limited, and project team members may have to maintain other products concurrently.
As the company's business expands, people who are familiar with products and technical architecture are always scarce. These people are generally responsible for some key new projects and must help newcomers familiarize themselves with the system at work.
Project management generally adopts agile project management methods such as Scrum and XP, or even reduced agile development.
The preparation for the project is not very sufficient, and it is impossible to do it after sufficient preparation.
The project needs to be optimized and reconstructed based on existing products and cannot affect the existing system. For operational products, product architecture and system architecture lose control and deform during bit by bit modifications. There must be a mechanism to control these factors.
Here we focus on the methods of product review and technical review during the operation period.
2. Principles of product review during operation period
No matter how urgent the project is, product review and technical review must be conducted
Reviews must be agile
The format of the review doesn’t matter, review! =Meeting, the form of review can be formal review or informal review. The core of the review is that there needs to be people who are familiar with the system and capable to check the plan.
The purpose of the review is not to find the optimal solution, but the most reasonable solution within the constraints of existing resources.
There is no perfect review system. The key is to continuously optimize the review system in practice and establish a review system and follow-up measures that suit your company's situation.
3. Methods of product review during the operation period
For product review during the operation period, there is no best practice plan for reference. Each company has its own realistic business conditions, and different business models have different review methods. It can be said that efficient review of products during the operation period is an art of balance, which must balance the requirements of management standardization, agility, and business reality. But overall, the core of the method of product review during the operation period is the same: continuous improvement based on team collaboration.
The review system during the operation period needs to be supported by the product development process during the operation period. A simplified process for product development during the operation period (compared to the product development process during the construction period) should be formulated to collect and expose problems in the review system from other process links to ensure the continuous optimization of the product review system. For example, through feedback from quality testing, operations, sales, marketing and other links, projects with failed review systems are discovered and included in the case library to continuously optimize the R&D process and review system.
Establish rigid standards that must be reviewed and refine them into a quantifiable checklist form (simply the first criterion)
For example, if the development time is more than 1 week or less than 1 week but involves key business modules, they must be reviewed. The reason why a one-size-fits-all method of construction period and impact is adopted instead of using interface personnel to evaluate whether a review is needed is mainly to avoid too many human factors causing the review system to become a mere formality.
If it is less than 1 week and does not involve changes to key business models, the person in charge will make his or her own judgment.
The review must involve the participation of stakeholders, and cannot simply allow product personnel and technical personnel to evaluate by themselves. For example: product solutions must have technical personnel, operations personnel, financial personnel, etc.; technical solutions must have product personnel, architects, business experts, etc. Stakeholders participating in the review have the right to roll back the plan and redo it. Of course, this involves another bigger topic: team collaboration. If a team cannot establish a trusting relationship, no matter how perfect the system is, it will become a PK.
The reviewer does not need to conduct a comprehensive review, but only reviews the plan on key points of requirements, key business rules, and risk points to ensure the efficiency of the review. The review results need to be recorded in the relevant process form.
Establish a review case library, review the review case library regularly (monthly), and continuously optimize the review system. The summary of the review case should focus on the matter rather than the person. Do not put the burden on the reviewer to be fully responsible for the results.
The execution of a system does not depend on how perfectly the system is initially defined. The key lies in whether the system can be continuously optimized. Continuous optimization/continuous improvement/continuous improvement is one of the well-known and effective core secrets of various management methods, but it is also the most difficult to implement. Especially compared to those management fashion buzzwords, mentioning continuous improvement is too unoriginal and boring. It’s so high that we all hope for a “silver bullet” to solve various problems we face.
Source of the article: Become a monk as before and become a Buddha. Please indicate the source link when reprinting.