产品经理不停的改设计，作为前端该怎样处理( 二 )
■网友
学了那么多 “软件工程” 知识，到实际中就全都还给老师了么？呵呵。工程师，工程师，就是要用工程的方法做事，得有能力分析工程的时间、范围、成本。不管是新做东西，还是就做改动，它们都是工程，都要做好每一步的时间范围成本的分析，然后给出合理计划，如果你把计划和排期说的明明白白，让大家都知道每一步的时间范围和成本，那这就是证据，谁都无法反驳的。
■网友
这个问题不是一个接受或者拒绝就能解答的问题。设计或者需求的改动请求是需要管理的。
另外，你做为前端，遇到这样的问题，你并不孤单，因为产品经理如果不停的改设计，很有可能也会有同时给后端提各种更改的需求。
经常的需求变更如果不进行管理，不仅仅会给你一个人造成困扰，也同时会给团队，给交付造成重要的影响。
建议你可以看下下面这篇我之前写的对待需求变更的态度，和管理变更的方法的文章。在文章末尾，还给出了具体的123行动项，帮助你们团队来一次性解决所有需求变更的问题。
【实用长文】一听到改需求就发抖？一次性解决所有需求变更问题（赠需求变更流程图）
地球人都知道IT人喜欢自黑。
经过作者的非常不完全统计，99.9%的IT圈段子，都来源于同一个素材——改需求。
比如下面这个：
这么多关于“改需求”自黑，说明了大家普遍对这件事情感到很无奈。
在如何面对挨骂链底端的产品经理一文中，我说过一个事实：
“需求变更是无法完全杜绝的，因为没有人能一开始就知道所有事。”
但这就意味着我们对变更永远无能为力吗？不是。
“变更虽然无法杜绝，但是是可以管理的。”
这篇文章将一次性解决所有需求变更的问题：
1. 什么是需求变更，这篇文章讨论的需求变更是哪一类？
2. 需求变更这件事，到底是好事，还是坏事？
3. 我们用什么态度来面对需求变更?
4. 为什么需要管理需求变更？
5. 如何高效管理需求变更？
6. 送给大家一个可以拿来就用的需求变更管理流程图。
7. 行动起来，和变更问题做了结！
1这篇文章讨论的需求变更是什么？
这篇文章中讨论的需求变更指的是，在计划已经定稿，团队开始工作之后，所有不在当前团队的工作计划中的任务（包括需求）。
包括：
新加入的任务
现有任务的改动
如果是要改动下一个工作周期/阶段的计划，不在这篇文章的讨论范围之内。如果是在这个工作周期/阶段的计划定稿、团队开工之前做的计划的改动，也不在这篇文章的讨论范围之内。本篇讨论的需求变更，仅限于已经排好了计划，团队已经开始工作之后，要做本个工作周期中的变动。
2需求变更这件事，到底是好事，还是坏事？
需求变更可以分为两类，一类是需求的优化，比如功能优化，性能增强等；一类是需求的往复变更，就是今天要方案A，明天说要改成B，后天又说觉得改成C比较好。看到这里，有人会说：
“
我知道我知道！第一类变更是好变更，第二类变更是坏变更！
我还知道，第一类好变更，是优化嘛，改是理所应当的，你怎么说我怎么改！
第二类变更，是坏变更，不改不改，还要把产品经理打20大板，不，50大板！
”
以上整个思路表面上是正确的，但是本质却是错误的。
今天早上，我的一个同事问了我一个问题：
“你觉得什么是价值？”
推荐阅读
- 刚买来的蟹爪兰，做好这几点，保准让其蹭蹭长不停
- 三角梅冬天有“四怕”，避开了才能安全越冬，来年疯狂开花不停歇！
- 旅行社@旅行社推出“高铁+旅游”新产品 高铁旅行说走就走！连淮扬镇高铁全线通车
- 广西鹿寨贫困户玩直播带货变身创业新星以电商帮老乡卖滞销农产品
- 黄金时间■黄金时间丨哪种产品最节水？购买产品请注意这个标识！
- 唐国标：招揽“职业经理人”勾勒好塘栖的新蓝图
- 货币等各类金融产品彻底电子化会到来么
- 侧重业务逻辑的产品需求规格说明书，需要有哪些要点
- 程序猿和产品汪能愉快的一起谈恋爱嘛
- 知乎有没有必要增加一个特别关注功能