In march 2017, at the invitation of the head of the project management department of the smart marketing platform of the mobile business group, i began to support the crm team of the intelligent marketing platform. the intelligent marketing platform is the advertising team of alibaba entertainment and the main force monetization. the crm team is responsible for developing and maintaining crm systems. crm system serves sales and agents, stringing together business chains such as business opportunity management, customer development, contract management, risk control review, account management, and financial settlement. the quality and speed of delivery of crm systems directly affect the efficiency and experience of sales and agency service advertisers.
in early march, i interviewed the core members of the sales, product, development, testing, etc., and observed the team's weekly meetings, stand-up meetings, and requirements discussions. at that time, the team's goal was to deliver the framework contract function on march 25, and the main work revolved around the framework contract function. according to the interview content, the timeline of the development process of the framework contract project is sorted out as follows:
as can be seen from the figure, the project is basically promoted in accordance with the waterfall model, and the overall test is carried out after 2 months of development, and the one-time release is released after 1 month of testing. after more than 2 months of development, the business has the opportunity to try out the product and give feedback.
this project exposes the drawbacks of the waterfall model:
1. the collaboration mode of the baton brings information difference
under the waterfall model, business, product, and r&d rarely participate in discussions. requirements are like a baton passing from the business side to the product manager, and from the product manager to the r&d team. every time the information is transmitted, there is a loss, the business side, the r & d team gets most of the second-hand information; the product manager becomes the bottleneck of team communication, the business side and the r & d team directly discuss the problems that can be solved, after two or even multiple rounds of communication to reach a consensus; the business side and the r & d team lack mutual understanding, the r & d team does not understand the real business demands behind the needs, the business side does not understand the trade-offs behind the technical solution.
2. difficult to respond to changes
in waterfall mode, all requirements analysis and design work is done before development, assuming that requirements do not change and that the r&d process simply follows the initial project plan and scope. in real projects, changes are inevitable. even if you spend twice as much time reviewing requirements and developing a project plan, you can't foresee all the changes. it is also true that the organizational structure of the business side in the framework contract project has been adjusted, the mapping relationship between the customer url and the sales has changed, the original design cannot be compatible with this change, and the implemented functions need to be redesigned. zheng he mian said in "lean product development": "i hope to be able to set complete and correct requirements at the beginning, which is increasingly unlikely for software products, because users do not know or cannot say what they want." in fact, the exploration and understanding of requirements should be an ongoing process that requires constant feedback. ”
3. get user feedback very late
in the waterfall mode, all outputs are delivered at the end of the project, and the risks of the project are accumulated until the end, and there is no opportunity to test hypotheses and get real feedback during the project process. in the framework contract project, the business side only tried the product for the first time in early march, which was less than two weeks before the release time, and most of the problems in the feedback were not ready to be modified before the release. after the release at the end of march, the product features continued to iterate for several months before they reached the expectations of the business side.
THE CRM TEAM IS DEEPLY HURT, AND THE TEAM'S DEMANDS MAINLY INCLUDE:
1. business, product, r & d close collaboration, as a team for the common goal of efforts.
2. SHORTEN THE DEMAND DELIVERY TIME AND IMPROVE THE CRM SYSTEM IN LINE WITH BUSINESS NEEDS.
improve the program and implement it
combined with the team's demands and the actual situation of the crm team, after communicating with the business, product, research and development, and project management leaders of the intelligent marketing platform, the improvement plan was determined. the improvement plan focuses on two points:
1. Form one team to facilitate cross-departmental collaboration
One Team is composed of core members of business, product, and R&D, and later joined the operation students responsible for product landing.
One Team is responsible for developing quarterly product planning. In the past, each functional department organized quarterly planning separately, and the goals of business, product, and research and development may be biased, and it is easy to disagree on the priority of demand in the implementation process. After the establishment of One Team, the members worked together to develop a quarterly plan. Once the goals are aligned, the team's work revolves around quarterly planning, and it's easy to agree on the priorities of requirements. Take a look at the CRM KA example:
QUARTERLY PLANNING IMPLEMENTATION FOR Q1 FISCAL 2018
One Team holds biweekly meetings with 3 fixed topics:
- review user feedback for the previous iteration of published features;
- synchronize the progress of the current iteration;
- sort out the core requirements for the next iteration.
Through the One Team biweekly meeting, a demand feedback loop was strung together. Everyone is no longer limited to the division of departments and roles, quickly synchronize information, and quickly solve problems. In the past, the problem of user feedback may be solved in the inter-departmental layer by layer, and now at the biweekly meeting, everyone will discuss the plan and immediately schedule it to solve.
2. transition to an iterative model to shorten the delivery time of requirements
After deliberation among the members of one team, the more challenging bi-weekly iteration was chosen between the monthly iteration and the bi-weekly iteration.
there are two key practices in transitioning from waterfall mode to iterative mode: splitting requirements and establishing a rhythm.
splitting requirements is a prerequisite for small-step iterations, and we don't have a one-size-fits-all approach for teams that have just transitioned to bi-weekly iterations. before entering the r&d process, the requirements are best split into granularities that can be measured within 1 week for release in one iteration. if the requirements are really difficult to split, they can also be delivered across iterations. at the same time, we will pay attention to the development time of the demand to measure the granularity of the demand. it is expected that as the practice deepens, more and more requirements can be released in one iteration.
The requirements split adopts the user story map method: for a complex and large demand, the user journey is divided according to the problems that the user wants to solve in a specific scenario, and each release tries to deliver a complete user journey. MVP (Minimum Viable Product) is implemented in order from simple to complex to deliver the simplest user journey. On this basis, we continue to enrich and improve, and gradually realize additional functions and customized functions. The following is an example of a demand split, in which the "general product inquiry" and "ordinary product contract" constitute an MVP.
There is a common misconception about agile development, agile is fast, and the requirements are not clearly defined to rush to start. In fact, it often outweighs the costs. As Marco Behler puts it: Programmer productivity starts with "the right needs."
In order to reduce the rework and waste of the R&D process, the requirements must comply with the entry standard DoR (Definition of Ready) before entering the R&D, and the Quasi-Release Standard DoD (Definition of Done) before release. After the requirements are released, the product manager will observe the buried data, and the business and operations will collect user feedback. At the One Team meeting, everyone decides the next step of improvement and optimization based on user feedback.
Iteration activities are carried out rhythmically, and iteration can run in an orderly manner. After deliberating, the members of one team agreed to try the following rhythm:
As can be seen from the figure, the development test of this iteration is carried out concurrently with the requirements analysis of the next iteration, which can minimize the waiting in the research and development process. The cost is that some of the development and testing students have to invest some effort in sorting out the needs of the next iteration, such as assessing technical feasibility and clarifying acceptance criteria. Most of the requirements are sorted out at the One Team bi-weekly meeting, and if some problems to be identified are found at the bi-weekly meeting, they will be recorded and followed up by a special person.
on the first day of the iteration, the r&d team pulled the requirements that met the access criteria into the iteration according to the priority, and made preliminary design and estimation. make serious commitments based on estimates and develop an r&d plan:
as can be seen from the figure, in order to reduce risk and disperse pressure, the team tried to do a small batch of gradual testing. before the test, the students will design the test cases, and the students who develop the test will run through the p0 and p1 test cases. test students verify that basic features are available, and immediately invite product managers and business students to try them out so that experience issues can be identified as soon as possible. before the function is released, the business party accepts the version to be released, and the business acceptance can be released after it is passed.
while determining the rhythm, we made a clear agreement on the output, responsible person, and deadline of the iteration activity. everyone divides labor and collaborates, and the iteration quickly runs in an orderly manner:
to increase transparency, we use workflows to describe the flow of demand states:
track the status of your requirements with kanban:
Effect evaluation
1. The One Team mechanism facilitates cross-departmental collaboration
business, products, research and development have complained to each other, the business feels that the delivered functions are not the most needed, the urgently needed functions are not done, research and development feels that the hard-earned functions are not used very wronged, and the products are sandwiched between the two ends.
After the One Team mechanism is implemented, we comprehensively weigh the business value, technical risk, personnel situation, external dependence, input-output ratio and other related factors to determine the demand priority together. Even if there is initial disagreement, through open and honest discussion, the final conclusions can be recognized and actively promoted. At the CRM SME Biweekly Meeting, the product manager prepares some product optimization requirements in advance. The business side proposed that it is more necessary to see the data report at present. Everyone quickly reached a consensus that data reports are the highest priority, and product optimization needs are lower.
At the quarterly summary of the CRM product team, the product manager and business interface of CRM KA said: Since the establishment of the One Team mechanism, it has run through the big closed loop of feedback from the business requirements from the proposal to the launch, and the business, products, and research and development have been coordinated in an orderly manner, and the mechanism will continue to operate smoothly.
crm sme's business interface person mentioned in the email: "at present, the product work of small and medium-sized crm is advancing in a normal and orderly manner, and while the project is underway, it is also actively digesting the stock demand", and thanked the team for its efforts.
The technical leader of the intelligent marketing platform spoke highly of the One Team mechanism: "It not only improves the development efficiency of the team, but also improves the communication efficiency of the team."
In the continuous collaboration, The members of one team have increased trust and understanding, developed a better understanding of the business, and the business has become more considerate of research and development. Here are two specific examples:
2. bi-week iteration shortens the demand delivery time
All the requirements of the CRM team are tracked in Aone, the team updates the demand status at the station meeting, and the statistical chart generated according to the demand status flow can reflect the real situation.
the primary goal of the bi-week iteration is to shorten the time it takes for requirements to be delivered. in conjunction with this goal, we focus on 2 main indicators: development time and delivery time from development to release. the smaller the requirements are split, the shorter the development time, and the more suitable it is for iterative development. the shorter the delivery time, the better the adaptability of the r&d team. when the business needs it, the team is able to quickly realize the requirements and deliver them to the users.
the crm ka team began experimenting with bi-week iterations in mid-june, with the weekly moving average of development and delivery times as follows:
as can be seen from the figure, the development time has been shortened from 12 days to less than 6 days, indicating that the requirements have been split even smaller. delivery times are basically within 20 days, with the only exception being the week from july 31 to august 6. the reason is that this part of the function should be launched synchronously with the related party, and the crm ka team will wait two weeks after completing the development test before jointly tuning with the related party.
it is worth mentioning that in the process of transitioning to bi-weekly iteration, the crm team has maintained a high quality level, whether it is the quality of testing, online quality or defect repair speed, it has reached the leading level of the group.
deliver capabilities with shorter delivery times and more frequently, enabling you to quickly validate hypotheses, deliver value, and respond to change. taking the urgently needed data reports of the business side as an example, the crm team delivered 55 business indicators in batches according to priority, ensuring that some reports were delivered every two weeks, shortening the waiting time of the business side, and quickly adjusting and optimizing the feedback of the business side, which won the high recognition of the business side.
meet the challenge
In the case of limited manpower, how to quickly meet the needs of business development at the fastest speed and lowest cost is the biggest challenge for CRM teams in the coming period. The practice of One Team and bi-week iteration has laid the foundation for team collaboration, small steps, and continuous improvement, and further deepening agile practices in the future can achieve greater benefits.
1. focus on continuous and rapid delivery of business value
Rather than delivering more functionality, we should focus on how much value we bring to the business. from the many needs, how to find and extract the most valuable business needs? among the various solutions, how to find the best iterative route to solve the business pain points first? by taking the 80/20 principle to the extreme, we have the opportunity to win more opportunities for business development with a small and broader approach.
To do this, we need to be good at trade-offs, and more importantly than deciding what to do, it is more important to decide what not to do. compared with the one-time delivery of a large and complete solution, it is more reasonable to first implement a small and light solution to meet the core needs of core users, quickly deliver to users, and iteratively optimize based on real user feedback.
2. increase productivity with technical means
compared with a one-time release at the end of the project, releasing every two weeks does bring additional release costs, such as the cost of regression testing and the cost of deploying online. to gain the flexibility that comes with bi-weekly iterations, we needed to find ways to keep reducing the cost of publishing until it became so easy that we could ignore the cost of publishing. this is exactly what agile engineering practices like continuous integration and continuous deployment solve.
The continuous deployment pipeline automates the entire process from code submission to unit testing, static scanning, compilation, packaging, deployment, testing, and release. Handing over all the repetitive work to the machine and freeing engineers to do more creative work is the fundamental way to improve efficiency.
The CRM testing team has implemented some automated testing, and there are also Jenkins jobs that are automatically compiled and packaged, and it is possible to achieve continuous integration and even continuous deployment in one step. The smart marketing platform test team is already working in this direction, which is very valuable work. If the R&D students also join in, everyone will work together and I believe that there will be results soon.
Summary
Through the One Team mechanism, trust and understanding between business, product, and R&D are enhanced, and collaboration is smoother.
By splitting the requirements and rhythmic short iterations, the crm team transitioned from the waterfall development model to the iterative development model relatively smoothly. the release frequency has changed from once a few months to several times in two weeks, basically within 6 days of testing, and less than 20 days of release. what's even more gratifying is that during the transformation process, the team maintained high quality.
The r&d team continues to quickly deliver the functions that the business needs, which is highly recognized by the business team.
No comments:
Post a Comment