为了确保团队开发的产品能够符合市场需求，文章探讨了如何避免开发错误产品的方法。文中提到，仅仅依靠敏捷开发流程并不足以确保产品的市场成功，还需要采取措施验证产品的市场需求。文章强调了产品负责人角色的重要性，但也指出了依赖单一产品负责人可能导致的问题。
开发和交付用户不需要的产品，从而没有任何市场，这种代价是昂贵的。敏捷可以帮助你有效地开发产品，但你必须知道开发什么产品。你怎么知道客户需要什么样的产品呢？\u0026#xD;\n
David Hussman在博客中发表了你经常犯错吗，讨论了开发产品的不确定性。\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n你怎么知道你开发的产品是对的？你如何决定你的下一个最好的投资是什么？以及如何验证你的选择？（……）当团队拼搏努力顺利交付产品的时候，什么让你确定，什么让你不确定，这些是团队需要思考和学习的地方。
完成定义（Definition of Done）可以帮助团队检测软件是否可以准备交付，但它会给出虚假的确定性，David做了如下解释：\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n不幸的是，产品只有在投入使用的时候才算完成。通过观察自然状态下的用户，那些产品负责人经常告诉团队他们确定什么。“我确定人们需要……”其实并不是人们真正需要的。这可能就是某人的傲慢自负或者害怕自己不是个好的产品负责人（Product Owner），而这就是问题。也可能是因为产品的想法是好的，但市场变了。当这种事情发生的时候，如果你想少开发错误的产品（这使你以小代价学到更多经验），收起傲慢并拥抱现实则是你最好的利器。
在一篇名为在敏捷世界里开发产品的问题博客中，Paul Young从产品管理的角度探索了敏捷的一些问题。敏捷看重从客户那里得到反馈，但你得到的反馈不会一直告诉你，你研发的产品是否是市场需要的。\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n在我的经历中，实际上很多团队会聘用四到五个客户，他们愿意提供一定层面的及时反馈，然后给固定的这几个人发布其他的版本甚至更多的版本。\u0026#xD;\n
向固定的客户群寻求反馈时就有了两方面的问题。首先，那些四到五个客户真正代表你的整体市场吗？或者，他们是不是细分市场的“20%干扰部分”？在我的经历中，那些愿意定期参加会议，每两周提供反馈的客户并不是大众用户的典型代表，他们代表的是高级用户和专家。\u0026#xD;\n
其次，客户不是傻瓜。很快那四五个客户会发现他们区区几个人却对产品方向有重大影响，并意识到他们的反馈从本质上把你们变成了私人定制店，产品就是为了满足他们个别的需求。同样，这也不是市场驱动，这是客户驱动。
Paul描述的另外一个问题是产品经理这个角色的实际工作阻碍了组织从市场驱动的角度研发产品。\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n不幸的是，产品负责人的角色要到处找人，要讲究策略，他需要花很多时间与研发团队进行日常的沟通，如每日站立会议、迭代计划会议和回顾会议。然而，让敏捷团队有效运转并没有错。我看到一些团队非常沉迷于“让敏捷工作”，于是他们开始牺牲产品管理真正需要做的事情——花更多的时间做市场调研。
Paul警告我们，如果过于专注于敏捷实践和敏捷套路会造成开发错误的产品：\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n敏捷的前途在于帮助我们快速研发（或干其他事），但却未提及我们在开始是否做了正确的事情。这是产品经理的角色需要做到的。我看到敏捷团队经常热衷于敏捷的那些手段，从而忘记了如果你们研发的东西没人要，即使成为世界上最高效的公司也没有任何意义。
Dr.Dobb’s网站上发表了名为Scrum 关于产品负责人的错误观点 的一篇博客。在博文中，Allen Holub讨论了从现场客户获得市场需求和靠产品负责人决定市场需求的区别。\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\nScrum中很多东西让我感觉不舒服，其中的一个是关于产品负责人（PO）的观点，更准确来说，我不舒服的是他们不使用现场客户。他们认为典型的产品负责人就是客户代理、市场部门和产品开发部门代表的混合体。产品负责人负责产品，意思就是说他要做决定，决定产品内容，用户故事的商业价值等等。\u0026#xD;\n
Scrum的很多理念源自于极限编程（XP），而极限编程要求在团队中有实实在在的客户。所以我很怀疑他们关于产品负责人的观点从哪里来的，并且对于它带来的伤害深感沮丧。
Allen主张，让产品负责人代替现场客户会导致他们无法充分了解到底需要开发什么样的产品。\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n因为产品负责人不是产品的最终用户，他或她可能不知道产品设计问题的答案。你是在开发你们猜想的产品而不是真实的产品。当产品负责人靠猜时，你们就在实现错误的产品。如果产品负责人花了一天或更多的时间才找到答案，你们就损失了一天的工作（如果已经在错误的猜想上开发，你们不得不回退昨天做过的东西，这样你们会损失更多）。其实你们有时间在团队中安排一个客户。当产品负责人成为客户代理时，开发错误产品的几率就高多了，这个错误甚至能整垮公司。
Joel Amoussou写了一篇博客，名叫建立业务可持续性，他阐述了精益创业（Lean Startup）作为敏捷的补充，来提高对开发产品的认识。敏捷可以帮助团队成功地交付软件产品，但是单纯的形式上的敏捷方法不能得到最好的结果。就像Joel解释的：\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n（……）你拥有最好的软件工程师，开发出设计出色、测试充分的软件，并且能及时交付，不超预算，但它不一定会转化为市场上的成功、业务的增长和可持续性。我们漏掉了什么？如何确保敏捷研发的产品是用户想买的？我们怎么知道每一个迭代周期辛辛苦苦开发的那些功能和软件是用户需要的，是他们肯付钱，并会使用的？
敏捷项目失败的一个原因是他们开发了错误的产品。\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n问题是在大多数情况下，最终签支票或刷信用卡为产品买单的，既不是产品负责人也不是业务用户。当产品将要上市或者大规模上市后就是这个情况。对企业来说实现错误的设计并开发错误的产品代价很高。这会导致研发团队设计和开发的功能只是从未被验证的假想和猜测（这些猜测是所谓有经验的专家和产品空想家提出的）。因此很多敏捷项目变成了重大的失败试验也就毫不奇怪了。
精益创业的原则能够帮助我们提高相关知识，开发出客户所需要的产品。\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n精益创业方法是创建最小可行产品（MVPs），尽早验证并且经常与该产品未来的客户沟通。通过快速开发原型或者通过持续交付（Continuous Delivery）增量地发布产品新功能，可以开发出最小可行产品，同时还要高效利用云计算的能力，例如平台即服务（Platform As a Service（PaaS））来保持精益。验证最小可行产品需要团队（包括软件研发人员）尽可能走出办公室与客户面对面沟通，得到最直接的反馈或验证。也可以通过分析的方法来验证最小可行产品，例如AB测试或最终用户可用性测试。一些可操作的度量方法例如系统可用性量表（System Usability Scale （SUS）），这些数据应该在自动防故障（fail-safe）试验中进行收集并作后续分析。
查看原文链接：http://www.infoq.com/news/2014/07/building-right-product
\u0026#xD;\n感谢曹知渊对本文的审校。
\u0026#xD;\n给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。
扫一扫
2340
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
