嘿，朋友们！
你是否听说过MVP？
如果你是爱好探索的人，你可能会好奇地问道：
“当然我知道，MVP不就是指‘最有价值产品’吗？”
但在这里，我们谈的不是那个MVP…
我们的追求不在于数量的最大化，而在于精益求精!
在这样一个背景下，MVP有了全新的诠释：
最小化可行产品
它的核心理念是迅速推出产品，然后细心倾听用户的反馈，包括直接和间接的反馈。通过这种方式，我们根据用户真正的需求和期望，不断开能和产品。
我们的目标是通过让用户直接告诉我们他们希望在我们的产品中增加哪些高级功能，从而减少产品管理和设计中的猜测成分。
通过这种方式，我们可以有效避免浪费时间和资源在那些人们不需要或不使用的功能上。
如何界定“最小”的范畴？
这是一个历来颇具争议的话题。相信我，它常常如此!
对于开发者来说，他们希望尽可能少地做，以减小工作量和风险。而产品所有者则希望添加更多他们认为用户所需的功能。
销售和支持部门则倾向于发布一个“完整”的产品，而非看似未完成的产品。但作为测试人员，我们深知平衡的重要性。
质量呢？这正是我们可以提供宝贵意见的地方。我们的目标是发布足够的功能以带给用户价值，同时为未来添加更多功能留下空间。
作为内部的支持者，我们理解使用模式和系统功能，因此我们拥有帮助团队做出这些复杂决策所需的知识。
准备捕捉用户的声音
那么，你已与团队共同定义了最小可行产品并成功发布它。
难道这样就大功告成了？
错误！
整个MVP的概念旨在使团队能够收集关于如何进一步开发产品的反馈。你需要确保产品“准备好”以收集反馈，同时团队也已做好准备去捕捉它。
记住，反馈的形式多种多样。最直接和简单的反馈是看有多少人正在使用新功能。但也要考虑到那些偶尔使用该功能与将其作为工作必需品的人之间的差异。
通常情况下，两者我们都需要兼顾。
当要求客户直接分享他们的想法时，反馈是直接的；而当通过分析遥测和日志来了解他们如何与你的应用互动时，反馈则是间接的。
准备倾听用户的声音
记住一点，客户不是为你的工作而忙碌的。当请求他们对新功能提供反馈时，不要期望他们会立即回复你的邮件。
有些用户会非常乐意分享他们的想法和评论，甚至给出建议来帮助改善产品。然而大多数用户可能只会忽略你的邮件请求——他们有自己的工作任务需要完成。
为了让用户更愿意分享他们的反馈，需要让他们明白为什么他们的输入是如此重要。解释这是请求的最佳时机，因为这将作为功能改进的一部分被采纳。在之后才向他们了解需求和需求可能已经晚了。
尽量使请求个性化，这样用户就会更明白为何是他们被选中来提供反馈而非其他用户。
拓宽质量的边界以增强客户幸福感
这个话题是我在最近讨论中涉及的更大主题的一个例子：如何拓展我们的工作领域以更好地确保客户的幸福感。
我希望现在你们能明白，质量不仅仅是关于应用程序没有bug或响应时间快慢的问题。这些都是用户体验的重要组成部分，但并非全部。
通过开发出具有用户所需功能的特性，我们正在提高产品的质量同时提升客户对产品的幸福感和满意度。