执行与技术型 PM

spec 不是让工程默默实现的合同。它是一份结构化的论证,记录用户问题、期望结果、被界定的范围、明确的非目标、关键决策、未决风险与上线度量。这份「论证」本身就是交付物 —— 工程读完后应能就权衡进行有理有据的反对。如果 spec 里只有「做什么」,你写的是一张 JIRA 工单。

• 第 1 页结构:问题、用户、当前替代方案、成功度量、范围、非目标。
• 第 2 页结构:关键流程、已作决定、推迟的决定、未决风险。
• 第 3 页结构:上线计划、度量、回滚计划、排序依赖。
• 超过第 3 页的内容属于设计文件或工程 RFC,不属于 PRD。

一页 PRD 强迫你写得清楚。任何总工作量在 4 周以内的事项都应使用一页 PRD。只有跨团队倡议、合规相关或「重大押注」项目才用更长的文档。多数团队过度生产文档;字数与执行质量几乎无关。

• 问题:谁在受苦,我们怎么知道,多频繁。
• 结果:我们要换取的指标变化。
• 约束:预算、截止日期、依赖。
• 未决问题:点出来,这样它会被处理而不是被回避。
• 签字:谁说了 yes(DACI 的 Approver)、何时、对哪一版。

没有「中立」的路线图格式。每种格式都把团队推向不同的对话。日期型 Gantt 偏向承诺;Now/Next/Later 偏向排序;主题型偏向战略对齐;结果型偏向指标变化。选能创造你最需要的对话的格式,并每年重审。

• Gantt:最适合截止日期固定的合规项目;最不适合以发现为导向的产品。
• Now / Next / Later:最适合产品驱动增长;对财务和销售来说信号弱。
• 主题型:最适合做组合式思考;有失去战术细节的风险。
• 结果型:在领导层信任团队选路径时最佳;需要有力的 NSM。
• 混合:许多团队对外用主题—结果,对内用 Now/Next/Later,只有硬截止日期才用日期。

方法选择被低估理论化了。Scrum 适用于成熟系统中可预测的功能工作。Kanban 适用于支持流式的工作流。Shape Up 适用于互信稳定团队对赌注的塑形。SAFe 适用于需要跨团队协调的大型受监管组织。没有一种自动正确;每种方法的病灶都被详尽记录。

• Scrum 风险:估算戏剧、仪式疲劳、sprint 目标沦为墙纸。
• Kanban 风险:WIP 爆炸、缺乏明确的优先级地平线。
• Shape Up 风险:对信任的依赖、周期末债务、周期内进展可见度低。
• SAFe 风险:会议负担压垮速度;以仪式替代产品判断。
• 用你团队真实的病灶检验方法,而不是博文热情。

API(Application Programming Interfaces)定义系统如何向其他系统请求数据或动作。哪怕非技术 PM 也需要工作模型:REST、GraphQL、RPC、GraphQL 订阅、webhooks。词汇上的差异决定了哪些是容易、哪些是困难。理解 API 表面的 PM 在「暴露什么」「何时引入版本管理」「如何规划合作伙伴集成」上做更好的取舍。

• REST:面向资源(GET /users/123)。多数公开 API。
• GraphQL:由客户端定义查询;灵活,缓存难,后端复杂。
• RPC / gRPC:面向动作(如 CreateInvoice);强类型;通常内部使用。
• Webhooks:服务器对服务器的回调;「在某事发生时通知我」的合适工具。
• 幂等性:可以安全重试且无副作用 —— 计费与集成上不可让步。

数据库选择长期决定什么便宜、什么昂贵。关系型数据库(Postgres、MySQL)对 join 便宜,对无界规模昂贵。文档库(Mongo、Firestore)对灵活形状便宜,对关系型查询昂贵。键值库(Redis)对缓存与会话便宜,对分析昂贵。能读懂基础 ER 图、并问出「这个查询是有界的吗?」的 PM,会在两年里替团队省下六个月。

• schema 迁移是永久的 —— 每次迁移都是小型 Type-1 决策。
• 读 vs 写:分开扩缩。
• 索引:「突然」性能问题最常见的根因。
• 软删除 vs 硬删除:涉及合规与分析的影响。
• 拿不准时:问「数据放大 100 倍后,这个查询如何扩展?」

