如何评判产品特性的“价值”-InfoQ

每次谈到敏捷开发里特性或故事的优先级排序，“价值”这个词就会被提出来；到底这个“价值”是什么？不同领域对价值的判断很不一样，面向外部用户的产品和企业内部系统也有所差别，但概括起来还是有章可循。以下所提到“产品”皆泛指以上两种类型的软件系统。

先澄清几个基本问题。

首先，价值不是考虑优先级的唯一因素，还要综合考虑风险和成本；有些项目容易忽略这一点，有高风险（比如技术风险）的工作太晚开始导致失败，以至于对敏捷的方法产生怀疑。通常价值应该是三要素中权重最高的一个：我们首先根据价值进行 Backlog 排序后，再基于风险和成本对其微调。为什么？简单地说，敏捷交付是业务驱动的交付模式，而价值是反应一个需求对业务的贡献。但这一点不要成为教条，在产品的某些阶段，可能其它因素，比如规避风险，会变得比交付价值更重要。这样就产生了优先级排序的两种基本策略：价值驱动，和风险驱动。

其次，价值的判断不应该是某一个人的专权。应该是团队共同参与对价值进行分析排序；但这项关键工作要有一个 owner，这就是 Product Owner，或叫产品经理。

对价值的分析过程可以用下面这个图来展现：

组织战略方向

从中学起课本里就会出现一些当时还不甚理解的哲学词汇，比如“价值观”；现在经常看到媒体议论所谓“普世价值”；可以说“价值”是指我们面对分歧和冲突时用以评判取舍的标准。个体价值观必然受到社会所普遍认同的价值评判标准影响，这个标准可能是社会自然形成的，也可能是被强加或灌输的。那么对一个软件产品呢？它身处的“社会”最直接就是创造它的组织，大到整个企业，机构，小到一个部门，它的价值判断首先会受组织制定的战略方向影响。

一个产品符合或有助于实现组织的战略目标，这是产品价值观的源头。就如同代码应当为业务服务，对组织来说，软件产品理应为组织的战略目标服务。微信在成功度过了最初的市场探索期后，绝大多数特性开始为腾讯所要建立的生态系统服务。产品团队首先需要认清该产品在组织战略实现中所承担的角色，这一点至关重要。这个角色可能是探索新商业模式，也可能是扩大用户基础；可能是一个生态系统的利润中心，也可能是为其它产品提供可靠的基础设施；可能是引领组织业务或技术转型，也可能是支持商业决策，等等；只有正确把握了这一点，才能更合理地判断什么样的特性应当优先地，投入更多资源去实现。

不久前我接触了这样一个产品，在没有清楚的产品定位时匆忙启动了项目投入大量人力去开发一些时髦的功能，最后发现自己和另一个企业战略产品定位重复；在交付过程中团队对该做什么不做什么，先做什么后做什么的判断常常感觉矛盾和彷徨，产生了很大浪费。也许有些时候，开始一个项目就仅仅源于某人一句话，甚或有绩效目标或政治因素夹杂其中… 交付团队可能没有能力去评判组织战略和产品角色定位，更别说可能因此否定一些决策。所以这个层面的价值标准需要放到组织层级来统筹：对于商业产品，需要考虑的是商业模式，战略规划；对于企业应用，需要考虑的是整体企业架构和演进方向；我们应该以这种方式在跨部门，投资组合层面为每个产品明确各自的定位。

同时我们也必须意识到组织战略不是一成不变的，企业在市场竞争中总在不断地转型。产品经理应当随时关注这样的动向，持续成为支持组织目标实现的推动力，甚至通过产品创新或业务创新来引领转型；组织转型过程中会产生一批新产品新系统，而不符合战略方向的就该淘汰。我们能看到那些开放而着眼未来的企业战略产生多样化，创新，活跃的产品；而封闭并仅着眼当下成熟模式的战略产生相对僵化的产品形态，缺乏创造性的修修补补。

产品规划和阶段性目标

产品规划至关重要！一个产品的规划基于现状，瞄准产品的愿景，商业模式，或整合的业务，制定出阶段性要达成的目标。对于商业产品这一点毋庸置疑，然而对企业 IT 系统很多人却没意识到这一点的重要性。在接触的很多项目里，团队完全被动地听业务人员或者领导提要求；然而业务来自多个方面，每个业务人员都将解决自己眼前问题视为非常重要；领导拍脑袋提出的要求有时打乱了产品原有计划，却不见得合理；这些需求缺少整合，甚至彼此矛盾，导致产品反复改来改去；团队看似一直都深陷进度压力，却总得不到用户或业务的认可。这样被动的需求接收模式让产品团队怎么进行价值判断？

