Some functions of Smayi Enterprise Edition 4.0 have entered the internal testing stage✨We will use a few articles in the near future to give a brief overview of the new functions of 4.0.
The topic of the last few articles will be the GQM Kanban in version 4.0 - GQM stands for Goal-Question-Metric (Goal-Question-Indicator), which is a set of systematic methods for building software R&D effectiveness measurement. To put it simply, the GQM method emphasizes clear and specific goals, dismantling from top to bottom, establishing a measurement model for research and development through questions + answering questions based on quantitative data analysis, interpreting and achieving goals from bottom to top. For more interpretation, please refer to " GQM Overview: The Fundamental Method for Building R&D Effectiveness Measurement System ".
Compared with most so-called "data Kanban", the evolution of GQM Kanban lies in the fact that the data is no longer simply listed and confusing; it first disassembles the specific measurement goals in specific scenarios into problems, and then leads to indicators from the problems Charts convey information in a progressive manner and guide users to drill down and explore in due course.
We believe that good performance metrics must not be difficult to understand. We hope that even front-line R&D managers who do not know much about the field of R&D efficiency can understand the meaning of each indicator and the information given by the indicators at a low cost, and actually use the metrics to solve their problems in R&D management. All kinds of "can't see clearly" and "can't explain clearly".
In the previous article, we introduced that we will introduce the "Project Delivery Efficiency Kanban" in the GQM Kanban , and this article will continue to introduce the "Project Human Efficiency Kanban".
0. Why is R&D human efficiency measurement so embarrassing?
As we mentioned in the previous article, R&D efficiency should ultimately be reflected in delivery efficiency (or flow efficiency), so that value receivers feel more deliverables, more timely responses, and faster achievement of R&D goals.
Human efficiency, or resource efficiency, as opposed to delivery efficiency, although often criticized, is still an unavoidable topic in R&D efficiency.
He Mian, "How does Ali define the R&D efficiency of the team?" "
On the one hand, it is indeed necessary to measure and improve human efficiency.
Improvements that only focus on delivery efficiency, such as strengthening cross-departmental communication and coordination and reducing waiting, can indeed make delivery faster; for example, adjusting the focus of R&D investment to match the business direction can indeed make the delivered software functions more in line with market expectations. But in essence, these measures are to optimize capacity allocation under the condition of constant capacity. If the production capacity itself is at a low level, no matter how the allocation is optimized, the improvement effect may be limited. Therefore, the improvement of human efficiency is one of the important means to improve delivery efficiency.
On the other hand, the measurement of human effectiveness has been controversial because it often deviates from the strong management orientation and is "anti-human".
For managers, especially those who are not so technically savvy, indicators such as working hours, job saturation (duration of executing tasks/total working hours), and number of lines of code are easier to understand, so they are often used to measure the progress of R&D. Human effect. These indicators seem to provide managers with a sense of security that "the wages are not paid in vain if the employees are supervised.
But software development is mental work after all. Developers are not machines that produce code, and it is impossible to run at full speed from morning to night every day. This leads to a painful, lose-lose game between developers and managers: developers either try to work around excess, or hustle and bustle under high pressure, become tired, numb and uncreative, and some members leave ; Managers may get their wish and see the increase in human efficiency indicators, only to find that this number is not necessarily related to the real efficiency improvement, and may still be negatively correlated.
No matter how much you love your work, you can only deliver bullshit if you keep turning the axis for too long
R&D human efficiency measurement is so embarrassing, behind it is the measurement design and use that often go wrong. This is why Smayi hopes to provide a more reliable and positive human effect Kanban.
1. Human efficiency measurement, first choose the right indicator
Delivery efficiency focuses on describing the end-to-end delivery performance, and the flow coordination within and between business, product, R&D, and testing links will all be affected. Human efficiency measurement focuses on the internal evaluation of the delivery capabilities of the R&D team, and R&D leaders need indicators that are only related to the R&D process.
As mentioned earlier, the common working hours and work saturation indicators mostly regard developers as resources that need to be operated all the time, rather than creative people, so they are widely criticized; while the number of lines of code indicators is likely to mislead Developers type more blank lines and write more unnecessary complex functions to create data, which leads to a sharp decline in code readability and maintainability, and essentially worsens R&D efficiency.
Smayi chooses the code equivalent per capita and transaction throughput per capita as the North Star indicators to represent the human efficiency level of the project team.
- The code equivalent is the same as the number of lines of code based on the workload index of the code, but it excludes noise interference such as code style and line break habits, and adjusts the weight of changes such as moving, pasting, and data modification, so it is more important and creative. work.
- Transaction throughput is a task-based workload indicator that can better correlate with project delivery progress, but may be affected by varying transaction granularity.
Therefore, the use of the two indicators at the same time can reliably and concisely illustrate the per capita development efficiency of each project, timely dig out internal best practices, or timely discover projects that are not in good condition, and then go to other charts to further understand the cause of the problem.
Four-quadrant diagram of project human effect
If you need to understand the specific information of a project's human efficiency, Smoyi supports drill-down analysis, presents the project's human efficiency trend, and automatically identifies potential abnormal points that are high or low. If the number of contributors fluctuates frequently, you may need to focus on developer focus, which we will cover in Part III.
On this basis, SMAY also includes the working hours index into the analysis. But working hours do not represent any output or workload, but the resource input of the R&D team and developers. By cross-analyzing the code equivalent, transaction throughput and man-hours, the production-to-production ratio within the R&D team can be quantified. Such metrics also help developers focus more on delivering results, rather than scrambling for hours. It should be noted that the man-hour-to-production ratio of different functional teams and different types of projects may vary greatly, and horizontal comparisons without screening may be inappropriate.
2. Refer to the industry baseline and objectively evaluate the level of human efficiency
The two indicators of code equivalent and transaction throughput quantify project human efficiency, but for the R&D team, there is a threshold for understanding the numbers: what do these numbers represent? The four-quadrant diagram shows that the human efficiency of a certain project is in the upper reaches of the company, so how does it compare with the industry?
According to the project language and team size attributes, Smayi can automatically match similar projects in the industry, provide a reference baseline for the interpretation of human efficiency data, help the team objectively understand the current level of human efficiency, and reasonably formulate efficiency improvement goals.
But here is also a reminder: the development stage of the project, business attributes, etc. will also affect human efficiency. For example, projects in the mature stage may have lower human efficiency than projects in the initial stage. On the one hand, there are fewer tasks than the latter, and on the other hand, the "historical burden" is also heavier, so changes need to be more cautious. Therefore, when judging the human efficiency of the project, it is still combined with the actual needs of the project for analysis.
3. In-depth analysis of project contribution distribution and concentration
Following the previous example, when the project reached maturity and the human efficiency declined, the leaders began to think: Does this project not require so many people to participate? Can part of the R&D manpower be allocated to other projects? After all, R&D labor costs are so expensive, so it is natural not to want waste caused by idling.
Today's division of labor: 90% of the project members wait for 10% of the members to complete the task
At this time, more detailed project human efficiency analysis is needed.
First of all, you can judge how many developers are working as the main force of the project through the project contribution balance chart. The definition of contribution balance is the proportion of developers who contribute 80% of the workload. If the balance is low, most of the project's manpower may be in auxiliary roles, and if it is transferred to a new project, there will not be too much work to be handed over.
Then, we can drill down to a certain project, continue to verify whether the balance is low, and use the output distribution Pareto chart to judge whether the work is gradually concentrated on a few core developers and who is the core developer.
So, are non-core developers still involved in other projects, or are they in an idle state? Human focus indicators can help us understand intuitively.
If many non-core developers are only focusing on this project, but the code output and transaction throughput are not high, it may be in an idle state. If many non-core developers are developing other projects at the same time, you need to combine the relationship between the old and new projects to judge whether it is reasonable for developers to participate in multiple projects at the same time; if the relationship between the old and new projects is not big, you can consider helping developers handover The remaining work is completely transferred to the new project to reduce the waste caused by frequent context switching.
Another situation is that the project has serious overtime but frequent delays, and the contributions are highly concentrated on a few core developers. In this case, you can combine the details of the output distribution and the concentration data to identify whether the project is really short of manpower, and other project personnel need to be frequently deployed for support; or the tasks are too coupled, the core developers are overloaded, and other members cannot help. or the structure of project personnel is not appropriate, resulting in some personnel having no tasks to do.
What needs to be reminded is that data analysis is more of an objective measurement, providing suggestions, excluding some possibilities, and guiding the drill-down layer by layer. It is often difficult to directly derive action items by itself. In the process of troubleshooting project human efficiency problems, review and discussion involving developers is essential.
We can understand the contribution balance and manpower concentration as health indicators of human efficiency: continuous overloading, over-concentration of contributions, and members investing in multiple unrelated projects at the same time are unhealthy. In an unhealthy situation, the human efficiency may still be high, but it is likely to be unsustainable (such as the team working overtime and exhausted) or the risk is huge (such as the departure of core members).
Summarize
Project human efficiency measures the R&D output within R&D. Although these outputs are not directly equivalent to the value felt by the business side and end users, it represents the bandwidth of the R&D department to support value delivery. In the improvement with the ultimate goal of improving delivery efficiency, improving R&D human efficiency is one of the essential paths. The embarrassment of human effectiveness measurement often stems from the confusion of path and purpose.
On the basis of clarifying the concept, carefully select the measurement index with positive guiding effect, interpret it under the appropriate reference system, pay attention to the health degree while paying attention to the figure of human efficiency, and drill down to the key single point in time, through the case Review the review to check the factors affecting human efficiency. Such a method of measurement and interpretation can help the R&D team avoid falling into the trap of numbers, but to discover and ask real questions.
After talking about delivery efficiency and human efficiency, we will talk about project quality control in the next article. If you are interested, welcome to visit the official website and apply for a free trial .