【前言】需求过来时，不要着急思考 “怎么做”。应先思考 “为什么要这么做”。

事情背景是这样的：

我负责了公司某个公共的的 npm，该 npm 被公司所有的 web 应用使用（以下用 p 代替）。某天，A 业务线的小明跟我说：

• 小明：“我们在一个复杂项目的场景下，需要 p 的 projectName 支持动态修改。即随着时间的推移，该 projectName 可能产生变化。”

• 我：“先说说该项目复杂在哪里？”

• 小明：“我们的项目里依赖了一个公共的业务模块，该公共业务模块里面使用了 p。而我们的项目里也依赖了 p，并且我们之间使用的 projectName 是不同的。而我们期望公共业务模块使用我们配置的 projectName。期望你能修改一下 p，以支持动态修改 projectName。（以下省略...）”

如此往复沟通，我都是围绕两个主题：

• 业务背景
• 项目背景

为了更好的理解他们的业务，我找到他们的产品经理去理清其中的业务关联。了解下来，我告诉他们：

1. 公共业务模块设计上存在缺陷。作为公共依赖，不应该有自己的 projectName 而应该使用母工程传入的配置或实例；
2. 即使从 p 的出发点去解决这个不合理的问题，也不会是你们所说的方案；
3. 我的建议是修改 公共业务模块。

最终由他们 TL 拍板调整 公共业务模块。

整件事情处理的套路正是我要告诉大家的：

• 得到需求反馈时，不要着急去思考 “怎么支持这个需求”。不妨先与产品经理与项目经理聊聊，理解对方的业务与项目背景。进而支撑你理解 “为什么有这个需求”；
• 如果需求合理，告诉对方你的方案及排期规划并询问对方的规划；
• 如果需求不合理，这个时候你要学会拒绝。并且告知是因为需求不合理导致，同时给出不合理需求的改进方案；
• 适当的借助 TL 的力量去推动工作的进展。