[Product Manager] Small Team General Workflow SOP Solution

: The so-called SOP, or standard operating procedure, refers to describing the standard operating steps and requirements of a certain event in a unified format, which is used to guide and standardize daily work. In the actual implementation process, the core of sop is in line with the enterprise and executable, not just a formality.

1. Interdepartmental Workflow

The cross-departmental processes and functions are shown in the figure below.

2. Operation

1. Daily submission requirements
   Operation and business students, fill in the form below and submit to the product manager.
   

2. Activity needs

According to the size of the event, submit the event plan to the product manager at least 15-30 days in advance. The event plan template has not been sorted out yet, and a special article will be published to discuss the event.

3. Products

The daily workflow of a product manager.

1. Demand pool

The demand pool of the product needs to be updated every day to make corresponding status changes. Can be summarized according to the template below.

2. Needs review

Before the demand review meeting is held, send a formal email to notify relevant stakeholders. The email template is as follows:

Dear all,
I have recently completed the research on the function of XX, and completed the version design of XX v3.0 on this basis. Now I invite you to hold a meeting to review this demand. The specific arrangement is as follows: meeting
time : September 1, 2018 at 10:00 AM
Meeting format: Offline meeting
Purpose of the meeting: XX v3.0 needs review
Participants:
1) iOS-Xiao Zhang, android-Xiao Chen, research and development...
2) Testing Xiaohong, product Huang, design Xiaoliang...
The following is the summary of this meeting, please refer to it:
××××××××××××
Tips: Please read the requirement description in advance. Be on time.
Possible problems (discussion points) are as follows:
×××××××××××××
Above
I wish you a happy life!

The requirements review process is as follows:

3. Prototype and requirements management

Requirements are presented in the form of requirement prototypes and annotations. Requirement prototypes are uploaded to Blue Lake, and specific requirements are updated in Zen Tao synchronously.

4. Data embedding template

Applet:

Other systems:

4. UI

1. Design drawings and labels

Upload the UI design drawing to Blue Lake, and provide the corresponding cutting picture.

2. Unified design specifications

For example, background management system.

5. Development

1. git code specification (intercept the fragment, see the code specification document for details)

2. git workflow specification (intercepted fragments, see specific documents for details)

3. Version number naming convention

Take YinLiFang_1.0.0.170517_beta.apk as an example:

Major version number (1): When there is a major change in the functional module, such as adding multiple modules or changing the overall architecture. This version number is up to the project to decide whether to modify it.

Subversion number (0): When there is a certain increase or change in functions, such as adding functions such as permission control and custom views. This version number is up to the project to decide whether to modify it.

Phase version number (0): Generally, it is bug fixes or some minor changes. Revisions should be released frequently, and the time interval is not limited. A revision can be released when a serious bug is fixed. This version number is up to the project manager to decide whether to modify it.

Date version number (170517): It is used to record the current date of modifying the project, and the date version number needs to be changed every day to modify the project. This version number is at the developer's discretion whether to modify it.

Greek letter version number (beta): This version number is used to mark which development stage the current version of the software is in, and this version number needs to be modified when the software enters another stage. This version number is up to the project to decide whether to modify it.

Introduction to version stages represented by Greek letters:

Alpha version: also called α version, this version is mainly to implement software functions, and usually only communicates within the software developer. Generally speaking, this version of the software has more bugs and needs to be continuously modified.

Beta version: Compared with the alpha version, this version has been greatly improved, and serious errors have been eliminated, but there are still some defects that need to be further eliminated through multiple tests. The main modification objects of this version are the UI of the software .

RC version: This version is quite mature, there are basically no bugs that cause errors, it is almost the same as the official version to be released, and the version that the testers basically passed.

Release version: This version means "final version" and "online version". After a series of test versions of the previous version, there will eventually be an official version, which is a version that is finally delivered to users. This edition is also sometimes referred to as the Standard Edition. Under normal circumstances, Release will not appear on the software cover in the form of a word, but will be replaced by the symbol ®.

6. Test

1. Testing

After the development is completed, submit it to the testers in a more formal form. The template is as follows:

Version number of the test version: V1.0.0-beta

Version name: 20190102 release content

Testing time: 2020-01-16

Version content:

××××××××××××

Test environment address:

××××××××××××

Test login account and password:

××××××××××××

Other Notes:

If a serious bug is found during the acceptance test, the version will be returned, and the test will be retested after the repair is completed.

2. Test cases

The template is as follows:

Test points:

UI tests:

• Make sure that the prototypes and renderings at hand are the latest versions.
• Ensure that the product UI conforms to the prototype and renderings made by the product manager.
• All interface problems are subject to the renderings. If you have any suggestions on user experience, you must first ask the product manager by email or orally.
• Since the data in the test environment is simulated data, the data types that may appear in the formal environment must be considered in advance during the test.

function test:

