3.22. 产品迭代管理¶
3.22.1. 产品迭代管理的目的¶
产品在研发上线，推向市场时，需要随时监控市场变化、用户需求变化，不断迭代产品，以延长产品生命周期。
3.22.2. 产品迭代管理的要求¶
软件的持续优化、升级：充分利用研发资源，正确认识技术优化所需的资源，升级研发效率
研发资源管理：研发人力资源安排图（时间、负责人、项目模块）
技术优化资源分配
初创：权利开发业务功能，10%用来技术优化
瓶颈：业务需求满足疲态，技术架构、设计缺陷出现问题，50%技术优化
重构：80%资源做技术重构
稳定：10%-20%资源持续做技术优化
双周迭代 局限性：MVP不一定能在迭代周期内交付、跨端项目复杂研发节奏相互依赖、难以准确预估工作投入
3.22.3. 迭代优化的过程¶
闭环过程：upgrade->需求挖掘11、反馈->不满->产品需求池->评估->排序筛选（其他的被排除）->转化为功能（其他的用弥补方案）->Feature List->upgrade
3.22.4. 形式 9¶
3.22.4.1. 升级换代¶
任何一款产品的生命周期都是有限的，因为客户总有「审美疲劳」的一天，竞争对手也在不断地推陈出新。后续新产品一般在前一款产品开始进入成熟期的后期时推出。这样，既保证了产品的连续性，又保护了前一款产品的获利机会。在图 5-3 中，当第一代产品 A 进入衰退期时，第二代产品 B 开始进入成长期；当第二代产品 B 进入衰退期时，第三代产品 C 开始进入成长期。通过多代产品的持续更新升级，企业实现持续的利润增长。
3.22.5. 需求管理背景¶
内部资源永远是紧张的，外部竞争却时刻在发生。所谓内部资源，主要是指研发资源。与AI相关的研发工程师在大多数企业中都是处于稀缺的状态，如何“好钢用在刀刃上”，那就考验产品经理的决策能力了。
当产品经理面对多个需求时该怎样做呢？我们没有办法把所有的需求同时做好，与其接收多个需求同时做，可能每个需求和功能都做不好，不如抓住一个需求做到完整。
3.22.7. 需求来源部分¶
不同方向的需求来源略有不同，总体来说，产品经理的需求来源有以下几个方面：
业务需求：由业务方，比如 BD、编审、运营等，直接提出的业务需求（与市场营销、产品运营等各部门协作，推广产品，适应长期发展8）；
数据挖掘：通过数据挖掘和分析，发现的问题或需求；
竞对调研：通过分析竞对的产品，发现竞对比我们有优势或值得学习借鉴的地方；
实地观察：不论是 B 端产品还是 C 端产品，其实都有大量的机会实地观察用户行为。比如直接陪访城市运营等；
战略需要：俗话说「老大拍的」，这类是由公司 leader 直接安排的需求，通常表示公司未来发展方向或急需解决的关键问题；
其他还包括客服、商服反馈的问题，通过在线渠道或用户访谈获得的需求，还有微博、朋友圈吐槽等各种 SNS 途径。不论哪种途径获取的需求，产品经理都应该有一个自己的需求池，统一记录各种想法。
在不同需求来源中，最看重的产品经理自己发现/评估的需求，这是评价产品经理需求决策能力的重要指标。
3.22.8. 收集和整理需求¶
收集和整理需求，就是将需求统一记录到需求池，方便团队内/间的传播。每个团队建议维护自己的需求池地址。
需求池只是一个备忘，记录下来的需求不一定都要做，也未必是值得做的需求才记录下来。
3.22.8.1. 需求收集¶
需求来源：见上。
需求内容：交互体验优化、业务调整要求、业务管理要求
需求采集：1V1面谈、问卷调研、轮岗实习
需求背后的 真实问题 以及 需求的价值
需求背后的真正问题是什么？
问题是否有简单快速的解法？
问题影响面有多大？个案问题是否值得研究解决
共性问题，优先级和紧急程度？
3.22.8.2. 需求池¶
企业建立需求池是为了让AI产品经理能够了解在一定时间内该业务的整体需求，从而能够更加全面地评估需求，需求池可以按照周或月的频次进行更新，这样更便于观察。
3.22.9. 筛选评估需求如此困难的原因¶
相比去做更普适的项目，做那些你最喜欢的、自己会用的产品更令人满足。
相比去做直接对你的目标产生影响的项目，把注意力集中在那些聪明有趣的主意上更有诱惑力。
相比去做自己已经有信心的项目，去钻研新的想法更令人兴奋。（有些情况也可能反过来）
相比去做语权大的需求，拒绝伪需求冒着得罪人的更稳妥
相比追求面面俱到，只把主线功能做好显得多么简陋
3.22.10. 需求属性的评估¶
3.22.10.1. 三维度¶
需求价值评估：需求的价值分为两个维度，一个维度是创造效益，另一个维度是节省成本，通过对需求背景的影响因子给定假设条件进行评估，就能大致估算出这个需求可以产生的预期效果；例如：当前的妥投率为95%，未妥投原因中收件地址错误的原因占比75%，假设通过增加收件人地址校验，解决85%，那么需求的预期收益就是提升3.18%的妥投率。
需求难度评估：难度可以从是否需要设计新模块开发、原有模块改造量、开发实现难度、是否涉及关联系统改造几个方面进行考量；如果一个需求既设计算法选项、参数优化、训练数据标注、模块封装、总控接入、前端改造那么这个需求的实现难度就属于很高的程度了。
需求周期评估：需求拆解后本项目组的开发周期加上关联系统排期、开发的周期就能确定需求的实现周期。
3.22.10.2. RICE 5¶
RICE SCORE = RIC/E，根据RICE评分即可对需求进行排序，该方法比较适用于大型项目，在一般项目中不常使用。
3.22.10.2.1. Reach（接触数量）¶
接触数量是指用每个时间段的用户数或事件数来衡量，考察一个需求在一定时间段内会影响多少用户。这可能是“每季度客户数量”或“每月交易数量”，尽可能使用产品指标的实际测量结果
3.22.10.2.2. Impact（影响程度）¶
影响程度是对目标产生可观影响的需求，以此来预估这个项目对个人产生的影响。可以分为巨大影响、高、中、低、极低几个标准。
3.22.10.2.3. Confidence（信心指数）¶
有些需求有创意但无数据支持而显得不明确，我们在评估时可以把信心指数考虑进去，可以分高为100%、中为80%、低为50%三个档次。
3.22.10.2.4. Effort（投入精力）¶
为了迅速行动并且事半功倍，估算项目需要团队的所有成员（产品、设计和工程）的总时间。投入精力的预估单位是人/月。
3.22.10.3. MoSCoW¶
美其名曰“全面”，以全面来打入市场。最终却是“样样做，样样差”。must have、should have、could have、won’t have模型。
Fig. 3.22.3 MoSCoW¶
位于“1”（Must have）:用户价值高,难度低,优先制作
位于“2”（won’t have）:用户价值低,难度高,延后制作甚至不做;
位于“3”、“4”:如果交货时间紧，“可以有”将第一批被删除，“应该有”紧随其后。
3.22.10.4. Kano帮你找到用户满意度2¶
一种在不同阶段按产品目标倒退需求优先级的思维方式，它将需求分为三类：
它将需求分为三类：
基础功能。代表产品进入市场的基本门槛，保证能够满足用户普遍需求的最低标准。然而在后续的研发若投入大量精力，并不会显著提高用户的满意度或建立产品的竞争门槛，因此此类需求优先级较低。
性能需求。即在实现基础功能后，为了提升和优化产品性能的需求。这类需求可以在一定程度上提升用户满意度，但其他竞争对手同时也会在这方面持续投入，ROI通常为线性。
尖叫（兴奋）功能。用户使用产品后能够感受到喜悦和兴奋，这种产品可能是非常有创造性的，也有可能带来
优先级顺序12：基本型需求>期望型需求>兴奋型需求
属性的成熟程度和情绪反应之间呈线性关系，主要针对于如易用性、成本、娱乐价值和安全性这样的产品特征。
狩野纪昭(Noriaki Kano)将五种情绪反应可视化为图中的曲线，其中，y轴是情绪反应，x轴是特征的成熟程度。情绪反应的强度由特征如何充分呈现和其成熟程度驱动。
将需求划分为必备型、期望型、魅力型、无差异型、反向型五类，分别以英文字母M、O、A、I、R表示。
必备型需求(M)：需求满足时，用户不会感到满意。需求不满足时，用户会很不满意。
期望型需求(O)：需求满足时，用户会感到很满意。需求不满足时，用户会很不满意。
魅力型需求(A)：该需求超过用户对产品本来的期望，使得用户的满意度急剧上升。即使表现的不完善，用户的满意度也不受影响。
无差异型需求(I)：需求被满足或未被满足，都不会对用户的满意度造成影响。
反向型需求(R)：该需求与用户的满意度呈反向相关，满足该要求，反而会使用户的满意度下降。
better-worse系数：
Better系数=（期望数+魅力数）/（期望数+魅力数+必备数+无差异数）
Worse系数= -1*（期望数+必备数）/（期望数+魅力数+必备数+无差异数）
Better系数越接近1，表示该具备度越高该需求对用户满意度提升的影响效果越大。Worse系数越接近-1，表示具备度越低该需求对用户满意度造成的负面影响越大。
3.22.10.5. 维格斯法¶
该方法将需求分为4个维度来进行评估。
实现需求给客户带来的收益。
不实现需求给客户带来的损害。（不做会怎么样？发现用户在解决这个问题的不满）
实现需求所需要耗费的成本。
实现需求的风险。其中收益和损害是从客户角度出发的，而成本和风险则是从实现角度出发的，是逻辑较清晰且通用的方法。
3.22.11. 其他弥补方案 4¶
平衡 如果是面向B端业务，那么所有业务线对自己的需求都是关注且紧迫的；这时候就需要学会平衡每个业务的需求，不能被业务完全牵着走，这样对产品规划会有极大影响。
那么每当这时候，就需要可以一起拉通多个业务，来集中评估各方的诉求，宣导团队的资源是有限性的；让业务之间来取舍他们之间的优先级，这就是让“决策”转移到业务自身上。
替代 任何的产品解决方案都是有备选方案的，那么在当前无法尽快满足用户的前提；可以优先采用临时方案，先满足用户最核心的需求，把其他延伸性需求先砍掉，待到条件成熟在上线完整需求。
而这就是采用“替代”的方式，一定程度上去满足用户需求，这对挽留用户、提升用户口碑有极大帮助。
延迟 这是一个不太“厚道”的方式，前面提到用户对他们自身的需求都关注比较强烈，受限当前的规划和限制条件，确实无法那无法尽快满足的情况，但用户是不会理解买账的；那么如何去“安抚‘用户情绪呢，把负面情绪尽可能降到最低？
这就靠一个“拖”字决，可以先给对方的一个明确信号：我们会做（类似先画个饼）。
但是由于一些原因（把这些问题夸大），需要稍微往后一些才能支持，那么这个往后的时间就可以相对灵活可变的，在这里也主要是安抚用户的情绪为主。
3.22.13. AI相关¶
3.22.13.1. 模型更新 7¶
具体又包括以下几个方面：
模型全量更新。主要是指模型整体升级，比较推荐 tensorflow/serving: A flexible, high-performance serving system for machine learning models，不仅性能优秀，而且可以通过监控模型文件的变化自动升级到新的版本。同时，还支持 RPC 和 RestFul 两种接口，支持版本控制，支持多个模型，简直是业界良心。
模型在线学习。主要指模型根据线上数据实时或准实时更新模型的情况。这块目前工作几乎还未涉及，日后更新。
更新毛刺。主要指模型更新前后线上请求出现的延迟抖动现象。一般在规模很大时才会出现。爱奇艺团队针对 Tensorflow Serving 有过不错的改进尝试，被 Tensorflow 官方公号发表，具体参见：社区分享 | TensorFlow Serving 模型更新毛刺的完全优化实践。
3.22.14. 风险¶
任何我们不希望出现的就是风险，其中很多回导致产品的失败。我们要想办法规避，风险发生后也要尽量降低损失。13
政策风险。比如直播行业，很多打擦边球的就会被勒令停止
团队风险。比如团队中主要人员，可能因为各种原因退出了，工作无法进行
技术风险。比如携程网瘫痪事件。
市场风险。比如竞争对手可能会恶意竞争，或者BAT之类的公司进入我们的额领域
诉讼风险。比如抄袭别人，导致他人诉讼。对于大公司来说，抄袭带来的利益可能大于赔的诉讼费，很可能抄袭。
决策风险。决策失误导致失败。比如谷歌太早退出Googleglass。
资本风险。盲目扩张，导致资金链断裂之类，比如蜜淘网。
不可抗拒风险。比如海啸、地震。