1704233034
电商卖家向淘宝的产品经理提了个需求，希望可以修改订单价格。这看起来简单，但具体做起来，难度可大可小。最简单的做法是直接修改总价的数字。但修改价格的目的，有可能是多种多样的。
1704233035
1704233036
►买家经常要求包邮，那淘宝是否提供“包邮”这样的快捷操作功能，让卖家可以直接把总价中的邮费部分清零。
1704233037
1704233038
►免邮费是否需要和地域结合，给出类似偏远地区不包邮这样的提示？
1704233039
1704233040
►对于货款，卖家经常要修改的是打折、抹零，要不要提供更方便的操作？
1704233041
1704233042
►老客户折扣有没有提醒？这又需要和CRM系统打通。
1704233043
1704233044
……
1704233045
1704233046
往往，越想让用户简单，系统就要设计得越复杂。
1704233047
1704233048
所以，针对成本的初评来细化功能，细化到什么粒度是很讲究的事情。粒度太粗则没法评估准确，而太细又会浪费时间。这里面有个有趣的悖论：开发说你不细化我就无法评估，产品说你不评估我就不知道是否值得细化，双方各执一词，形成死循环。
1704233049
1704233050
要想正确看待这一悖论，需要双方心里都清楚，功能细化有可能给成本带来很多方面的影响，最终减少影响也离不开大家的共同努力。
1704233051
1704233052
而要在没细化时就能评估得相对准确，要靠团队默契。想象一下，如果产品和技术团队都很成熟，对彼此的人员情况很熟悉，对现有产品、技术架构也很熟悉，具体表现为产品经理知道技术人员的能力，了解功能实现的基本可行性；技术人员理解产品业务，能预测将来会扩展的地方，那么早期的评估一定会更加准确。
1704233053
1704233054
如果细化之后工作量确实比预想的大了很多，我们还可以灵活分割，把一个大功能切分成更细的模块，按照性价比分期实现，从而在保证产品迭代节奏的前提下，逐步完成工作。
1704233055
1704233056
确定性价比
1704233057
1704233058
评估完价值与成本后，就可以得到一张功能列表，具体的呈现可能是一张Excel表格，或者是某个IT系统里的需求管理表。
1704233059
1704233060
图6-4是我在某公司交流时做的一个简化的功能列表。第一列的每张卡片各是一个功能点，有些功能之间的关联很紧密，必须一起做，特意贴在一起以表示同属一个功能模块。第二列是价值评估，用1～5从低到高的分值来衡量。第三列是成本评估，已简化为开发量“人天”，而且因为较难一次性评估准确，用了便签的方式以便修改。第四列是第二列除以第三列得到的性价比数值。
1704233061
1704233062
1704233063
1704233064
1704233065
图6-4 最简单的功能列表
1704233066
1704233067
经常有人问我产品经理要不要懂技术？我的观点是，产品经理懂技术肯定是优势，只要不滥用。比如，在初步评估成本时，自己能搞定就可以大大提升效率。那如果不懂技术怎么办？你就必须和技术人员配合。提供两个常见的方法，Team Estimation Game和Planning Poker，都是敏捷开发过程中供团队一起评估成本的方法，非常简单也非常好用，有需要可以自行查找资料加以学习。
1704233068
1704233069
要牢记此时评估的目的：确定功能的相对成本高低，从而确定性价比。功能A与功能B相比，哪个相对成本较大一点，哪个较小一点，只需要知道对比关系就可以，比如“高中低”的评价或者“5.3.1 ”的不同分值。然后，用半定量的价值和半定量的成本，就可以计算出半定量的性价比。
1704233070
1704233071
这个半定量的公式是：性价比 = 价值/成本
1704233072
1704233073
按理说应该先做那些性价比高的功能，但这太理想化了，实际操作中，还需要考虑功能的分类和其他的实际情况。
1704233074
1704233075
6.1.4 功能分类：KANO模型
1704233076
1704233077
表面上看，只要从功能列表中找到性价比最高的功能先做，就不会有问题。但事实上并非如此。你会发现，有一些非常基础的功能，比如一个电商网站的交易、支付等功能，是非做不可的。如果这些功能需要投入较大工作量，则性价比不会很高。这与之前性价比高者优先的结论有些矛盾，要想正确看待和理解这一矛盾，需要引入KANO模型[3] 。不过，由于KANO模型并不是专门针对产品经理而设计的，此处对其说法进行了一些相应的转化，用它来对功能进行分类。
1704233078
1704233079
先来解释一下图6-5。图中横轴指的是产品功能的实现度，用来表征一个功能有没有做完。最左侧的一点代表功能实现尚未开始，最右侧的一点则代表功能实现已经很完善。纵轴指的是用户满意度，越靠近下端表示用户越不满意，越靠近上端表示用户越满意。
1704233080
1704233081
1704233082
1704233083