"One Ring To Rule Them All"
JRRTolkien
“You can only manage what you can measure.”
P.DrukerWhen it comes to metrics, dozens or even hundreds of different options come to mind.
What kind of measurements did not come up!
But the trouble is, when you look at these beautiful pictures, it is often completely incomprehensible what they mean.
And in general, it is completely unclear whether these metrics were chosen correctly or would it be worth looking at completely different ones?
I would like some kind of one metric, such that it looked, and everything immediately became clear.
But does she exist? Or is there no magic?
Let's see and look at a specific example ...
Often, all we have is just a certain set of input data with which it is not very clear what to do.
Jira and her tasks
Imagine that your company uses the Jira task tracker and all developers are required to mark in it the events of taking tasks to work and their solutions.
You can get an unload on Jira tasks, but what to do with it next?
A good idea in this situation is to think about what exactly you want to control and what result you want to achieve.
Read, for example, the article “
Insight into the metrics: how I understood what metrics are and what their main charm is ”
And if you add here the books “Lean Analytics”, “Running Lean” and Tao Toyota, it becomes clear that in the case of Jira, it is more correct to manage and measure the delivery time of the developed functionality in prom.
So, the goal is chosen - we want to measure the software delivery time, but this can be done in hundreds of different ways. For example, you can measure the length of each of the development steps, and also add to this the measurements of the loss of waiting time, repairing defects, re-opening, etc. Even on the vskidku can be called about 50-70 different metrics related to software development.
How to be? Is there the only One Metric on which one can understand everything with one glance?
If you have seen with your own eyes those dozens of metrics that are discussed above, then I know in advance your answer - you will say: No! And so you want ...
I would like such a metric, one glance at which one could understand how much development is progressing and whether it is necessary to do something additional with it.
Surprisingly, it seems that there is one worthy metric that can safely claim to be the
One and Only Unique .
Let's take a closer look at it.
There is such a report in Jira as “Total Flow Chart” ...
“Stop-stop-stop ... Everybody knows him,” you say, I will not find anything new here. ”
In general, yes, the report is well known to everyone, but still let's take a look at it in a little more detail. I assure you, there are several "pleasant" surprises.
Here is how it usually looks like:
Any stripes. What are they for? What for? What do they mean? But what ...
Dark red bar - the number of tasks implemented on an
accrual basis . Blue - the number of tasks in the work, and yellow - new tasks registered in the backlog.
The cumulative result is when tasks are completed all the time added to the number of tasks made earlier.
For example, imagine that the day before yesterday you did 2 tasks. On the graph the day before yesterday point will be marked: 2.
Yesterday you did 3 more tasks. The next point on the chart will be equal to 2 (the day before yesterday) +3 (yesterday's) = 5.
And today you have done another task. Today's point on the chart will be equal to 2 (the day before yesterday) +3 (yesterday's) +1 (today's) = 6
Those. the schedule will increase all the time.
And so, if we plot on the graph the number of tasks made, the number of tasks in work and new tasks, then we can extract the very One and Only Unique Metric.
Consider a real-life example (unloading from Kibana and Elasticsearch):
Do you see?
In fact, we can calculate the speed (or performance) of the development. 200 new tasks are made in 17 days. From here we get that the current speed is the development speed - 11.76 tasks / day, i.e.
One task is performed on 0.085 days .
Judged by schedule, the number of tasks in the work, the blue area does not change (the width of the strip is almost the same everywhere), i.e. it can be assumed that the speed of development is constant, in contrast to the number of new tasks.
With the current speed of development, 800 new tasks created on 06/17/2018 will be completed only after 68.03 days.
Fine? In my opinion, not very.
Speaking? Definitely!
Here is another real example (Jira report). This is the schedule for the execution of tickets by technical support:
Similarly, we calculate the performance of the support service - 2.7 tasks / day.
There is something to strive for
It is not enough to know the current speed. It is also necessary to understand the target value, i.e. see what to strive for.
Understanding the speed of work of one person, you can calculate how many people the support service will need to realize the target number of tasks or increase the current performance.
The support service employs 15 people. It turns out that per person accounts for 0.18 tasks / day.
Suppose you want to increase the speed of execution and ensure that the service can work out not 2.7 tasks per day, but 10 (target value).
One person does 0.18 tasks per day, which means 10 tasks will be done by 56 people.
Well, or as an option, you can increase the speed of one person.
With the speed of 1 task per day, for 10 tasks you need not 56 people, but only 10.
Manage delivery time
It turns out that the metric allows you, in fact, to affect the delivery time.
Comparing the current performance with the target value, you can understand how many times it is necessary to speed up the process.
By varying the parameters that make up the performance (the number of people and the speed of their work), you can control the total delivery time.
And where else is it applicable?
In fact, metric analogs can be seen in many areas.
Take, for example, DevOps. DevOps is used to reduce the time interval between the creation of a distribution kit and its deployment to prom. here, as well as in the examples above, you need to manage the delivery time.
Obviously, the metric is perfect for DevOps. Just count how many distributions (assemblies) came up to the prom in a certain time and get the current performance of your pipeline.
In principle, this same metric can be used in areas related to money.
For example, for an online store it would be possible to similarly count the number of orders for a certain time. The whole question is, do stores really need it?
Conclusion
As you can see, the One and Only Universal Metric has the right to life, at least in the field of software development and in the service divisions (technical support service).
It is simple to calculate, contains a meaning, and can be used to compare with a target value.
Of course, it can not be applied thoughtlessly. Before proceeding with the implementation, think, and really you need it.
And what do you think about the universal metric?
Which metric do you use as a universal one?