Temptation to unify versions

A few months ago, I came to work in a communication company from a software company and entered the billing and Information System Department. This Department maintains several important systems in the company: business, billing, accounting, customer service, resource management, business analysis, and product sales. These systems are the basis of the company's business. After several months of busy work, I gradually became familiar with my colleagues and working environment, and became more and more familiar with the maintained system.

The developer of the business and accounting system is a software company located in the northeast. This is a public company with a Level 5 CMMs. It has products in various industries, such as communication, medical care, and education. The communication systems are distributed across more than 10 provinces across the country. The developer has more than 10 field maintenance personnel on our site to help us maintain the business and accounting systems. System upgrades and analysis of new requirements require their assistance.

After several months of contact, I learned some characteristics of developers. Recently, they have the opportunity to come to their headquarters and experience their R & D process at close distance. A major feature of developers is to adopt a "Unified Version" approach. Specifically: in principle, on-site maintenance personnel cannotCodeMake changes. If the siteProgramIf a problem occurs, the maintenance personnel must report the phenomenon and cause to the development personnel at the headquarters. The developers should modify the problem, release a new version at the headquarters, and redeploy the on-site personnel. The customer puts forward new requirements, and also submits the analysis to the headquarters for unified evaluation and calculation to determine whether it can be implemented and how it can be implemented, then, the upgraded version is delivered to all provinces. This is the unified version. Each province in the country uses only the same version sequence, and each province uses different versions based on its own needs. Each version is maintained at the Headquarters, planned, standardized, and software.

The essence of the Unified Version is to pursue the unification of ideas and avoid differences between regions. Human thinking is a very complicated thing, especially software development is a mental work, which requires a lot of communication to reduce misunderstandings. One hundred people will always have one hundred ideas. A unified version is adopted across different regions, and the Headquarters implements strict management, avoiding differences of opinion in software design and implementation.

From the perspective of project management, using a unified version is conducive to control the scope and cost of the project. The customer's requirements are not implemented, how to implement them, and when to implement them are all centrally planned by the headquarters, and the development tasks are arranged in a uniform version, and then delivered to various regions for implementation. In this way, we can avoid conflicts of Principles between different regions. The headquarters has strong control over maintenance personnel in various regions.

This development and maintenance method is used for design and development by the R & D personnel at the headquarters, and the tests are then delivered to various provinces for on-site maintenance personnel in each province for deployment and maintenance. When an error is detected during the operation of the software system, the on-site staff analyzes the on-site status and then reflects the situation to the headquarters. The headquarters will find the specific cause and modify the situation. Then, the on-site staff will redeploy the software. If the customer has new requirements, they can discuss with the on-site personnel, and the on-site personnel should submit them to the headquarters. The headquarters should conduct unified planning for the needs of various provinces, arrange R & D tasks, and re-deploy the tasks on site after the tests are completed. There is a division of labor between the development personnel at the headquarters and the on-site maintenance personnel: the Headquarters personnel concentrate on technical capabilities and can arrange R & D tasks in various provinces for unified scheduling. On-site personnel should understand the actual software and hardware environment and the actual needs of customers. Such a division of labor seems very reasonable.

For the application systems of communication enterprises, although there are special situations in different regions in terms of business methods and different requirements for systems, they are in the same business field after all, the same enterprise nature is dominated by commonalities, and there are many commonalities between provinces. Using a Unified Version management method can also avoid repeated implementation of some common functions between different versions, avoid repetitive work, and improve the development efficiency.

However, using such a uniform version also brings many problems.

The most obvious problem is that on-site problems and customer demands cannot be solved in a timely manner. Generally, a fault is detected at the site, and the inspection is only a very easy problem to solve. However, under the uniform version rules, the on-site maintenance personnel have no control over the version, and must respond to the headquarters and issue a new version after the solution is solved. This process is sometimes quite long. After analyzing the new requirements raised by the customer, the on-site personnel should also submit them to the headquarters for unified planning. The headquarters personnel should understand the on-site conditions, then we will unify the planning and design and arrange the development strength. There are many links in such a process, and the time is often quite long. Therefore, there are many restrictions. The Information System Department often faces a lot of pressure from business departments. If some of the control rights can be handed over to the on-site maintenance personnel, the simple and obvious fault and localization requirements can be solved by themselves, and the coordination with the headquarters should be maintained during the process, it should be a more ideal method.

