Maintenance Team building in software companies

Compared with the development teams in software companies, maintenance teams often seem obscure, and work is relatively conservative, far from being as fresh as development teams. This is a common phenomenon, that is, maintaining the value of a team is often intentionally or unintentionally reduced. In fact, the construction and management of the maintenance team is much more challenging than that of the development team. If the team runs properly, they can complement each other with the project team or development team and take full advantage of the driving force.

The goals and procedures of the software maintenance team is assigned the responsibility to maintain paid products. The main task is to analyze and fix new bugs and make some adjustments to the software by the customer, the specific content depends on the maintenance contract. In short, it is either repair or makeup, or icing on the cake. Because it is a delivered product, its change is the cost of the development team's development process 2 ~ 25 times, which has been finalized in the software engineering field (refer to here and here ). If a new bug is introduced due to a change, it indicates that at least two changes are required, and the cost is 4 ~ fixed during the development process ~ 50 times. In order to ensure the quality of changes and reduce risks and inconsistent costs, the software maintenance team usually has more strict processes than the development team, and the management should be more detailed. The following is an example of a software maintenance team process: the maintenance team building is more difficult because of the constraints of the maintenance team. The biggest challenge is personnel stability. How do I select a person to enter the maintenance team? First of all, we must be meticulous and rigorous. We must be willing to stay calm and be able to meet the standards of our technical skills. Such a person may be irretrievable and often changed. Water Control is not blocked. I personally think there are four key points: 1. Try to select the right person to enter the maintenance team. Although difficult, we still need to work hard. Be sure to know what is the first condition and what is the secondary condition. For example, whether technical capability is the first condition depends on the team's goals. 2. Establish a good rotation system to ensure smooth rotation between the maintenance team and the development team. The inbound and outbound conditions are set flexibly. 3. Establish a technical handover process to reduce the risks caused by personnel flow. 4. Combined with the shift system at the second point, new technical personnel and interns can be recruited to the maintenance team, and the team atmosphere can be active while reducing the workload. These practices allow the maintenance team to have a unique advantage over the development team or project, and attract some people. The key is to maintain a fairness. Adams's theory of fairness refers to whether he recognizes the proportion of his income to his input. That is to say, if the maintenance team is managed by the project team, can maintenance team members feel fair? Of course, these practices are only a cure, not a cure. To solve the problem, we need to discuss the setting of team goals. The maximum pressure on New Driving Force maintenance comes from its goal setting. The so-called pattern determines the outcome. How can we form a more favorable structure? First, the technology of the software maintenance team should be the same with that of the development team. Why cannot it be used? Can problems found during maintenance and identified requirements be imported into the development team? Compared with the development team/Project Team, if the maintenance team has a relatively low time pressure (depending on the product type), it will have the opportunity to conduct in-depth research on the problem, especially the knowledge related to the field. In-depth research to reduce side effects is also the most important task for the maintenance team. This advantage is a feature that can be leveraged. It is the responsibility of the maintenance team to thoroughly explore problems and seek solutions. The research results are then transferred to the R & D team in the form of documents or technology sharing. In addition, the maintenance team is involved in the development team's queries, including design, documentation, and code, which will also provide great assistance for the team's overall capability improvement. Is it feasible? Start with the team goal. If a maintenance project is terminated, the maintenance team may be disbanded. It is predicted earlier that the prospect of the maintenance project will allow managers to have sufficient preparation time. According to the description of Software Evolution in <Software Engineering> 9th, software maintenance decisions should be made from two dimensions: Business Value and system quality. After the results are obtained, different decisions are made.

Biz Value	System Quality	Strategy
Low	Low	Scrap or replaced ). High cost, but of little significance.
High	Low	Replaced or reengineer ). High maintenance cost, but great commercial value.
Low	High	Continuous evolution (evolution ). Low maintenance costs and low commercial value.
High	High	Continue maintenance.

As for the specific indicator setting methods used to evaluate business value and system quality, the author has given some suggestions. To achieve this, in addition to understanding the product features of the maintenance team (software complexity, maintainability metrics mm), but also the corresponding market changes (requirements of different stakeholders ).