因此我们应该换一个方式。首先包括 PO、业务人员在内的产品团队以及其它相关利益者需要共同理清产品的愿景。也就是要弄清楚为什么开发这个应用，这个系统？我们对它的期望是什么？相比旧的系统，或其他竞争对手，这个产品能带来的改进或差异化竞争力在哪儿？什么是这个产品主要的卖点？是不是 PO，团队和各相关利益者都理解并认可该愿景？我们对该产品的愿景是不是与组织战略方向一致？

明确了愿景后，就要对如何达成这个愿景进行规划，产生演进路线图。任何产品都有一个从探索到消亡的过程，也就是都遵循产品生命周期法则。比如一个在线教育应用，其业务模式还没有得到验证，当前的目标是在 6 个月的时间里发展一定用户基础并获得反馈。在这个阶段，一个吸引人的用户推荐系统是不是有助于实现目标？一个健壮的会员管理功能呢？一个完善的收费会员体系呢？显然有不同的答案。产品生命周期决定了在不同的阶段产品应有不同的策略，从探索期，发展期，成熟期，直到衰退期，“价值”的内涵是在改变的。产品规划是预测性地对这些阶段进行设计，并制定每个阶段应采取的策略，这其中就包括每个阶段的价值取向。更进一步，大的阶段还可以分为一系列连续的小阶段，小目标，比如每个季度，或者每个月，都应该有一个产品要达成的关键目标。

有了团队一致认可的阶段性目标后，当团队分析一个特性或故事，基本只有与该目标强相关的才优先纳入版本计划或迭代计划；而与目标不强相关的优先级就往后放；若这样做出来的计划大家认为不合理，那就要回去审视设定的目标是否不恰当了。产品的特性或故事是否符合产品规划，是否符合当前的阶段性目标这是进行**“价值”**判断的最重要方法。

在制定产品规划和阶段性目标时，精益创业的最小可行产品（Minimum Viable Product）分析方法可以很好地用上。MVP 分析即是对某个 Idea 设计一次最低成本的探索，也就是制定一个较小的短期目标，符合此目标的特性和故事就优先纳入该 MVP，而不相关的就暂时不做。MVP 分析都给我们提供了一条很好的进行持续创新探索，设定短期目标和进行价值判断的思路。

在基于阶段性目标或 MVP 分析进行“价值”判断时，建议从“是否不可替代”的角度去进行思考，即对每一个特性或故事问我们自己：如果暂时不实现它，我们想要进行的探索能否达到目的？想要改造的业务流程能否实现？用户的期望能否得到满足？是否可以暂时采用其它替代的手段达到同样目的？若我们每一次把目标设定得足够小，这样的思考可以帮助我们排除很多暂时价值还不够高的工作，从一堆看似都和当前目标相符的特性或故事中找出真正价值最高的部分，可以更快将一个版本交付出去。

投资收益分析

企业对产品最直观也是最简单的期望就是能够带来财务数据上的提升。因为有了这个特性，能够增加多少收入，或节省多少开支？或者如果缺少这个特性，将会造成多少损失？如果能够针对特性就一段时间内所能产生的财务影响进行较合理的计算，那么价值就可以被量化了。

计算财务影响的时间周期可能是几个月，几个季度，甚至是几年。若交付的软件产品是用于销售的商业软件，我们可能有办法预测它在未来一段时间的销售数据。在做这样的预测时一定要将销售或市场研究人员纳入进来。分析产品的销售渠道有哪些？我们可以将细分渠道列出来，比如：零售，OEM 预装，政府采购，企业采购等。软件的利润来源有哪些？比如 License 授权，支持或服务费，应用内购，插件或高级特性收费，广告收入等。一个特性可能只对某一类的用户或某一渠道的销售有影响，做这样的细分有助于我们更清晰的看到新特性可能带来的销售变化。

进行财务分析，也需要考虑到以下一些财务分析方法，帮助我们清醒得判断不同的特性的价值高低，而不是认为只要能带来收益就是值得做的。

净现值（Net Present Value），同样带来 100 万收入，是在近一个季度兑现，还是一年以后兑现价值是不同的
内部收益率（Internal Rate of Return），营收的增长率要达到怎样的比例，目前的投入才是值得的，5%？10%？
投资回收期（Payback period），当前的 100 万投入增加一个新特性，多长时间才能收回投资

