Introduction:This paper will discuss a methodology that has not yet been practiced, that is, whether the “growth hacker” theory can be applied to the improvement of R & D process, so as to achieve more reliable directional efficiency optimization?
As a conventional means of recording user behavior, buried point has gone through the spring and Autumn period with the development of front-end technology. However, it was not until the emergence of “growth hacker” series theory that buried point analysis really became rich in connotation and rules to follow.
Similar to the “growth” in the product field, “improving efficiency” has always been the main theme of the R & D field. In the process of software development, with the development of the project, many behavior data related to code base, pipeline and task will be recorded in the form of events. Although the source of these data is not the same as the page buried point, there are many analogies in the use of these data. However, when product managers start to adjust their marketing strategies by using real-time data, TL and PM of R & D team still can only use the post analysis method dominated by statistical method and summary index to review and evaluate team effectiveness after each version and iteration, And talked about how to shorten the iteration period from one month to two weeks to get “faster feedback”.
This paper will discuss a methodology that has not yet been practiced, that is, whether the “growth hacker” theory can be applied to the improvement of R & D process, so as to achieve more reliable directional efficiency optimization?
1、 Polaris indicators of R & D team
Before setting growth goals, the team often needs to determine a “Polaris indicator” that can reflect the success of the team and is easy to observe, such as sales, signing rate, number of active users, etc. For the R & D team, the key indicators are demand completion time, function defect rate, user satisfaction and so on. Take “requirement completion time” as an example, which is a relatively objective indicator and directly reflects the development team’s response speed to user requirements, that is, the average time required for a requirement to go through from proposal to final delivery.
Next, we define a relatively ideal requirement delivery process and express it with reference to the “transformation funnel” structure of product flow analysis
Accordingly, by adding all the requirements in the project, you can draw a “requirement delivery path diagram” (for example, the actual phase division should be more abundant)
Although it is a little rough, we can really recover a lot of information lost in the charts that only count the result data. For example, for the same two requirements that took 10 days to complete, one took 7 days to develop, the other took only 1 day to develop, and the rest of the time was spent waiting for testing. Their differences can be clearly distinguished on the delivery path diagram.
Other benefits include:
- Even if a need has not been finally delivered, but is blocked in a certain link, or rework occurs, it can be significantly displayed on the path diagram in the form of abnormal traffic at the first time, thus causing the attention of TL and PM in time.
- It can not only intuitively see the overall delivery progress of each stage, but also view each node flowing through from the perspective of a single requirement, and find other similar requirements, so as to analyze their common characteristics.
- When it is used for post analysis, it can be used to trace back the delivery results, for example, to check the proportion of the demand not delivered on time flowing through the previous nodes.
Based on the above references, we can draw the “efficiency hacker” model (aarrr model corresponding to growth hacker) which transforms R & D demand value
With Polaris indicators and visual path, the next key is to use data to guide performance improvement.
2、 AB test on time axis
Not all customers are worth a lot of effort to maintain, and the growth team always gives priority to the retention of high-value customers. In the process of efficiency improvement, we should first identify the differences, and then teach students in accordance with their aptitude.
Just like the “RFM model” customer classification method commonly used by growth teams, for R & D needs, we can also classify the demand sets that can adopt different response measures through the orthogonal dimensions related to effectiveness, such as “riw model”:
- Recent activity of a (activity) demand (related event frequency)
- I (importance) the importance of requirements (priority, time remaining from plan completion)
- W (workload) the amount of development effort (such as the number of code modification lines) associated with the requirements
The three dimensions can divide all samples into eight groups. This granularity is very suitable for delineation of key points, while avoiding too much information and excessive divergence. The above three groups of attributes are selected not only because they have high discrimination, but also because the observation values of these indicators are easy to obtain and can be updated with high frequency, so that abnormal samples can be found and corrected in time in the process of R & D.
Software R & D is a mental work based activity. The factors that affect R & D efficiency include but are not limited to the personal ability of developers, team atmosphere, company culture, project schedule pressure, tacit understanding among members, external communication cost, related process tools and so on. Most of them are subjective components that can not be simply measured by numerical method. In the past, when we talked about R & D efficiency improvement, we would focus on platform capability, R & D process, tool support and other “short course, quick effect” methods from the perspective of controllable technology, but the real world R & D efficiency improvement means are much richer. Technical engineering means can be used, such as improving the construction speed, simplifying the online process, and improving the release tools; Organizational culture can also be used, such as optimizing reward and punishment strategies, establishing advanced benchmarks, adjusting the human structure, improving employee welfare, strengthening skills training and so on. So which method is the most suitable for the R & D team?
In this regard, growth theory has long given the answer, no matter black and white cat, as long as you catch the mouse is a good cat: do an ab test.
Different from ab testing for product users, when conducting project R & D, AB testing can not be conducted directly with a single requirement as granularity (not convenient for project management). In contrast, team or iteration are more appropriate AB granularity. We are not unfamiliar with the specific AB method. For example, let two project teams adopt different efficiency improvement strategies to compare the effects, which is similar to “pilot” and “model room”. Or let the same team try some new efficiency improvement methods in different iterations, and then decide to keep or give up according to the effect. This is the “ab test on the timeline”.
Here, a new concept has been created. However, readers who are still sober will soon find that this is not a new idea. Iterative review and improvement meeting are just doing this! Not really. In the past, the analyzable data in iteration review were mainly iterative burn out diagram and requirement / defect accumulation diagram, which reflected the overall trend. The “overall mean” often covered up local problems, which could not meet the rigorous requirements of “ab test”. The above “requirement transformation path” and “riw distribution” can just make up for the details of the previous iteration process and provide guidance for the effectiveness improvement method.
3、 The limitation of the imported doctrine
In many aspects, there are similarities between the growth strategy through buried point analysis and the efficiency strategy through R & D event analysis
There are all four elements of R & D events, so any solution that can be buried can be used for R & D events. This is imported doctrine.
However, the growth focuses on a fixed group of users, seeking to stay new; Efficiency is faced with the ever-changing demand, the pursuit of on-time delivery. Because of their different analysis objects and objectives, there are still differences in essence
- Users will come back when they leave, which can be tracked continuously; When the requirements are completed, it’s over. Next time new requirements come in. This is also the reason why requirements are not suitable for ab test granularity.
- The higher the level of renewal and retention, the better. There is no upper limit; The efficiency of delivery cannot be overemphasized unilaterally, otherwise it will not be worth the loss to sacrifice quality and fatigue tactics in exchange for “efficiency improvement”.
- The page path is relatively fixed, for example, you must go through the single page before entering the payment page; The demand path is not necessarily, for example, a “development overdue” task may eventually be “delivered on time”.
In addition, the page click of buried point records is always real-time and accurate, while the demand status depends on manual update, so the actual operation may not be timely. Therefore, the collected event data often has time deviation, which is a long-standing problem of R & D data analysis. Fuller automation is a solution. For example, in the new collaborative product of Alibaba cloud cloud effect, R & D behavior can be associated with task update through rules (such as code submission triggering task start, pipeline release triggering task completion, etc.), which will greatly help to increase the accuracy of performance analysis.
Finally, even the model of reference, whether it is effective still needs to be proved by practice.
4、 Imagination and summary
Growth and efficiency, two seemingly unrelated themes, are linked by a brain hole.
Operate the technical team with product ideas, restore the R & D process with buried point data, and insight into key bottlenecks with transformation path. Efficiency hacking makes the project schedule more objective and the R & D process more transparent.
Copyright notice:The content of this article is spontaneously contributed by alicloud real name registered users, and the copyright belongs to the original author. The alicloud developer community does not own its copyright, nor does it bear the corresponding legal responsibility. For specific rules, please refer to the user service agreement of alicloud developer community and the guidelines for intellectual property protection of alicloud developer community. If you find any suspected plagiarism content in the community, fill in the infringement complaint form to report. Once verified, the community will immediately delete the suspected infringement content.