最近有同学问了我一个很常见且扎心的问题
：

“工作中，产品需求方已经确认了需求，应对但是产品在设计过程中或设计定稿后
，总是需求会‘有理有据’地变更需求，导致下游设计稿一改再改。变更设计师该怎么做才能避免这种情况 ，大厂减少返工呢 ？设计师亲授何”

其实我的工作中也遇到过很多类似的情况。我们可以根据需求变更的应对影响程度分“大”和“小”两种情况来看 ：

一 、对上下游影响较小

如果需求的产品变更和调整并不会涉及到下游工作量上的大幅增加 ，只是需求微量调整，那么就需要你从心理上先接纳它，变更承认它是大厂你工作职责中的一部分，是设计师亲授何工作的常态
。毕竟产品都是应对需要经过不断迭代和打磨才能呈现出相对完善的状态。

相比于抱怨
，你更需要做的是在承接需求时就对项目的排期做到心中有数，为最终的交付留有一定的调整时间 ，避免项目整体进度的延误。

二 、对上下游影响较大

如果大部分的变更和调整对你和其他下游团队的工作量上造成了显著影响，会拉低几个协同团队的产出效率，那么你可以试试以下两种方法：

1. “有理有据”地拒绝需求。

既然对方可以“有理有据”地变更需求 ，你也可以“有理有据”地“拒绝”变更需求 。 这里的“拒绝”，并不是指完全不理会或者不承接需求，而是指 ：

1. 给出我们原有的时间规划作为依据；
2. 指出需求变更对于我们设计产出的影响；
3. 拒绝并解释无法在原先的时间规划中完成设计内容的原因；
4. 要求产品方根据需求变更做重新排期
   ，并通知其他相关方
   。

2. 对 PRD 的质量提出要求。

作为产品最紧密的协作者，设计师理所应当对产品经理的产出和交接的方式提出一定的要求，以确保双方达成共识，彼此之间没有信息差 ，才能保证工作的顺利进行 。这些要求可以是：

①所有的 PRD 需求必须有文档呈现。

正如设计稿是设计师的工作产出，PRD 就是产品经理必备的工作产出。PRD 是整个产品研发过程中很正式的一个环节，既能够与上下游交接 ，也能够将需求以文档的形式存档，便于对产品之后的优化迭代和工作追责 。

当然 ，就像不同水平的设计师产出的设计稿质量不同，不同水平的产品经理也会导致 PRD 的产出质量有所不同。抛开写法风格不谈，“能够将产品需求表达清楚 、将需求变更记录详细，以确保协作方能够顺利理解需求内容” ，就是 PRD 的质量底线 。

②每次需求变更都需要重新排期。

当 PRD 中需求发生变化时，并不是简单的文字修改 ，而是牵一发而动全身 ：与之相关的是设计师 、前端、后端 、测试、运营等团队的工作排期和规划。

因此相关的协作方都有权责评估 PRD 中新增需求或修改后需求的变更程度，并要求产品经理重做工作排期。如果改动是在太大 ，也可以商讨是否分两期实现需求。

以我们团队平日里的工作方式为例 ：在承接需求时，不仅首轮 PRD 需要开会做评审
，当 PRD 有变动时，也都需要再开会做二次评审。这样并不会让工作更加繁琐 
，而是会让产品经理更加谨慎和耐心的对待自己提出的每一份需求及需求的变更，确保需求的产出质量。

③协作时端正工作态度 。

产品经理作为上游对接方 ，在对接时的工作态度不应是
：

× 赶紧把需求交出去。

而应该是 ：

√ 确保上下游协作方能够完全理解并认同自己的需求内容 。

相应的，设计师作为下游对接方 ，在对接时的工作态度不应是：

× 赶紧把需求接过来并尽快完成。

而应该是：

√ 确保对需求和产品目标有充分的理解和认知，并确保设计目标与之保持一致。

对于产品需要完成的目标应该是一致的，只有这样 ，你对于产品需求的变更才会更容易接受 ，做出的设计评估和决策也会更合理。

工作中的协同问题会影响工作产出质量 。一个高效的产研团队
，也一定是一个在协同方式上找到了最优方法的团队。你是不是也有过类似的问题和经验？来留言区一起交流下吧～

作者：长弓小子