Section 5th on cultivation of product thinking of mainong-selection and management of product requirements-"Everyone is a product manager"

This section mainly summarizes the content of section 2.4 and section 2.5 in Su Jie's book.

The requirement PK is a common problem in an Internet company. If the PK wins, your product can be established immediately. If you lose, other products will be launched. You can stay.

Product Requirement selection mainly includes: requirement packaging, BRD production, product meetings, and project initiation if it passes.

1. Preparations: pack the requirements

Our product must be implemented as a project within the company. The project is about how fast and easy to complete the task, which will be discussed later. Therefore, your demands will not give you a chance to implement them all. So you need to sort, select, and package the requirements.

Project creation,The ultimate goal is:High Speed and good saving, that is, large scope, short time, high quality, and low resource. We need to balance these four resources. Currently, agile development is the preferred project method. The project time is generally fixed, and the major point is "iteration cycle", which is generally 2-4 weeks; the team is relatively fixed, so the project resources are fixed. Then, the product quality should be ensured at any time. So, at last you will find that only the "amount" can change ----Project Scope.

We have previously mentioned the cost-effectiveness (commercial value/cost) of a requirement, sorted by cost-effectiveness, and determined the scope of project execution. Some requirements can only be added in subsequent versions. We call the process of selecting a requirement"Requirement Packaging".

The general principle is to package according to the cost-effectiveness, but pay attention to the following issues.

1) it is best to package similar functions for "requirement packaging. What are similar functions? This is generally closely related to the business logic and can be identified based on the basic attributes required. Not difficult.

2) requirement dependency. There is a dependency between functions. In this case, the dependency can only be performed first, and the dependency of functions on personnel is another one. For example, if you want to write a module that is particularly difficult, there will be a huge meeting in the entire project, so there will be human dependency, which is also a problem to be considered. The best thing is to constantly improve the capabilities of the entire development team.

3) requirement granularity issues. A complex requirement can always be subdivided, but what is appropriate. IGenerally, the workload of a single requirement should not exceed 5 person-days.Otherwise, it is difficult to control.

2 battlefield: Product meetings

A product meeting is a meeting for a group of elders to allocate resources to the product manager. It is generally once a month. At the beginning of the meeting, we generally review the project passed by the previous product meeting, the current progress, whether to adjust the time schedule, whether to add resources, and whether there are major changes in demand, what are the problems with released products. This review is very necessary. On the one hand, let the bosses update their understanding of this product project, and more importantly, accumulate experience to make more reasonable decisions for future product meetings.

After the review, we will take our business demand documents for you to listen to and snatch resources .. Generally, resources are snatched from different projects within a product. Because developers seldom say they switch between different products, they need to be familiar with the product.

3 weapons: Business Requirement documents

BRD: Business Requirement document, Business Requirement document.

MRD: market requirement document, market requirement document.

PRD: Product Requirement document, product requirement document.

How to Write BRD?

Project Background: Where are we? Why is this project necessary? What are the problems solved? When necessary, list some numbers to illustrate the necessity of the project.

Commercial Value: where do we go? This is the most important key point. What value will be generated after the project is implemented? predict the number and discuss the business objectives. Big Brother's favorite.

Function Requirement Description: how can we proceed? What do we need to do to achieve our goal. Describe the packaged requirements,You can use the "function list" to draw business logic relationships..

Non-functional requirements: for example, performance.

Resource Evaluation: second focus, mainly human resources and other resources.

Risks and Countermeasures:

4. One requirement is life-and-death.

Requirement status: Waiting for discussion, rejected, suspended, in demand, under development, under test, completed.

Demand management,

Do a good job in statistics. For example, statistical time and quantity.

(End)

Section 5th on cultivation of product thinking of mainong-selection and management of product requirements-"Everyone is a product manager"