第三篇：定位篇——技术产品经理的“三权分立”

聊到技术产品经理（TPM）这个角色，很多人第一反应是“不就是个翻译官吗？”
嗯，这话对了一半。翻译需求确实是我们日常工作的一部分，但如果你只把自己定位成传话筒，那基本就废了。

我个人习惯把TPM的核心权力拆成三块：需求权、排期权、验收权。这三权，说白了就是咱们在项目里的“立法、行政、司法”。
你想想看，如果这三权你一个都抓不住，那跟项目里打杂的有什么区别？

1. 需求权：谁说了算？

需求权，不是说你一个人拍脑袋定功能。而是指——当业务方、开发、设计三方对需求理解不一致时，你拥有最终解释权。

我在项目中遇到过最典型的场景：业务方说“我要一个报表”，开发理解成“拉个Excel”，设计理解成“做个可视化大屏”。
结果三方吵了三天，最后发现业务方其实只是想要个邮件推送的统计数据。

为什么会这样？因为需求权没有明确归属。

我建议你这样做：

• 每次需求评审前，先自己写一份“需求一页纸”，把核心逻辑、边界条件、验收标准写清楚。
• 遇到争议，不要拉群吵架。拉一个“三方确认会”，你主持会议，当场拍板。
• 需求变更必须走“变更流程”，不能口头说改就改。

2. 排期权：资源怎么分？

排期权，不是让你当项目经理去画甘特图。而是——在资源有限的情况下，决定“先做什么、后做什么、不做什么”。

说白了，排期权就是“砍需求的艺术”。
你想想看，开发资源就那么多，业务方天天催，老板天天问进度。如果你没有排期权，那项目节奏就会被别人牵着鼻子走。

我个人习惯用“四象限法”来排期：

优先级	紧急且重要	重要不紧急
高	核心功能、线上故障	技术重构、性能优化
低	紧急但不重要	不紧急不重要
处理方式	立即排期	排入下个迭代

我建议你这样做：

• 每个迭代开始前，拉一个“排期会”，让开发、测试、业务方一起过需求列表。
• 用“故事点”估算工作量，而不是用“人天”。故事点更灵活，能避免开发讨价还价。
• 排期一旦确定，中途不允许加需求。除非老板亲自拍板，否则一律排到下个迭代。

3. 验收权：质量谁把关？

验收权，是TPM最容易忽视的权力。很多人觉得验收是测试的事，跟自己没关系。
大错特错。

验收权，决定了“这个功能到底能不能上线”。
你想想看，如果验收权不在你手里，那开发随便写个半成品，测试说“功能通了”，业务方说“能用就行”，最后上线一堆bug，背锅的还是你。

我在项目中遇到过最惨的教训：一个支付功能，开发说测过了，测试说没问题，结果上线后用户支付失败，直接导致业务中断两小时。
后来复盘发现，开发只测了正常流程，根本没测异常场景。

我建议你这样做：

• 在需求阶段，就写好“验收用例”。不是测试用例，而是从用户视角出发的验收场景。
• 验收时，不要只看界面。要看数据、看日志、看异常处理。
• 建立“验收清单”，逐条打勾。有一条不通过，就不允许上线。

4. 三权如何平衡？

需求权、排期权、验收权，不是孤立的。它们是一个闭环。

• 需求权决定了做什么。
• 排期权决定了什么时候做。
• 验收权决定了做成什么样。

你想想看，如果需求权抓不住，你排期排得再好，做的也是错的东西。
如果排期权抓不住，需求再正确，也做不出来。
如果验收权抓不住，前面两权都是白费。

我个人习惯在每个项目启动时，就跟团队“约法三章”：

1. 需求变更必须经过我确认。
2. 排期调整必须经过我同意。
3. 上线前必须经过我验收。

嗯，这里要注意：三权不是让你去跟开发、测试、业务方对着干。而是让你承担起责任。
你有了权力，就意味着你要为项目的成败负责。

我曾经在一个跨部门项目中，因为三权没分清楚，导致业务方直接找开发改需求，开发偷偷改了代码，测试不知情，上线后出了大问题。
后来我强制要求所有沟通必须抄送我，并且每周拉一次“三权同步会”，把需求、排期、验收状态过一遍。

说白了，三权分立的核心就一句话：让专业的人做专业的事，但最终决策权在你手里。