很多开发觉得，只要代码写得漂亮、技术能力强，问题就会迎刃而解。
可现实往往并不如此：交付延期的根本原因，很多时候不是技术难，而是需求不明确、产品拖延，或者组织流程不健全。

我曾在一个团队中观察到这样的情况：产品本身是技术出身，他习惯对实现方式进行干预，同时在下发任务时常拖延需求。作为开发，我们很弱势，延期就是我们的责任，而产品延期几乎没人追责。

这种环境下，单靠技术能力是很难保护自己和团队的。举个几乎每个开发都会遇到的场景：

产品：

这个需求差不多了，
你先按现在的理解做着吧，
周五肯定要给我一个版本。

对于这样的要求，开发怎么回答？

说需求没确认不能做？那肯定是不行，会被扣上不配合的帽子。

说保证完成任务那肯定也是不行的，那样会把你当成消耗品，默默的消耗你。比如你刚开发了一个功能，产品可能立即会对你说，你做的不对，需要改成xxx。你修改了一次又一次，但没人记得你的功劳，因为最后的成品可能只是一个很简单的页面。你只能成为被随意驱使的机器，没有思考，只有执行。产品很差劲，无法一次设计出完整的产品，只能不断的修改。但是，一旦体验不好，老板会说，为什么开发没有提出建议？设计的人是产品，但设计出问题让开发担责。你在疲于奔命，你心里在咆哮，但也只能默默忍受，为什么只能忍受，因为在很多组织中，开发都是弱势的，在老板兜着产品、却没人兜开发的环境里，开发没有对抗的底气。开发弱势到什么程度？我亲耳听到一个初级产品在需求沟通会上理直气壮的说：你们前端没有设计稿就不能开发了吗？没有人回应。不是不敢，而是争论这个没有意义，因为老板就是这么想的。通常产品拖延没人问，开发延期需要层层审批解释，还会有很大的概率不被批准。回复很可能是：不行加加班吧...，你那是人不够吗？不行给你加两个人差不多了吧...

在开发弱势环境中，怎样回答才算是不亢不卑呢？

首先要知道，不能硬刚，除非你想换个游戏重新玩。必须说可以做。

我可以先按当前理解推进一个 demo，
但这版不作为最终交付版本，
相关细节确认后需要补改。

由于缺少相关的细节， 建议1，2，3...，因为产品没有完成他的职责，开发只能帮他完善。记住，可以不是最后的产品设计，但不能没有。因为如果没有产品设计，最后评估开发工作的时候，产品可以任意拿捏开发。完成产品设计后，必须锁定产品需求，即使锁定期很短。

比如：在周五前，不接受新的需求。按已经确认的demo版本的需求，周五将会出demo版本。

这样是明确一个边界，也是明确 demo 版本的成本。如果产品并不接受这种大的边界，还是想随意修改需求，开发要尽力给他画小一些的边界：如果周三前确定xxx，是可以完成xxx的。如果周四前能确认xxx，是可以完成xxx的。边界确认后，就是要留下证据，正式些的，发邮件，不过如于开发弱势，这样做显得太高调，会让产品不服务，毕竟是给特权套上马笼头，一般在群里发一下就行了。其实产品真的不遵守，也不能把这个拿出来，除非你要撕跛脸，这样做的作用，是给产品一些心里压力，毕竟正常情况下大家心里对是非都有一个判断。

在画边界时要果断，语气必须肯定。一旦说出，不能随意妥协，除非修改前置条件。有些开发比较腼腆，喜欢把排期单独发给产品，这是大忌。产品无视你的成本为0，可是你承受的风险会达到100%。

现在的产品一般是不懂技术的，这样产品和技术沟通起来可能会有些障碍，于是开发就想，如果产品懂技术就好了。但是当产品真的懂技术，开发就会发现，烦恼（温和的说法）不断。因为他会仍然用“技术负责人 / 架构师”的心态写需求，把 “怎么做” 当成产品职责，你会发现，他把产品需求写成了详细设计。在这样的产品下面，要怎么做才能避免在技术上被锁死，但出了事，却要承担全部责任？

首先，不能直接否定他，那样会掉进自证陷阱。因为你否定他，他就要你证明他哪里错了。这个很难。因为实现方案很难说哪个对哪个错，要选哪个方案，是多方面考虑的，比如开发熟悉（以前做过）也是一个理由 ，但是这样的理由是没办法说服产品的。

可以先肯定他的方案，这个方案从结果上是 OK 的。不过实现上可能存在一些不确定性。我建议需求里先只约定业务结果和约束条件，具体实现我来保证，保证按时交付，保证代码质量。后面是委婉的说明需要给开发留出发挥空间，最后指明，开发才是代码质量的100%责任人，不是产品。千万不要这样说：你这个方案不对， 这个设计不专业，你不懂这个技术细节。要尽力避免和产品 PK 技术，尽力从责任上说问题。把“技术反对”翻译成“产品风险”，你要做的是 不讨论“你对不对”，只讨论“这样会带来什么后果” 。

说白了一切都是因为开发太弱势的错，否则开发直接怼：你一个产品不好好写需求，我怎么写代码关你毛线事？心里再补上一句“狗拿耗子，多管闲事。“

最后总结一下，要始终记住三句话

1. 需求是产品的，结果是一起的，实现是开发的
2. 没有冻结的需求，就没有承诺的排期
3. 所有延期，都必须有可追溯的时间点

你不是在“对抗产品”，是在给团队建立边界。保护自己，保护团队的人。

我最终把这篇文章发到了前端分类，因为我是一个前端，讲述也是是前端角度。标签还加了产品经理，希望能有产品看到，多给开发一些理解。虽然这篇文章没有讲技术本身，但却比技术重要的多。这就应了那句话，做的好不如说的好，说的好不如说到点子上。踏实肯干，精益求精，这是每个开发都应有的基本品质，但也需要学会沟通，懂得保护自己，保护团队。

不要试图去改变组织的风格，不可能成功（从开发这个角色发起，不可能成功）。不要试图去改变某个产品的风格，成功率接近于0。人是很难改变的，尤其是你处于弱势的前提下。除非你和产品私下打好关系。说白了，只要关系到位，一切都不是问题，但这个实现起来显然比我前面说的那些难的多，更多的是靠天赋，也靠人与人之间的缘分。

标题中的管理产品是说开发在职业成长过程中，学会去管理与产品相关的不确定性和边界。

最后永远保持清醒，不要和产品发生争执。在有可能擦枪走火的情况下，把产品拉到无人的地方讨论。因为争执一旦发生，产品可能没什么事，你肯定会被减分。因为在多数组织里，技术是为产品服务的。要学会用“流程”对抗“组织风格”。不要带情绪，用事实说话。作为开发，要发挥开发的长处：

开发是“复杂度翻译器”

你能把：

• 混乱需求
• 模糊承诺
  翻译成：
• 风险
• 时间
• 依赖

👉 这件事产品做不了，老板也做不好。别再只闷头研究技术了，多练习一下复杂度翻译器这个能力，这个能力比技术还要重要。