而对于企业的内部应用系统，更多的意义不在于创收，而是通过标准化，自动化，信息聚合等手段提升生产运营效率，减少浪费，降低成本。比如供应链系统的某一特性能够自动化原来由手动处理的操作，参考原流程的每日处理次数和每次处理的人力和设备支出，我们也许可以粗略算出该特性能够给整个供应链效率提升所节省的成本。对于这样的收益，不要泛泛而谈，一句提高效率无助于帮助我们识别价值高低，需要尽可能找到一些更科学的评价方法。

关于财务回报计算的方法在《Agile Estimating and Planning》一书里有一些详细描述。但是在我遇到的大多数项目中，要对产品特性带来的财务影响进行预测和计算都是件困难的事。大多数特性对于收入和成本的影响都是间接性的，可能没法直接将其关联到销量，价格或支出等因素。

以用户为中心的分析

产品必然有用户，不管是客户，消费者，还是企业内的业务人员，或是依赖这个产品所提供服务的其他产品团队，可以一概统称用户。丰田汽车的精益实践，以及小米的创业过程等都证明，用户在产品创造过程中的早期参与能够产生更好的结果，并提升用户的满意度；而对每一个新特性或改进，我们也需要最终从用户那里获得反馈来验证我们的假设是否正确，以便调整以后的演进方向，形成闭环。因此，我们在判断特性价值高低时应当以用户为中心。我总结为以下几方面：

用户行为影响

增加或修改一个特性，将对用户行为产生影响。比如改变用户体验，影响用户黏性，导致用户群体结构的变化，乃至影响产品在用户心中建立的形象等。不同类型的产品关注点会不同：一个社交产品、媒体类产品可能用户黏性方面的特性价值非常高；工具类产品尤其关注用户体验，易用性；而一个企业 IT 系统则更关注对用户现有工作方式和业务流程带来的优化，效率提升；最近几年企业 IT 系统的用户体验也逐渐得到重视。

为了帮助我们更细致地对用户行为影响进行分析和预判，可以参照进行销售预测时对收入来源进行细分的方法，我们可以对产品的用户群体进行细分。对企业 IT 系统和应用，可能划分为员工，经理，业务人员，供应商等，或者按企业部门，职能角色划分；对于互联网产品，可以按照用户年龄段，性别，和地域来划分；甚至考虑这样的互联网行为类别：网络浏览者，轻度网络服务使用者，网络服务忠实用户，自发推广者，合作伙伴等等；具体细分方法不一而足。产品在不同的阶段所主要服务的对象，或最能为产品带来发展的往往只是特定类别的用户，而一个特性影响的可能也只是个别用户群体，进行用户群体细分有助于我们更清楚地判断一个特性带来的用户行为变化。

注意，用户行为的变化可能没有绝对的好坏，进行优先级选择时应当引导这种变化与组织的战略和产品愿景一致。比如 Apple 近年在 iOS 和 MacOS 的体验一致性和协同性上面大做文章，添加的大部分特性都在潜移默化地影响着用户的行为，从中我们可以窥得一些 Apple 在操作系统层面的战略和阶段性目标。

用户渴望度

作为产品的创造者，在设计产品时你有没有和真正的用户进行过交流？有没有经常和业务部门的人开电话会议听他们抱怨？如果有，你一定会听到他们对这个产品很多的期望或不满。若一个问题被反复提起，并且恰恰这个需求又符合产品的愿景，那就不要犹豫了，这就是你应该关注的价值。产品不就是为用户服务的吗？

想了解用户或业务人员对产品特性的渴望度有很多方法。首先第一点就是多倾听。不要将自己关在屋子里闭门造车，而是与用户交流，与业务人员交流，或者与直接面对用户的销售人员，客户代表交流。若一个特性他们逮住机会就向你提，向你抱怨，天天在那儿叫嚷，那你就一定得认真考虑了。要将用户从早期就纳入到产品的设计和开发过程中，与用户产生共鸣，移情，你才能抓住他们。

除了与零散的用户交流，也可以组织一些典型用户组或早期参与者。定期邀请到产品团队，与他们一起商讨产品的规划；告诉他们近期可能考虑的一些新特性或改进，由用户来选择或提出他们的期望，而不是靠个人的判断。

我们曾经用过的方法还包括设计问卷调查。Product Owner 能够直接接触并倾听的用户毕竟是少数，我们要想办法要获得更多样本数据。设计一个问卷，将用户反馈的建议，我们认为有价值的特性，展示给我们挑选的用户，甚至所有用户，由他们来打分。有一个叫”Kano Analysis“的方法，在问卷中我们针对每一个特性问用户两个问题：如果有这个特性你感觉怎样？如果没有这个特性你感觉怎样？用户可选的回答包括：

”我非常开心”
“我期望如此”
“我无所谓”
“勉强能接受”
“我无法接受”

