叮嘟！这里是小啊呜的产品进阶读书笔记整理。好记性不如烂笔头，今天也是努力进步的一天。一起加油进阶吧！

一、今日阅读计划

07讲  关于需求变更（上） 需求背后的需求

08讲  关于需求变更（下） 化变更于无形

二、泛读&知识摘录

1、07讲 关于需求变更（上）：需求背后的需求

（1） “唯一不变的，就是变化本身。”——斯宾塞·约翰逊

（2）需求不会变更，变更的是实现。

用户的需求通常很稳定，变更是由于 产品经理对用户需求的分析出现了偏差，或 满足用户需求的手段发生了调整。

比如，产品经理说需要一匹更快的马，后来换成了要汽车。
在这个过程中，用户的需求一直都是到达目的地”，变更的是满足需求的方式。

（3）挖掘需求背后的需求。

对于产品经理来说，挖掘 “一匹更快的马” 背后 真实的用户动机 是最重要的基本功，不要停留在用户自己提出的所谓需求上，这些需求只是真正需求的一个线索。

“用户不需要 1/4 英寸的钻头，他需要的是 1/4 英寸的洞。”
“用户需要的也不是 1/4 英寸的洞，而是在墙上挂一幅画。”
“用户不是需要画，他需要房间的格调。”
......
这些听起来像抬杠的演绎，其实就是不断探索和挖掘真正需求的过程。

我在工作中经常用到的 “5问法”，所谓“ 5问法 ”，就是针对一个问题，连续以“为什么”来自问，连问 5 次，从而追究其根本原因，找到用户背后真正的动机。

比如，做公司内部的订单系统：
用户提出希望为订单添加根据最近修改时间排序的支持，你不应该直接去实现，而应该问为什么。

可能用户会说，因为每天的订单量太大，审核不完，为了防止订单过期，所以要从最久远的一份开始审核。

很多产品经理到这里就结束了，但这还不够，你应该继续就这个问题问下去，比如可以问为什么订单会过期，或为什么一定要审核。

这是我经历过的一个真实案例，随着不断深入挖掘，后来发现有大量的审核工作是可以自动完成的。
最终我们做了一个自动审核的功能，彻底解决了这个问题。

关于需求变更有一个值得注意的事实：变更通常发生在产品特性上线之前，也就是需求分析结束，开发正在进行或测试正在进行的过程中。
如果项目已经发布，一般再改就叫“新需求”而不是“变更”了。

（4）给需求分析留出时间。

分析需求的时间不够，在短时间内，产品经理的方案和逻辑没有完全想透，但为了尽快出结果，紧赶慢赶写完需求文档交给下一个阶段。

变更出现越早代价就会越小。

给前期需求分析的过程留点时间和空间，让产品经理能在自己的脑子里跟自己多较较劲，把该变的都变完，交出尽可能稳定的方案。

建议产品经理在完成需求分析，写好需求文档之后，把文档放下来，不去
想它，做一点别的事情，等个一两天，大脑从需求的情境中脱离出一点之后再重新去读自己写的文档。通常都会发现或大或小的问题，我们把这个过程叫作 需求文档的发酵。

（5）别忘了需求评审。

增加需求评审。
不一定是架上投影仪开大会，找几个人到茶水间聊一会儿也行。

在方案交到开发阶段之前，把它挂起来先打个遍体鳞伤，否则开发到一半再变更，就只能把产品经理挂起来打个遍体鳞伤了。

2、08讲 关于需求变更（下）：化变更于无形

（1） “拥抱变化。” ——阿里巴巴价值观之一

（2）如果项目已经根据项目流程开过了需求评审会，却没有在这个环节暴露问题，直到临发布的最后一刻才引入了变更。怎样改进需求评审才能避免未来可能的变更呢？

（3）“具体”的力量。

对一些关键性的特性，在资源配置合理的情况下，尽可能做一个与实际情况没太大差异的来做评审。
数据可以是假的，架构可以是假的，但看起来和用起来要尽量保真。

哪怕没有做成动态的，只是一张张截图，在评审的时候你也可以通过讲故事的方法让它变得具体。
比如你可以展示一个界面，边引导大家边说：“现在我是一个从朋友圈打开 xx 的用户，我看到的页面是这个样子。”——这样代入具体场景，才能让大家产生真感觉。

（4）变更时机的选择。

如果变更在所难免，时机选择就很重要，并不是所有变更都“越早越好”，而是要 平衡收益和成本。

最好的变更发生在需求分析过程中，在产品经理脑子里。

第二好的时机是在需求文档结束，工程师接手前。

