The "mystery" of software quality (2) -- hierarchy of quality (1)

Source: http://blog.csdn.net/KongDong/
Author: fasiondog

Part 1: the "mystery" of software quality (I)-hypocritical Quality

Note: The Administrative and Emotional Colors of quality mentioned in the following article are only the ways in which winberger reveals and explores management improvements in the organization from the perspective of psychology, do not use this as an excuse for failing to develop high-quality products. For the objective definition of quality, please refer to Zhu shaomin's article. It is recommended that you read this article first to avoid misunderstanding of quality:
Is the definition of quality always politically and emotionally colored?

Quality hierarchy

In the traditional quality system, the quality hierarchy generally refers to the hierarchy level in the classic quality pyramid model consisting of quality policies, quality manuals/organization manuals, processes, methods/tools/guides/standards, however, this pyramid model mainly expresses the structure of the quality management system, but it cannot express the reason why the quality system can operate and affect the product and the system principle. Here, we do not want to discuss the quality management system itself, but want to be able to explain and understand some driving factors behind the development of high-quality software products, these factors play an important role in realizing the "customer-centric" goal of a software organization.

So what is the level of quality that we want to express here? As mentioned above, all definitions of quality are hidden from the "Administrative and emotional" factors. The situation will become very interesting as you look inside a development organization. From an emotional point of view, any stable team is composed of a group of people with some potential common values. This value affects and promotes a unique quality view of the team, in addition, the potential quality view of some authoritative people in a team has a profound impact on the Quality View of the entire team. Generally, these people are the Leader of the team or the technical authority. From the perspective of the Organization, any organization has a certain organizational structure. A slightly more complex organizational structure has a certain level.It is this hierarchical relationship between people and the organizational structure that makes people's quality view a certain level, the hierarchy of such quality is not the quality attribute embodied by the product itself and has an objective existence, but an additional attribute (or feature) generated by the two reasons above).

This additional quality hierarchy has two notable features:

1. TeamLeader(Or some authority in the team. For the sake of simplicity, I will only talk about the team.Leader) Plays an important role in a team's potential quality view;

2. The influence of the environment and position on the true quality view of teams or personnel at different levelsDecisiveEspecially those factors related to their survival and development. The most classic and powerful evidence here is what people often say: "ass determines thoughts "! (Where is a person talking)

First, there is nothing special to note here. The second feature not only reveals the reasons for choosing different paths for different software development methodologies and the core factors behind the success, but also helps to understand the causes and considerations behind organizational structure changes.

In the early days, the typical organizational structure of software product development was to develop new software products with the core of the R & D team (now there are also new conceptual products, just to illustrate this, do not overdo), and sell to the customer, as shown in:

Due to the Quality View of R & D personnel (such as the pursuit of gorgeous interfaces/New Technologies ......) And actual customers (such as profit, cost reduction, simple operation and maintenance, and short repair time ......) There are obvious differences. As people gradually recognize this issue and propose a "customer-centric" view, people are required to fully understand the actual expectations of customers, therefore, the figure above can be converted to the following figure. However, as shown in, because the R & D personnel are not fully in direct contact with customers, the customer's quality view does not effectively affect the thoughts and actions of R & D personnel, in addition to the pursuit and preferences of R & D personnel, the more important organizations actually require R & D performance. If the progress is assessed, fewer defects will be sacrificed, if the assessment is a process, the process will be well qualified, and the progress and few defects are often discarded. What should I do? How can we achieve the customer's expectations in R & D?

(To be continued)
Note: This part is not clearly described and may be modified later. If you have any suggestions, you are welcome to discuss it.

Article 1: "Mysteries" of software quality (I)-hypocritical Quality

Subsequent topics:
Solution to Agile Methods
Structural Adjustment of large software organizations
Large software organizations: the foundation of Bureaucracy
Balance between the impact of quality view and goal orientation of managers