Abstract:Standard the mainstream products in the market, update the difference features, so that the products follow the market changes.
This article is from Huawei Cloud Community, “How to reduce customer doubts about deliverables after the project goes live”, the original author: Agile Little Wisdom.
background
Background description
Early years ago, the software industry was just emerging. At that time, the software products had simple functions and single uses. The software research and development methods also followed the step-by-step development process of “plan –> demand analysis –> design –> coding –> testing –> operation and maintenance”, and the final products could basically meet the needs of customers. This approach is still used by many companies today, but unlike in the past, customers are increasingly questioning project deliverability.
One company asked a similar question: “What can project management do to prevent or reduce delivery problems caused by customer skepticism when the project goes live?” During the communication, we learned that the company was using the traditional waterfall model for research and development, and we also learned what the customer’s main questions were.
Question describe
There are generally three aspects that the customer questions. On the one hand, the deliverables are not consistent with the contract requirements: Customers think clearly said the contract is A, but the function of the product to be B, such as is located in the northwest of customers eat dumplings, want to dip in vinegar, signed A contract for the company to provide “dumpling dip”, the order is the northeast person, according to “dip” developed A bottle of soy sauce, so customers think themselves clear enough, mistakes due to functional development is the company’s internal management; On the other hand, the product is developed according to the demand, but the customer has not received the information about the product or the progress of the research and development team in the whole process of research and development, which leads to the anxiety of the customer for the project, and thus raises questions about the product. On the other hand, some products are developed correctly according to requirements and report the progress to customers regularly. When they are deliverable, customers think that the functions are not enough and they have no competitiveness in the current market, just like the current e-commerce companies do not support mobile payment. Such doubts are a headache for the company.
Are you experiencing the same problem? How to reduce customer skepticism about deliverables?
Problem analysis
The questions mentioned above can be summarized as follows: the two sides do not have the same understanding of the requirements, the product function planning is not updated with market changes, and the lack of communication leads to the anxiety of customers who do not know the situation. Let’s speculate on the reasons for these doubts.
The two sides have different understandings of the requirements
After the requirements are established, they may not be further clarified, resulting in the developers’ misunderstanding and developing products that deviate from their expectations. Or if the customer wants to say A, but because of the problem with their presentation, the requirement is described as B, then A satisfactory deliverable will not be developed.
Worse still, customers come in with only a vague idea of what they’re going to do, and the planned product is left to chance to satisfy them.
Inadequate communication and clients’ anxiety due to lack of understanding
Let’s imagine a scenario: Zhang bought a mobile phone on the Internet want to girlfriend as a birthday gift, birthday is coming soon, now show the shipping goods, but can’t see the details of the logistics information, customer service also not told zhang goods now is what circumstance, in it’s a little, you don’t worry, even if the goods arrive on time, also can because of the logistics process is not visible and difficult to obtain high praise.
In the actual production, the same is true. After the customer places the order, the R&D team keeps working hard and does not communicate with the customer about the progress of the project. As a result, the customer will become anxious because he does not know the progress of the project and eventually question the deliverable.
Product function planning is not updated with market changes
As the saying goes, change is better than plan. The traditional R & D model is driven by plan, and the market is changing rapidly. If you want to occupy the market, demand changes are inevitable. A plan is like a map. A road will undergo a lot of changes after the changes of the world. It may take a long time to find the shop marked on the map two years ago but it is impossible to find the place. Similarly, looking at a product based on a plan made two years ago in the context of its delivery creates a sense of “no matter what the Han Dynasty is, Wei and Jin dynasties”, and customers inevitably question the product.
The measures
The traditional R&D model of delivery is similar to the flow process: the plan and requirements are done, the development is carried out according to the plan, and then it is delivered for acceptance. In this R&D model, customer engagement is U-shaped: customers are more involved in the planning phase and the requirements definition phase; After the project entered the research and development stage, customer participation dropped sharply or even did not participate; In the final delivery phase, the customer participates in the acceptance work. The decrease of customer participation in the research and development stage can easily lead to poor communication between the two sides on the product. For example, the demand is misunderstood and no one guides it. New features come to the market, product changes don’t come to mind, and all of these “inadequacies” translate into questions about the delivery. To avoid this, you can try to make an Agile transition, which can greatly reduce customer skepticism about the delivery.
Agile values are: “Individuals and interactions over processes and tools; Working software is more important than well-organized documentation; Customer cooperation is more important than contract negotiation; Responding to change is more important than following a plan, and while the right is important, the left is more important.” Agile delivers in iterations, each of which does not last very long; At the same time, Agile focuses more on delivering value to the customer, and the customer (or customer representative) can participate and influence the whole project throughout its life cycle. The figure below compares traditional and agile development customer engagement across different lifecycles.
In what specific ways can Agile reduce customer skepticism about deliverables?
Analyze and document requirements using standard user story methods to ensure mutual understanding
The traditional R & D model is plan-oriented and uses detailed documents such as outline design and detailed design record requirements. This method has its advantages, but it also has obvious disadvantages: firstly, it takes a long time to make the plan; secondly, the requirement description is too productized and difficult to interpret.
Agile development is value oriented. Unlike the traditional development model of documentation, agile development uses user stories to document requirements: A user story describes the requirements from the user’s point of view and gives the value that the user expects to achieve, making it easier for developers to develop the features that the customer really wants (see “User Story equals Requirements” for more details — you must not have written a user story well).
For example, a user story is used to describe a demand: a customer wants a bottle of dipping sauce for dumplings. The user story can be written: “As a Xiao Wang who grew up in Shanxi, I want a bottle of dipping sauce for dumplings to make them more delicious.” According to the user story, the customer is “born and raised in Shanxi”, so the dumpling dip may be aged vinegar rather than soy sauce, which is more accurate to deliver than “the customer wants a bottle of dip”.
Also, user stories are not written and set in stone. The “N (Negotiable)” principle in the “Invest” principle of user stories requires that stories be deliberable. When the developer does not understand the requirements in the user story, the problem can be thrown out and clarified by the product owner until both sides agree on the understanding of the requirements. Below is a user story written using DevCloud, along with a requirements analysis discussion.
In summary, the use of standard user stories to document requirements can solve the problem of inconsistent understanding of requirements, thus reducing customer skepticism about the delivery.
Communicate with customers on a regular or irregular basis through review meetings etc
There are many agile development methods, and Scrum is one of the most mainstream agile methods. There are four activities in Scrum: the Planning Meeting, the Daily Standby Meeting, the Review Meeting, and the Retrospective Meeting. Each activity helps the team to better practice Agile and deliver higher quality. The details of each activity are as follows:
As can be seen from the table, planning meetings, daily station meetings, and review meetings are all carried out around the product. Review meetings are held at the end of each iteration, and regularly inviting customers to attend review meetings is the most direct and effective way to communicate with customers: At the meeting, the team will demonstrate the iteration deliverables to the customer, through which the customer will know which functions the product has, which functions have not been completed, and which functions are deviated from the ideal. For deviations, the team can communicate with the development team and make improvements in subsequent iterations.
If the client is too busy or too busy to attend each review meeting, then occasionally invite the client to attend the daily standing meeting. The standing meeting takes place every morning and the client can attend at his/her leisure or interest. Daily station meetings are not necessarily conducted with the customer, but through the station meetings the customer can see a small portion of the deliverables and the status of the team, reducing anxiety. If the customer does not attend the meeting, the product owner can sort out the minutes of the review meeting after the end of the review meeting, and inform the customer through visit, telephone, email and other forms, so that the customer can understand the current project progress, reduce anxiety, and thus reduce the doubt on the deliverables.
Standard the mainstream products in the market, update the difference features, so that the products follow the market changes
In addition to clarifying requirements and enhancing communication with customers, we can also lead customers to compare products with other mainstream products in the market, find out differences and update them, so as to reduce customers’ doubts. For example, the settlement function of an e-commerce product does not consider mobile payment in the plan, but only supports online banking payment. If the project is operated according to the traditional mode, the product will not support mobile payment when the final delivery, which will be very troublesome to use. If use Scrum projects, can be in the process of the project, or review the product payment functions, to the mainstream electric products, this time will find mobile payment is by far the most mainstream online payment, the product need to support mobile payment, so can be “settlement function support mobile payment” as a priority the new requirements to join the project, And negotiate with the product owner to complete this requirement in the next iteration or as soon as possible, so as to make the payment function of the product follow the changes of the market and increase the competitiveness of the product.
Refer to appendix
Kenneth S.Rubin: The essence of Scrum. Beijing: Tsinghua University Press
Scrum Guide
Click on the attention, the first time to understand Huawei cloud fresh technology ~