The uncertain factors in the daily work of the product are nothing more than functional bugs and requirements changes. What are the main points that can be prepared from the perspective of product operation through pre-investigation and prior confirmation? This article attempts to set out six points to throw a brick.
1. Implementation problems
(1) Master the overview of the data sheet involved in the demand
This is the basis of the last five points, such as the field type, range, what to take, how to take, where to return, which existing fields will be affected after the return, etc. (This step is often not easy in an environment with drastic changes in personnel);
(2) Internal and external collaboration
Just as the “edge” of a military map is the easiest to break through, bugs occur most frequently in cross-module, cross-domain and other multi-party interfaces. It is also prone to three-regardless areas. It is necessary to pay special attention to the data situation at the interface, especially Under the current situation of’opening’, the problem of the partner interface is the’big family’ of uncertainty;
(3) Defects of the process itself
The logic is more comprehensive, but the data source does not match, the older the system, the more serious the situation. To be honest, if you do not do the first step of basic data collection, you will not be able to bypass these mines, resulting in complete loss of control. Theoretically speaking, the defects of the collection process itself can also provide a reference for the reform of the business process. how to say? Promoting business from it in turn, may always be theoretically speaking.
2. Hidden performance hazards
(1) Among the fields involved in the demand, which ones are the most frequently accessed, and how frequently are the specific fields? Whether the most frequent fields (and their parent and child) overlap in the same project, and the specific degree of overlap;
(2) Whether the page where the requirement is located is a key page with high concurrency, or whether it will have an associated impact, including related pages at the upper and lower levels;
(3) If it is to hold an event, have you prepared for various functions and monitoring.
3. Responses to different timeliness
Distinguish long-term, periodic, one-off, and one-off that may be repeated many times.
- A semi-automatic and semi-manual copycat program can be adopted at one time to speed up the implementation progress;
- Periodically, consider developing tools to improve reuse capabilities;
- The intermediate state may be repeated many times. Based on historical experience, part by part will be instrumentalized.
4. Midway demand changes
Consider in advance the areas that do not involve logic and may change, such as the amount of data and the frequency of updates. Cultivate “common sense” and “habits” in this area, put forward redundancy in the requirements, and consider them in advance.
Consider the possible addition of complex associations and new logic, and estimate the workload of these changes in advance.
What if there is a huge demand change that cannot be rejected? Theoretically, the so-called “digging the real purpose of the demand side to guide and achieve a win-win” is used to deal with demand changes. Actual work is not so ideal. Demand changes involve complex interest entanglements. There is often no way to win-win. Try to rely on professionalism. Judgment, try not to get involved in the camp as much as possible (actually, it depends on the team culture, let’s go with the fate).
Whether the key process (such as shopping cart, payment page) adds additional steps or has an impact. If it is involved, try not to touch key processes as much as possible, and adopt asynchronous and other parallel methods to avoid risk out of control. Even small text changes in key positions need to be more cautious.
Performance is considered in every detail. Page opening and response speed are the foundation of all user experience. As much as possible, let the thinking of operation and maintenance permeate the subconscious mind.
The overall awareness of the impact of existing monitoring deployments must not only ensure the correct monitoring of new requirements, but also ensure that other existing monitoring will not be affected.
Considering the mutual influence of cookies and js, the same business repeatedly confirms the mutual coverage characteristics of monitoring.
Points to note in data monitoring: Focus on whether there is an abnormal trend at the two time points added and removed. ?
Common monitoring angles such as capture data, server log monitoring, business data, etc., according to specific needs, choose the focus of attention.