通过正反两面的的提问和矩阵式的结果分析，可以比较准确地了解到用户对各个需求的渴望程度相对高低。

甚至这样的用户参与可以放到线上进行，比如从论坛、微信公众号等网络自媒体，产品内嵌的反馈建议模块中收集用户的反馈和期望；并真正能将其中合理的要求尽快呈现给用户，让用户感受到我们在用心地聆听。

用户量和使用率

相信绝大多数人都理解 20/80 原则，每当谈优先级排序我都总会拿出来讲。软件通常只有 20% 功能是用户常用的，而其他 80% 都很少用到，甚至几乎没人用；然而传统软件开发我们可能花了 80% 的时间去开发和测试较少人用的那些功能，却没有把最频繁用到的 20% 做到足够好。

微软的 Office 每次更新都会增加很多特性，甚至曾经还有过一打开 Office 就有一双眼睛在那儿呆萌地盯着我。但作为一个用户，自认为还比较典型，感觉今天和我十几年前上大学刚学会用 Office 那会儿所用到功能没有太大差别，我常用的可能占 Office 所有特性 5% 都不到。“少就是多”这个道理并不难懂，但我发现真正以此去认真思考并践行的人并不多。就普遍场景来说，应该是越多用户使用、越频繁使用的特性的价值是越高的，应当优先得到更多的资源。

曾经接触过一个项目，他们运用 Ajax 将每个页面及页面上每个主要的功能（按钮）的使用都记录下来。然后他们统计页面和按钮有多少不同的人使用，总共被使用了多少次。以数据为基础，一个简单的规则就产生了：那些 80% 用户都会用到的页面或功能，以及使用频率最高的 40% 页面或功能一旦出现缺陷或需要改进，在没完成这部分之前，团队绝不增加任何其他新特性。于是这样产生了一个质量很高，用户感觉用起来很爽的产品，即使它没有看似功能丰富得眼花缭乱。

价值验证

上面分别谈了谈对需求进行“价值”判断时需要认真思考的几个角度。但这样就没问题了吗？

我始终忽略了一个重要问题：所有这些分析和判断都是在特性被实现之前进行的，是一种预测。而记住：预测是导致绝大多数失败的恶魔! 而“只有实践是检验真理的唯一标准”。进行价值判断要考虑很多因素，然而为了避免判断错误花过多时间进行讨论，迟迟不去实践，你就错过了实现价值的机会。在互联网和传统企业都努力追求创新的的今天，需要的是快速迭代与反馈验证，以及基于反馈的快速调整；而所谓准确的预测并不能有效避免失败，只有基于快速反馈验证的迭代式演进才能降低可能失败的风险。

因此关键的关键是，我们从提出一个特性开始，判断其价值的同时就要思考如何对它的预期价值进行验证：可能是收入或成本，用户反馈，下载量，满意度的变化；还有一些验证方法可能需要以一些技术手段来实现，比如统计访问量，点击率，停留时间，A/B 测试等等；在精益创业（Lean Startup）中，通过设计 MVP 来对假设进行探索，通过持续增量地交付特性来验证其价值。若经过几次改进尝试，都达不到之前所预期的效果，那就得认真思考转型（Pivot）了，而这可能意味着整个产品的愿景和规划这些影响产品“价值”判断的最重要依据都会改变；甚至导致组织战略调整。

将每一个特性视为一个假设，从提出特性就明确其验证手段和标准，以此形成特性交付的闭环。这称之为“假设驱动开发（Hypothesis-driven Development)”，在将出版的《精益企业》中有较详细描述。

总结

综上所述，虽然每个软件产品所交付的内容在“价值”的判断上都基于其产品特征各不相同，但归纳起来说我们可以从组织战略方向，产品规划和阶段性目标，投资收益，和用户几个角度去思考。注意这几方面不是独立的，如文章开头的图所表达的：

产品特性要符合和有助于实现组织战略，这是价值观的源头，不应当与其背道而驰，否则组织战略如何落地？这与产品需要创新并不矛盾，组织战略需要有开放性，并鼓励业务创新、产品创新。在这个层面上组织需要统筹。
通过产品规划和阶段性目标来主导产品演进过程，这是对特性进行价值取舍的最重要方法。产品规划是为了实现愿景，而愿景显然应该符合组织的战略方向；而规划和阶段性目标的产生过程中要用到的主要方法是投资收益分析和以用户为中心的几种分析方法。
迭代式地将产品交付给用户后，根据运营反馈来验证当初对投资收益或用户行为上提出的假设，也就是我们对“价值”进行的预测；可能基于验证结果调整产品规划，甚至组织战略。

感谢张凯峰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。