当系统与系统对话时,网络是不可靠的。队列(RabbitMQ、SQS、Kafka)吸收负载尖峰;重试处理瞬时故障;幂等键防止重复扣款与重复发送。承诺「即时」「实时」用户体验却不理解队列延迟的 PM,会让团队走向无法交付的架构。永远问:这是同步还是入队?

• 同步:用户等待,系统在 <1s 内响应;只适合短小确定性操作。
• 异步:用户得到确认,工作在后台进行;触及外部系统的事情都需要这个。
• 至少一次 vs 仅一次交付:决定幂等性需求。
• 死信队列:消息去那里死掉;应被监控,而不是被忽视。

中位数延迟会撒谎。用户体验由尾部主导 —— p95、p99、p99.9。一个中位 200ms 但 p99 为 4s 的站点,对 1% 的用户而言是坏的 —— 而那 1% 会是最响亮的。在意 UX 的 PM,在意尾部。

• 中位(p50):一半用户更短;几乎告诉不了你 UX 的事。
• p95:5% 请求更慢;「可接受」的边界。
• p99:1%;在 B2B 中,每个账户每天都会被打到。
• p99.9:千分之一;对高流量产品和 API 至关重要。

feature flag 是一个运行时开关,能让你把代码上到生产但不暴露给用户。结合按 cohort 的目标定向,它能实现渐进交付:1%、5%、25%、100%,在每一阶段观察指标。把每个有意义的变更视作 flag 化的滚动发布。代价很小;选择权很大。

• 用户可见的任何变更,都先放在 flag 后。
• 始终保留 kill switch —— 不重新部署也能回滚的能力。
• 始终设定 flag 清理时间表;旧 flag 会变成隐形的技术债。
• 把 flag 与指标 watch 配对 —— 退化时自动回滚。

上线不是「工程合并」。它包含沟通、销售赋能、支持就绪、遥测、成功标准与回滚。多数上线事故并非工程失败,而是清单失败。上线清单是 PM 拥有的、最有杠杆的工件之一。

• 上线前:遥测已验证、成功标准已记录、回滚计划已演练、沟通已起草、支持已培训、销售赋能就绪、beta cohort 反馈已纳入。
• 上线:按指标门控分阶段滚动、on-call 轮班知情、状态页就绪。
• 上线后(T+24h、T+7d、T+30d):指标复盘、定性反馈综合、上线流程回顾。
• 不要在周五或假日前上线 —— 除非你想要一个混乱的周末。

用一页周报替代状态会议。它把信号压缩成 90 秒可读的格式,让风险尽早暴露,并形成「承诺与交付」的公开记录。做得好,可消除 80% 的同步状态对话。

• 顶部:本周 NSM 与头条指标。
• 中部:在做的赌注、状态、信心、阻塞。
• 底部:本周需要的决策(指名 approver、截止日期)。
• 语调:具体而克制。不要营销语言。不要表情包风暴。
• 固定节奏分发(周五 16:00)。可预测性建立信任。

PM 在分歧上花的时间多过在共识上的时间。技能不是回避冲突 —— 而是早把冲突摊出来、让它结构化、并由指名决策者解决。多数产品「文化问题」其实是穿了戏服的「决策权问题」。

• 在会议前以书面形式摊出分歧;减少情绪升级。
• 用 steel-manning:在反对前,把对立观点说得比对方更强。
• 用书面形式升级,不要在会议里突袭;指名 approver 决定。
• 决定后 disagree-and-commit;反复翻案具有腐蚀性。

PM 与工程之间的信任,是产品中最被低估的资产。被信任的 PM 获得范围弹性、技术支持与更快的交付。不被信任的 PM 得到防御性估时、范围僵硬与神秘的延期。信任建立在无聊的习惯上:偶尔出现在站会、把代码读到能看 PR、为技术债在干系人面前发声、并且永远、永远不在公开场合责怪工程。

• 每季度花半天影子参与一次 on-call 轮班。
• 阅读你没参与过的事故的 post-mortem。
• 公开为技术债与可靠性投入发声 —— 不要让工程独自承担。
• 出现滑坡时,在外部承担责任。工程会在内部回报你。