一些工作中遇到的坑，引以为戒，避免再次踩入System problems:
1. Report query is slow, dragging down the speed of other applications
Solution:
First of all, both report query and interface form query can go to the read-only library.
And for report query, although the query volume is the largest, it only needs to support query delay data (synchronized once a day).
For interface form query, the amount of information is relatively small, but the latest information needs to be queried in real time. And the query frequency is more frequent, it is necessary to do a good job in the design of the cache.
In the system function design, it is also necessary to distinguish between report query and interface form query.
2. Because cost accounting is involved, every time the organization changes the person in charge, it is necessary to create a new organization with the same name (with different orgid), close the original organization and change its name.
Solution:
Establish an "organization-accounting organization", a 1-to-N structure. An organization life cycle includes multiple accounting organizations, and the system records each cycle of the accounting organization and the corresponding person in charge. The organization records the current person in charge.
3. Some hard-coded rules associated with the organization ID (orgid) make it necessary to review the impact of the association every time an organizational structure adjustment is involved.
Solution:
First, ensure that the organizational structure is adjusted by means of 2, and the id of the organization itself remains unchanged.
Secondly, for some rules that need to be hard-coded into IDs, it is recommended to highlight them on a unified configuration interface, which can be flexibly modified.
In addition, for complex business rules, a separate func is still established to process and return the type value. The basic logic of the system only needs to apply different processing methods to different types.
4. Some default rules for else are designed logically in the system, and some scenarios are not considered.
Solution:
Use the default rules with caution, especially for some key data, the source must match the corresponding type. If it exceeds the preset scene, it should prompt an error and not handle it. Otherwise, system results will be wrong due to unexpected scenarios.
5. The financial calculation script needs to be executed on the 3rd of each month, and is processed according to the data source information as of the end of the previous month, but the data source information will be updated every day.
Solution:
By copying, back up the information at the current moment at the end of the month, and get it for use when needed.
6. The development of the recruitment talent pool, because the amount of data is relatively large, the form content of the interface query, the development does not allow to add sorting rules.
Solution:
Use ES search engine to improve query performance. (Exchange time with space)
For data that does not require high timeliness, you can complete the sorting in the free time at night, and refer to the recommendation system.
Reduce the functions involved in full table query in the interface. (For example, the total number of tasks is displayed)
7. The process is written to death in the system. Once the business logic is adjusted, the development needs to spend a lot of effort to modify the underlying configuration of the system.
Solution:
For personnel changes, especially in developing companies, the process is difficult to stabilize. There is value in having a configurable process management system and configuration capabilities.
However, for some stable processes, it is necessary to improve the user interface and interaction through customization, so as to avoid frequent adjustments leading to exceptions.
Therefore, it is necessary to take into account both customization and configurability when designing the system.
For some simple approval and paperwork processes, it is recommended to build a general and flexible approval chain management platform (similar to the sign-in/approval system).
8. Development requires frequent data processing, which will take up a lot of time
Solution:
put the script of each data processing on git, and record it by category.
Developers take turns to do data processing and concentrate on time.
Business questions:
1. Permission management is confusing
Solution:
Strictly configure the corresponding permissions according to the organization, organization tree and position, to avoid assigning the permissions to the individual; at the same time, standardize the position name of each person, and monitor whether the position name is reasonable when there is a problem with the authority of a certain person.
(The company needs to have a clear definition of the position and the corresponding scope of responsibility)
2. After some functions are online, it has an impact on the functions of other modules
Solution:
Before the system function is confirmed and developed, it is necessary to inform all relevant departments of the requirements to be developed. After the system function is developed, it is necessary to contact the demand department for UAT testing, and the business side needs to test a wider range of scenarios. And notify all relevant departments of the launch time of new features.
The product must participate in the test to avoid the final result being different from the expected, especially the front-end interaction.
3. There are some big needs, the development is not understood, and there is no way to evaluate the time and problems
Solution:
For large requirements and plans, the development needs to be informed in advance so that the development can be prepared. Adjustments to some old and infrequent systems and functions also need to be notified to the development in advance. It is easy to understand in advance for development.
4. Departmental documents are missing. For some old and uncommon systems and functions, you need to check the code to understand
Solution:
The product needs to save and upload the PRD of the requirement problem, and perfect the product prototype (very important). Developers should also leave relevant system documents, especially the transfer of each
work , and do a good job in the handover of the above materials.
5. The key to developing product testing
The key to development work is to think carefully about technical implementation. Evaluating whether the development time is accurate is the result indicator of whether the development is professional enough.
The key to product work: A thorough analysis of the requirements is one of the key tasks of the product. The effect to be achieved is to be able to speak clearly to the developers, with reason, evidence and convincing.
The key to testing work: testing is ill-conceived. The requirements for testing are not trivial testing. Be sure to distinguish between key processes and key functions. Do not neglect key functions.
6. How to meet the demand
Find someone at a higher level to communicate. It is possible that a demand comes from a leader's plan, but the person who communicated it did not communicate the real demand.
Multi-faceted and multi-angle understanding of needs, and listening to it is clear.
If something doesn't have value to the business on its own, there's no point in optimizing it.
7. How to explain the requirements
For businesses and products, the requirements (use case method) should be described according to business scenarios.
For development, the interface structure and functions should be described.
Some Views on Product Requirements Analysis and Design
1. The design of requirements needs to be distinguished: core and auxiliary modules
2. The design of the core requires a full understanding of the business and certain expectations for future development. Once set, it will basically not change. It is the lowest-level framework in the realization of development business functions. A good idea is to break down the requirement elements as finely as possible, then analyze what the core is, and consider the difference and scope of the attribute table, operation table, and process record table.
3. The design of auxiliary modules is relatively flexible, and can refer to the idea of agile development, adopt a multi-iteration mode, and conduct testing and development cycles.
4. Product risk control: systemic risk, security risk, operational risk, and process risk.
5. Systemic risk: It is necessary to manage exceptions during development.
Operational risk: Do a lot of user testing and trial operations, and make prompts on the operation side to restrict users from performing "illegal" operations at the application logic level.
Process risk: Design the monitoring and quality inspection links, use professional tools to monitor the process, and check whether the process is self-consistent.