Release judgment criteria・Estimate the number of call center calls from the remaining bugs(2-nd)
- 1. Estimate how many call centers will be called in a month due to residual bugs
- 2. Calculate the total number of units in operation A2 following A1
- 3. Next, consider the declaration rate for each degree of impact of the problem event in (B).
- 4. For example, this is the table
- 5. What is the adjustment factor for each country?
- 6. Finally the calculation formula is completed
Estimate how many call centers will be called in a month due to residual bugs
The previous article and this next article show you how to estimate and calculate the number of phone calls to the support center due to residual bugs. This is the way of thinking of Gutara’s father that even if there is a residual bug at the time of software release judgment , the release of the software is approved with little influence on the service provision according to the purpose of the software. Now, let’s explain the contents of the calculation formula in order following the previous article.
Calculate the total number of units in operation A2 following A1
It is sufficient to calculate the total number of units in operation per month in (A2) by the number of units in operation in the market x 30 days. Not limited to this item, it is an estimation calculation to the last, so no accuracy is required for any item. Even if one of the items is highly accurate, the other estimated items are not very accurate, so multiplying them will eventually settle to a rough accuracy.
Next, consider the declaration rate for each degree of impact of the problem event in (B).
Now that (A) the estimated number of problem events (times / month) per month has been calculated, next is (B) the declaration rate for each degree of impact . What is the degree of influence? It is easy to understand how much the problem event affects the service provision .
Take, for example, an online game. The problem of not being able to press the start button of the game has a great impact. Since the purpose of the game software is to provide a service when you enjoy the game, you will not be able to provide that service at all, so the impact on the provision of the service will be great.
But what about the problem of picking up a particular item in the game and not picking it up? It depends on the importance of the item, but if it is not so important, it seems that you can continue to enjoy the game even if you can not pick up the item. In this case, the provision of the service of enjoying the game is not significantly affected.
Perhaps one in two people who have experienced the problem of not being able to press the start button of the game will call the game maker’s support center to declare it. But what about those who have experienced the problem of not being able to pick up a particular item in the game? About 1 in 100 people may call the support center for declaration.
In this way, if the degree of influence of the problem event is large, the probability of making a declaration call to the support center is high, and if the degree of influence is low , the probability of making a declaration call is low. This is represented by (B) the declaration rate for each degree of impact. This is difficult to calculate with a formula, so Father Gutara made a table and decided the value for each degree of influence. .
It is difficult to think of a declaration rate for each degree of influence that is decided and created by this software, so it is necessary to prepare for each market in which the software is used . It’s easy to understand from the example used in the previous article, but the decision whether to make a declaration call to the support center differs considerably between the bank’s online payment software and the online game software. Therefore, it is more convenient in actual luck to make it for each market where the software is used.
For example, this is the table
Probability table of declaration calls for the XXX market
Degree of influence | User declaration rate | explanation |
Declaration rate when notified to the support center (* 1) |
Serious | 1.0 | 1 in 1 (all) | 1.0 |
important | 0.5 | 1 in 2 | 0.05 |
generally | 0.01 | 1 in 100 | 0.0 |
Minor | 0.0001 | 1 in 10,000 | 0.0 |
*1: If the customer’s approval has been obtained for the defect, the rate at the time of customer approval will be adopted.
The vertical direction of the table, one of the problem events to what extent affect the service provided to the end user the degree of influence , and is written in four stages from serious to minor. The number of people who make a declaration call to the service center when a problematic event of each degree of influence occurs is written in the user’s declaration rate column. For example, if a problem event with a significant impact occurs, it is estimated that one in two people will make a declaration call, and the declaration rate is 1/2 = 0.5.
Considering a concrete example of the degree of influence in an online game, for example, it is as follows.
- Impact = Serious: I can’t press the start button of the game (I can’t play the game, it’s an immediate call)
- Impact = Important: Login to the game fails once every two times (well, I can play the game, but it’s frustrating)
- Impact = Normal: I can’t pick up items that aren’t important in the game (I don’t really care)
- Impact = minor: The background image of the game is partially broken (OK if you don’t notice it)
In addition, in the rightmost column of the table, there is a column called the declaration rate when the support center has been notified. This is, Yes to contact the customer’s support center the problem events in advance, received a phone call reporting returns the operator is appropriate answer of the service provided to the end user in that if you can avoid the influence is, this value It is a column that means to calculate using.
In other words, if you receive a declaration call from the end user, but it is not very important and the operator responds appropriately and the service delivery is not affected, then no count is fine. is what it means.
There is no particular theory or experience in the values set in this table . It is a value decided by the spirit of a complete sickness. However , even if the value is decided by the spirit, it is possible to reduce the fluctuation of the judgment criteria of each software release by setting it, so I think it is better to decide even if it is awkward.
What is the adjustment factor for each country?
It’s not an incomprehensible expression. Even in the same market, the quality required varies from country to country, so the percentage of people who make a declaration call to the service center when something goes wrong in the market will change, so there is a certain amount to adjust. It is multiplying by a coefficient .
For example, let’s assume that the required quality of the Japanese market is 1.0 . Japan is a country with a high awareness of quality. I take it for granted that the products I bought will work properly in any situation. On the other hand, what about small countries in Southeast Asia, for example?
Even though the infrastructure has been improved considerably, it is not uncommon for power outages to occur. It is an environment of ion hula where the service of electronic devices is stopped several times a month due to a power outage. It is presumed that users who are accustomed to such outages due to power outages will not bother to call the support desk of the product vendor for a few product defects.
For example, in a small country in Southeast Asia, only about 1 in 10 people will make a declaration call, even if 2 out of 10 Japanese people have a disability to make a declaration call to the support desk. In order to incorporate this difference into the calculation of the number of filing calls to the support center, we use a value called adjustment count by country.
The word seems difficult, but for example, if Japan is 1.0, it is just a matter of multiplying the value of 0.5 at the end for small countries in Southeast Asia . Depending on the country, set a value such as 0.7, 0.5, or 0.3. Of course, this value is also decided by Aya.
Finally the calculation formula is completed
With this, I was finally able to estimate and calculate the number of declarations, such as how many declaration calls will be made to the support center per month when one bug remains in the released software . Thank you to everyone who has read this far.
It’s still a little early to be relieved. There is one more thing to think about, so I will introduce it in the next article.
Discussion
New Comments
No comments yet. Be the first one!