Project Process Management & architecture Summary

1. Project Background

There was no marketing cost for the business in the early stages. The discount for the buyer's purchased goods was provided by the seller. The final price of all orders was determined by the seller and the business party. The entire purchase process was very simple.

Now this business is valued by the company. The business team can apply for marketing expenses, and the business team can actively subsidize discounts. When a user buys a product during a promotion, the business party pays for the discount, and the seller does not need to consider the discount. To meet this marketing requirement, you need to work with third-party teams, such as the merchant marketing team and accounting team.

2. project management team collaboration

At the beginning of the project, I introduced the business background to the two groups and raised product requirements. The project started smoothly: define the business boundary scope, interface delivery time, joint debugging and testing time, and system launch time.

 

One week later, I was informed that the accounting team had rescheduled the development director and communicated with the developer to find that he did not understand the requirements discussed earlier, then we can start to discuss the product requirements and implementation solutions again, and all the time points set before the results will be discarded. Because the responsible colleague said that the implementation solution was very complicated, the first time I was speechless... Then I will start to reduce product complexity... Review the requirements by time and determine the time point of each progress.

Conclusion: if the core business depends on a third-party team, they should try to communicate with each other at the initial stage of the project to check whether there are any details that have been carried out or are unclear at the initial stage of the project, although there were few situations where developers were rescheduled at the beginning of the project, they did exist. After the complexity was re-evaluated, it was found that it had a great impact on deadline.

In addition to exposing the problem in the early stage of the project, you need to re-determine with the product demand side whether some modules in the requirement can be converted into simple rules. For example: the transfer subsidy for each seller's order is changed from the real-time settlement method to the daily settlement of each merchant's subsidy + the method of providing daily settlement details, because this method can continue to reuse the existing daily settlement logic of the accounting system, no need for the remittance system to develop a new real-time settlement module.

 

Based on this lesson, we will report progress to the marketing system and accounting system every two days, and provide API interfaces in batches or in demand, after your business system completes all the processes through mock, it develops and calls interfaces in batches. This allows you to conduct joint debugging and self-testing earlier than the unified interaction time. The system API interfaces of both parties can be concurrently called, tested, and developed to make full use of time.

 

The test environment is unstable: After the joint debugging of the main business process is completed, the accounting system colleagues told us that their test environment is unstable, but we thought they would solve the problem, after a day, I found that the problem was still unstable. I asked them when they could solve the problem. The result showed that, like playing the World Cup with the Chinese soccer team, I had no hope !!! I want to wait. If I want to wait, I want to get the tableware! We decided to go to their workstation and start to communicate with the test scheme. We took one day to perform on-site self-testing and running-in, and then started the business test-to communicate the problems in the test on the chat tool, and then the test went smoothly.

 

Demand change

In a project, the PM cannot accept too many changes in the demand-the judgment is based on the complexity of the current technology implementation, rather than relying on the description of product functions. Therefore, acceptable demand changes are generally simplified requirements for product functions.

In cross-team cooperation, a simple change in requirements may lead to project delays if the requirements are not synchronized to the partner team. Even if the product team is informed of this change, the technical team should re-communicate and confirm that the technical team of the partner is likely to change the technical implementation solution because of this small demand change and will not notify the partner actively. PM should always pay attention to this change and ensure that all teams keep abreast of the latest product requirements.

 

In this project, we temporarily decided that a feature will not be used for this activity (the business side has no time to collect statistics), but will be used for subsequent activities, but it is not synchronized in time, the result was quoted by the partner, saying that if this is the case, this version will not be available and will be extended to the next version. However, all functions are available on time, \ (^ o ^ )/~.

 

In the final analysis, we must put communication first.

2. system design modules and Coupling

Divide the business boundaries to ensure that the new business function module has the least correlation with the current system and is easy to split logically or physically. An independent business module only processes one event, and handles the event perfectly. In addition, it is easy to use in other business scenarios and does not carry any historical business burden for function expansion.

Robustness

Robustness is divided into business robustness and System Service robustness.

The robustness of business implementation is reflected in the idempotence, transaction, and fault tolerance of business. Like the implementation principles of post/put interfaces in the rest architecture style, it is recommended that each interface has idempotence characteristics. Query Interfaces naturally support idempotence, however, the Add/update/delete interface requires some feature parameters to implement these principles. A completed transaction consists of multiple sub-processes, such as A, B, and C. If the C process fails, how should we deal with the current transaction business?

There are two scenarios:

1. If the current transaction is a subsidiary process of another transaction, because the preconditions meet the business scenario, the next transaction process is not allowed to fail, then the transaction is inappropriate in this scenario, you can only retry the service status to ensure the final success.

2. The second method is also common: If C fails, the transaction/distributed transaction is used to roll back all operations A and B, and the business operation fails.

 

If both methods are optional, the 1st methods are more reasonable because the implementation method that can be retried does not cause a temporary error due to a process: database connection failure, thread pool task addition failure, and so on, these interfaces can also be exposed to the management interface for manual intervention and automatic system compensation operations.

 

The service robustness ensures that the final state of the service provided to the user is certainly consistent with the expected results.

 

The robustness of system services is reflected in good Error Notification and recovery policies. If a single node in the system goes down, the service is unavailable for a period of time, or the pressure is too high, the whole service cluster should not be unavailable. The so-called load balance, failover, failback, and throttle (sampler) hardware and software policies can play a major role.

 

Self-monitoring

Monitoring is divided into business monitoring and system application environment monitoring.

Business System Monitoring focuses on the RT/QPS of business interfaces, the number of successes and failures, and the volume of core businesses. In a certain period of time, if there are large fluctuations in data indicators, it may be that some business interfaces have problems, or some occasional error alarms also need to be concerned, these occasional bugs may also be caused by code logic bugs or system bottlenecks.

The monitoring of the system application environment is very common to the system load, CPU, mem, disk Io, Nic traffic, JVM, and so on.

Management Portal

Business Management Interface: Previously, the idempotence and fault tolerance of the system have been emphasized. The system can achieve eventual consistency through automatic retry, and the interface can be easily exposed to the Management page, manual intervention by management personnel for compensation operations or data correction. In this system, basically all service interfaces are exposed to management, making it easy to perform data correction and business retry.

Configuration item management interface: High configurability is a system that can easily achieve high service reliability and scalability. You can modify the configuration to enable or disable services that are under too much pressure... This launch of the system started the activity because the new feature was launched for fear of miscalculation of accounts. This service configuration was enabled only after the payment was temporarily suspended and the total amount of accounts was confirmed.

3. Conclusion

Every project has a bad idea. In the project process, the communication is not smooth, personnel changes, and requirements are forcibly changed. some third-party systems that depend on them are not transparent, some Hidden Rules are often discovered only when the first time they are used.