适用对象:产品、前端、后端、测试、研发小组长
目的:让研发不追问就能开工、测试看完能写用例、金融需求不出资损
维护:研发小组长

一、PRD 该写什么(产品交付标准)

判断一份 PRD 是否合格的唯一标准:研发看完能估工时,测试看完能写用例。 做不到就是不合格,评审时打回。

必备模块

最常缺失、也最致命的三块:异常流(7)、计算规则(8)、非功能(11)。
产品常只写 happy path,这正是评审要卡的地方。未定义清楚的字段,不允许进入排期。

二、需求到上线:研发小组长推进流程

小组长控的是节奏和交接点,不是自己埋头写代码。

需求评审 → 技术方案 → 任务拆分/排期 → 并行开发 → 联调 → 提测 → 回归 → 上线/灰度 → 复盘

1. 需求评审(卡入口)

• 拉齐产品 + 前端 + 后端 + 测试。
• 逐条钉死模糊点、冲突点、缺失的异常流和计算规则,当场确认或会后补。
• 产出:确认后的需求 + 明确的"本期不做"清单(防甩锅)。

2. 技术方案(卡设计)

• 后端先出:数据模型、接口契约、状态机、幂等/一致性方案、定时任务设计。
• 先定接口再并行开发——接口文档(字段、类型、错误码)是前后端解耦的合同。
• 小组长 review:边界、错误路径、并发、回滚代价。

3. 任务拆分 + 排期

• 拆到 1~2 天粒度,标清依赖关系与 block 关系。
• 明确联调点、提测点。

4. 开发中

• 接口先 mock,前端不等后端。
• 每日同步阻塞点,小组长扫清跨人依赖。

5. 联调 → 提测 → 回归 → 灰度上线

• 提测要有自测报告(改了啥、影响面、SQL/脚本变更)。
• 金融类必须灰度 + 可回滚 + 对账,不允许全量裸上。

三、给前后端的交底(以「理财发息」为例)

金融需求最怕口径不清,少一项就是线上资损。以下是小组长该输出的权威交底。

给后端(计算与周期是命门)

① 起息规则

• 起息日:T+0 / T+1 / T+N(如"申购日次日起息")
• 计息截止:赎回日算不算息("算头不算尾" or "算尾不算头")

② 计息公式(白纸黑字)

利息 = 本金 × 年化利率 ÷ 计息基准 × 持有天数
计息基准:365 还是 360?(按产品指定)
单利 or 复利?

③ 发息周期

• 日结 / 周结 / 月结 / 到期一次性
• 触发时间点(如"每日 00:30 结算前一自然日利息")
• 跨月、月末(28/30/31)、跨年如何处理

④ 取整与精度

• 保留几位小数;向下取整 or 四舍五入(金融普遍向下取整,避免多发)
• 币种精度(USDT 6 位 vs 人民币 2 位)

⑤ 工程铁律(踩坑高发区)

• 幂等:定时任务重跑、消息重投,同一天只发一次 → user_id + product_id + 结息日 做唯一键。
• 时区:统一 UTC 还是 UTC+8,结算日边界在哪。
• 对账:每次发息落流水,可追溯可对账,禁止只改余额不留记录。
• 状态机:待结算→已结算→已入账,失败可重试,禁止中间态丢失。
• 并发:结息与赎回并发,加锁或乐观锁。
• 回滚:发错息用反向流水冲正,禁止直接删数据。

交底话术示例:
"本产品 T+1 起息,按 365 基准日结,每日 00:30 结算前一自然日利息,单利,利息保留 6 位小数向下取整,以 user_id+product_id+结息日 为幂等键写入结息流水表,余额变更与流水同一事务;结算失败进重试队列,最多 3 次,仍失败告警人工介入。"

给前端

• 字段口径:每个金额字段的单位、精度、展示规则(千分位、涨跌颜色)。
• 状态与异常:加载态、空态、失败态;按钮防重复点击(申购/赎回必做);金额输入校验(最小/最大/步长/余额不足)。
• 数据来源:金额相关一律以后端为准,前端不做金融计算(避免精度不一致)。
• 交互确认:涉及资金的操作二次确认,防误触。
• 时间展示:收益到账、结息时间的时区与后端对齐。

一句话总结

• PRD 好不好:看研发能否不追问就开工;卡点在异常流、计算规则、非功能。
• 推进流程:评审卡入口 → 接口契约先行 → 前后端并行 → 联调提测 → 金融必灰度可回滚。
• 金融交底:后端钉死"起息日、计息基准、周期、取整、幂等、时区、对账、回滚"八项;前端守住"状态/异常/防重/以后端为准"。