During system operation and maintenance, on-site maintenance personnel are often busy and the pressure is high. Because the programs sent by the Headquarters developers always encounter various problems, the on-site O & M personnel are in the fire-fighting status, so it is difficult to take time and manpower to think about the needs, and there is no energy to analyze the customer's business. The developers at the headquarters are far away from the northeast. The only way they know the field requirements is through on-site maintenance personnel. As a result, the development personnel do not understand the requirements, and the Development quality is difficult to guarantee. In addition, the personalized requirements of some regions cannot be effectively tested at the headquarters. These codes are sent to the site without being tested and handed over to maintenance personnel for testing and deployment. In this way, the quality of the development staff at the headquarters is under too small pressure, with no emphasis on improving the quality, resulting in a further decline in the quality. Then the O & M personnel are more busy with fire fighting and have no energy to analyze the needs.

Lack of understanding of requirements and lack of intuitive experience on the site environment, resulting in design and development staff not focusing on user needs. R & D personnel are often limited to technical details, and understand vivid customer requirements as database addition, deletion, query, and modification, and send several commands to the exchange. In such a R & D process, the software produced is very difficult to use, with messy functions, documents left blank, and many bugs. This results in extremely complex user operations and high ideological pressure.

All versions are centrally managed at the headquarters, and the actual results are not satisfactory. The management of unified versions is very complicated. Each province has a specific environment and has some special requirements. In order to adapt to the local environment and realize these requirements, some functions have been developed. The versions of each city are dynamically changing, and new requirements need to be implemented. There are bugs to be changed in the old version, and the development of the overall structure is still in progress, resulting in complicated branches and many versions, management is difficult and errors often occur. After the application deployment from the headquarters to the region is deployed, it will always find that the previously implemented requirements have disappeared, and the bugs previously eliminated have emerged. Customers and O & M personnel spend a lot of energy on missing features and repetitive bugs. Due to this problem in version management, product upgrade brings great difficulties.

The requirements of telecom enterprises can be divided into two levels. The first is the general requirements with industry characteristics, which are relatively stable. The second is the personalized needs of operators, which are complex and changeable. Different levels of requirements should be implemented by different personnel in different subsystems. The core part is developed by a group, and then each group meets the specific needs of each region on this basis. As long as the underlying subsystem remains backward compatible during the evolution process, versions in various regions will not be affected. This reduces the complexity of the version. Upgrade and maintenance are convenient, and can quickly respond to special needs of individual customers. Such a development form is reasonable. However, the developer adopts the form where the Headquarters is solely responsible for R & D and the site is solely responsible for maintenance. The Headquarters R & D personnel are responsible for all design, coding, and testing work. In this management mode, the system forms a unified large version, and the requirements of various regions are implemented in this version. Some of the requirements vary widely across different regions, forcibly unified in a single version, and even the following code appears:

If Sichuan then
......
Else if then in Yunnan
......
Else
......
End if

Developers at headquarters do not have a reasonable division of labor between general needs and specific needs, and they cannot focus on solving general needs in the industry, limited manpower is entangled in the unique software and hardware environment of each region, and it is time to deal with unique business needs. Maintenance personnel in various regions face difficulties in deploying and maintaining the Code with low quality, rigid design, and chaotic versions sent from the headquarters. If the demand cannot be met in a timely manner, it takes a long process for the program bug to be corrected, and the operator does not have strong support.

The development and technology of software systems are undoubtedly important, but they are by no means the most important. Business Needs must always be at the most important position. The purpose of technology is to eliminate technical issues in the project. At last, developers and customers talk about user needs, rather than talking with each other in technical languages, instead, we use the customer's business language to talk. This is the success of the technology. The developer has been working for this project for many years and has been deployed in multiple regions. He is still talking to the customer about database tables and stored procedures and cannot go deep into the customer's business. This is not an ideal state.

What is good software made? Instead of using hands or brains, they are made with feet. It is possible to understand the customer and understand the customer's needs to go out of the office, run more places, and perform careful research and investigation. Finally, we can consider the problem from the customer's perspective. What we do in this way is what the customer really needs.