在工程师接手后，
      有的变更很小，比如文案之类的，随时发现随时提，提的同时记得改掉文档描述。
      稍微大一点的功能，则最好在发现变更后就立即跟开发沟通，去判断合适的变更时机。
      有时候工程师还没有做到这一部分，那就不会产生什么额外成本。
      有时候工程师已经做完了，你要比对一下变更的优先级和可能带来的延期再做决定。
      
如果涉及流程和架构上的重大变更，更要立刻与整个项目组沟通，有可能连设计都要推翻重做，这种情况挨骂是肯定的，态度好点儿，可能可以躲一顿打。

如果项目基本完成开发，箭在弦上准备发布了，那对于变更一定要更加慎重。
这时的态度是应该是能不变就不变，可以先上线，通过运营的手段稳一下线上，然后尽快迭代做修改。

总之，原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。

（5）让团队能消化需求变更。

虽然大家本能上都讨厌需求变更，但我们永远都不可能彻底杜绝需求变更，更何况我认为有时需求变更也有积极意义。因为变更是响应变化，在互联网行业里，每天刀光剑影，瞬息万变，市场上发生的事情传递到产品和服务上，越快越好。

三、头脑风暴

1、【07讲 关于需求变更（上）：需求背后的需求】思考

我的思考：

收集用户需求后完成产品方案前，我会多跑跑开发同事工作区简单咨询一些需求技术支持问题；
需求分析方案和设计方案初稿完成后，我会先和项目开发团队拉小会简要过一下，再和客户与用户确认需求；
内部评审确认需求&需求宣讲会后，需要关注&跟进开发进度，及时交流同步信息。

他人启发1：个人经验。

在做项目的过程中，在开需求评审会之前，我一般会先把自己的产品方案给技术看一下，简单评估下可行性，做一个简单的统一看法。

再开需求评审会的时候，最大的目的是传达整个项目的目标，统一项目中的细节，然后根据会上各方的讨论结果再给需求内容做一些合理调整。最终发邮件确定方案。

需求评审会更像是将产品经理对项目的看法和目标传达给项目参与者的过程，给团队成员统一目标。

他人启发2：知识小结。

一是 5 问法，这是破解需求的好办法。
  我们总说有一些伪需求，可能就是在前期并未做好充足的讨论与思考，碰到什么事情就一股脑地列入计划，不给自己留有一些缓冲余地，最后只能自己背锅。
  
二是，通过不断提问，学会给自己充分的思考空间。
  闭门造车永远都是最低效的方式，要真正验证假设，而且一定要快。
  
三是，我在现实工作中碰到的情况就是，需求评审这事其实大家没有放在心上.
  有些同事对业务并不熟悉，心态上还是以完成任务为主，对需求或是方案并未有足够的重视，简而言之，责任都是产品经理的。
  我一直在想，产品是靠团队的，一个人总有自己的局限。

无论是需求分析出现偏差，还是需求方式进行变更，都体现了产品经理需求分析的能力。

而在需求变更开始之后，考验的就是产品经理沟通和平衡能力。无论是过程中哪一环出现问题，都是产品经理的责任。虽然没有完美的产品经理，但是有不断完善自己的产品经理。

2、【08讲 关于需求变更（下）化变更于无形】思考

他人启发1：敏捷实践。

站在一个开发角度，结合敏捷实践，谈谈自己的想法：
1. 团队的整体设置一定是快速响应变更的，需求的变更程度和sprint长度成反比，这个对于dev team的要求极高；
2. 做技术的一定要积极投入需求评审会中，不断challenge产品经理，一方面帮助他们更多思考，另一方面探究自己的理解对不对，一定不能闷头执行；这就要求dev team一定是跨职能的，否则在开会时就是走过场；
4. 在技术层面，快速响应变更后面意味着有一套完整的TDD，CI/CD流程，否则无法形成可靠的workflow。

他人启发2：PS+PPT。

我用PS+PPT，不仅做静态原型，偶尔还做小动效。

他人启发3：找到对的人。

原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。

这里有个前提很重要， 找到对的人。 
知道谁是对的人这个也是职场需要锻炼出来的。

没错，在不知道怎么识别的时候，一般是直接找项目的技术负责人，如果他完蛋，基本项目也就完蛋了。

他人启发4：信任感。

这里说的是具体的事情，从另外一个角度说下我的看法：信任感。
产品精力和研发之间是否足够信任，是否可以放心得把后背交给对方，搞定了人的事情，后面的事情会轻松很多。

Ending！
更多阅读笔记记录随后再来吧！

就酱，嘎啦！

注：
人生在勤，不索何获。