产品经理不停的改设计，作为前端该怎样处理( 三 )
我思考了一下，回答说：
“
价值就是用户的真正的需要。 如果我们满足了用户的需要，我们就创造了价值；反过来，如果我们做了很多事情，但是没有满足用户的需要，我们就没有创造价值。
”
这两类的需求变更，无论是需求的优化，还是需求的往复变更，都是为了更好的贴近用户的真正的需要，所以，这两类的变更，都是好事情。
所以，
我们的问题不是变更是好事情还是坏事情，也不是该不该变，而是如何更高效的达成变还是不变的决策——即，如何更高效地管理变更。
找到正确的问题，问题就解决了一大半，到现在为止，我们找到了正确的问题了：
如何更高效地管理变更。
3我们用什么态度来面对需求变更?
这个问题其实在第2个问题里已经侧面回答过了。需求变更的目的是为了更好的满足用户需要，关乎我们创造的价值大小，所以我们要积极面对。积极面对包含两部分的含义：一，不抵触或者反对，二，不迎合和欢迎。而是积极的去管理。
4为什么需要管理变更？
如果不管理，就会出现下面的场景：
5如何高效管理需求变更？
做好下面的6点，就可以高效地管理变更。
1各个渠道提出来的变更统一提到产品经理。研发团队只和产品经理对接。
反例1：变更直接提给开发团队，开发团队直接被外部多方打搅，不知道哪些做哪些不做，哪些先做哪些后做，就只能打乱仗。
【产品经理不停的改设计，作为前端该怎样处理】 反例2：开发在工作中自己觉得设计不合理，就自行把原来的定义给改了，连产品经理都不知道。最后验收的时候才发现。反例3：开发团队直接接收了一个高管的新加入需求，就凭直觉接受了这个需求去做了，结果造成现阶段的交付目标不能按时达成，而这个交付目标是在之前和高层承诺过的。
2产品经理对变更请求进行初步评估，评估第一个标准是：这个变更是否和本阶段的工作目标对齐。
反例1：团队收到一个和本阶段产品发布目标完全没有关系的突发奇想。
反例2：团队收到一个损害本阶段产品目标/与产品目标背道而驰的改动建议。
3产品经理对变更请求进行进一步评估。评估第二标准是：这个变更是否已经定义清晰，清晰的标准是团队清楚理解需求和解决方案
反例：团队收到一个还在概念阶段（缺乏详细定义）的新增需求，边开发边澄清需求和返工，造成本阶段工作目标受到严重影响。
印象派作品《日出》
4产品经理进行初步评估后，变更请求需要团队各方代表进行评估
是否接受变更，至少需要团队的各方代表，包括开发代表，测试代表，运维代表进行统一的评估。如果是属于产品目标的变更，同时还需要投资人，用户代表，和业务方代表参与评估。
推荐阅读
- 刚买来的蟹爪兰，做好这几点，保准让其蹭蹭长不停
- 三角梅冬天有“四怕”，避开了才能安全越冬，来年疯狂开花不停歇！
- 旅行社@旅行社推出“高铁+旅游”新产品 高铁旅行说走就走！连淮扬镇高铁全线通车
- 广西鹿寨贫困户玩直播带货变身创业新星以电商帮老乡卖滞销农产品
- 黄金时间■黄金时间丨哪种产品最节水？购买产品请注意这个标识！
- 唐国标：招揽“职业经理人”勾勒好塘栖的新蓝图
- 货币等各类金融产品彻底电子化会到来么
- 侧重业务逻辑的产品需求规格说明书，需要有哪些要点
- 程序猿和产品汪能愉快的一起谈恋爱嘛
- 知乎有没有必要增加一个特别关注功能