• Make sure you have the latest version of the functional requirements document on hand.
• Make sure that all software functions are implemented and the logic is normal.
• All functional issues are subject to the requirements document. If you have suggestions on user experience, you must first ask the product manager by email or orally. Personal suggestions, user experience suggestions, are prioritized after fixing bugs.
• If some functions are technically difficult to implement or cannot be implemented in a short time due to scheduling reasons, they must be confirmed by the product manager instead of just listening to the technical explanation of the developer. The confirmation here is best to exist in the form of email.
• For all "external reasons" problems, it is necessary to urge developers to contact and coordinate with customer service personnel as soon as possible. And it will be reflected in the subsequent test report.
• All "design so" and "deferred processing" issues need to be confirmed with the product manager before verification. And it will be reflected in the subsequent test report.
• When placing a test order, the registered test account must comply with the company's specifications; the delivery address must contain the keyword "test", and it is best to include the date in the name of each order for easy query; after placing an order in a formal environment, you must cancel the order etc.

Compatibility test/performance test:

• Ensure that the software can be used normally on all compatible models (iOS generally needs to be compatible to 6, ios5 can be ignored, and the user usage rate is already below 5%)
• The performance test must meet the test requirements under hardware stress conditions (for example, multi-threading, and the apps commonly used by users must be tested in an environment running in the background.)
• The performance test of network response to user experience needs to ensure the switching effect under wifi, 3g, and 2g networks. For example, switching from wifi to 2g, the speed of network response and switching interface.

3. Test Daily

Testers need to send test reports to the tested items every day. The content of the test daily is as follows:

• Grading the quality of the current beta version
• Give examples of more serious problems and prompt developers to modify them first
• Assess the overall situation of the release
• Record the content modified during the version testing process

4. Go-live report

Before the product goes online, testers send a product go-live report. The contents of the online report are:

• Grading the quality of the current version
• Attach the test report (functional test report, compatibility test report, performance test report, etc.)
• Summarize the basic situation of the online version. If there are remaining problems, the solutions must be listed and documented

5. Bug submission management specification

The template is as follows:

[Function] The function module where the bug occurs, such as the personal center.

[Topic] Describe the module, phenomenon, error phenomenon and correct result of the problem in one sentence. For example, uploading avatar photos in the personal center fails.

[Recurrence rate] The probability of bug recurrence can be described by percentage, always, sometimes.

【Platform】Android, iOS, H5, Web, PC

[Problem Type] Interface/Function/Performance/Compatibility/Security/Experience

[Severity level] can be described by P0, P1, P2, high, medium, low or serious, normal, and low.

【Reproduction environment】DEV, TEST, LIVE

【Test models】iPhone 6, Google Pixel

【System Version】9.1.1

[Test version] Just give the version number, build number, and tag of the bug found

[R&D Division] Front-end, Back-end

【Prerequisites】

【Reproduce steps】

1. XXX
2. XXXXX

【Expected result】The expected correct result

【Actual Phenomena】A phenomenon that is actually seen as wrong

[Other Supplements] You can provide attachment documents, logs, screenshots and other information that can assist in the development and analysis of problems.

7. Release

1. V1.0 launch notice

The online email template is as follows:

Leaders and colleagues:

With the joint efforts of all colleagues, the "XX" project was officially launched on X, X, X, X! The project was initiated on X, X, X, X, and after XX days of hard work, the project team overcame XX and XXX difficulties, and all departments completed their tasks on time, so that the entire project went online smoothly. Thank you for your hard work, and thank you to every member of the project team!

The platforms on which this project is launched include:

• iOS (version number: V1.0.0, you can search for "XX" in the App Store, probably ranked Nth)
• Android (version number: V1.0.0 can be found in App Store and XX software store, search for "XX" and probably rank Nth)
• Download the QR code as shown in the figure: [Pretend there is a QR code here]

This version mainly includes the following functions:

• XXXX function, solve XX problem
• XXXX function, to meet the needs of XX

Welcome everyone to download and experience. If you encounter any problems, comments and suggestions during the experience, please give timely feedback to the product manager (email XXX)

The "XX" project carries the company's expectation of chasing the XX market. In the future, we will cut through the thorns in the XX field and create infinite possibilities for the company! This requires us to pay more hardships. Going online is just the starting point, not the end point. We have already formulated the next work with each team, which will allow our products to enter the market and compete with competing products!

The main work we will carry out next:

• Do a good job in product optimization, XXXX
• Do a good job in product promotion, XXXX
• Do a good job in product operation, XXXX

Students in each group are asked to make persistent efforts and continue to XXXXXX for the "XXXX" project.

Thanks!

2. Version Release Notice

The notification template is as follows:

Version number: v1.1.2

Version content: XXXX

Release date: 2020-01-16

Code update time: specific time period (If it affects normal use, please inform in advance.)

8. Others

1. Meeting template

Meeting Minutes:

Meeting Minutes:

2. Weekly and daily templates

Daily :

Today's work content: content + working hours

work plan for tomorrow

Questions and more

Weekly :

Work progress this week

work schedule for next week

problem and solution

Summary : I hope everyone can benefit from it, formulate a sop that suits your team, and form an efficient, close and combative team.