技术方案
产品经理不用会写代码，但要看得懂技术方案，才知道需求能不能做、大概要多久。
产品经理为什么要懂技术方案
Section titled “产品经理为什么要懂技术方案”- 提需求时知道哪能做、哪做不了，少提不可实现的需求。
- 能看懂工期是怎么估出来的，评估排期更有底。
- 和前端、后端沟通时能听懂对方在说什么，减少来回。
一句话：前端管“用户看到和点到的”，后端管“数据怎么存、怎么算”。
| 岗位 | 主要负责 |
|---|---|
| 前端开发 | 页面展示、交互、调用接口、处理错误提示 |
| 后端开发 | 接口、业务逻辑、数据库读写、鉴权与安全 |
| 测试工程师 | 功能、性能、安全测试 |
| 服务器运维工程师 | 部署、监控、备份、故障处理 |
岗位划分详见 技术团队岗位。
产品经理不指挥技术分工，但要和双方确认接口字段和数据流向。
接口就是前后端之间的约定：前端发什么、后端回什么，都写死在文档里。
| 项目 | 说明 |
|---|---|
| 请求字段 | 前端传给后端的参数，标清名称、类型、是否必填 |
| 响应字段 | 后端返回给前端的数据，标清名称、类型、含义 |
| 错误码 | 出问题时返回的编号和对应文案 |
| 鉴权 | 怎么证明“你是谁”，如登录令牌 token |
示例（登录接口）：
| 字段 | 方向 | 类型 | 是否必填 | 说明 |
|---|---|---|---|---|
| phone | 请求 | 文本 | 是 | 手机号 |
| code | 请求 | 文本 | 是 | 验证码 |
| token | 响应 | 文本 | 是 | 登录令牌，后续请求要带上 |
| userId | 响应 | 数字 | 是 | 用户编号 |
| code | 响应 | 数字 | 是 | 错误码，0 表示成功 |
用户在页面上的一次操作，数据大致这样流动（文字版）：
用户操作 → 前端页面 → 调用接口（HTTP 请求）→ 后端处理业务逻辑 → 读写数据库 → 后端返回结果 → 前端拿到数据 → 渲染页面
- 前端不直接碰数据库，一切数据都走接口。
- 中间任何一环出错，都要有对应的提示文案。
交付成什么形态，直接影响怎么做、工期多久。
| 形态 | 适用场景 |
|---|---|
| H5 | 发个链接就能用，适合活动页、轻量功能 |
| App | 要用相机、推送、离线等系统能力，体验要求高 |
| 小程序 | 依托微信等平台，免安装、传播方便 |
| PWA | 网页形式但能“添加到桌面”、可离线，适合绕开应用商店 |
各形态的定义参见 产品分类术语字典。
约束要提前说清：预算、上线时间、必须支持的机型、必须对接的第三方系统，都是约束。
除了功能对不对，还要约定“好不好用、稳不稳、安不安全”。
| 类别 | 要约定什么 |
|---|---|
| 性能 | 响应时间（如接口 1 秒内返回）、并发量（如同时 1000 人在线） |
| 安全 | 数据加密、权限校验、防刷（限流、验证码、风控） |
| 兼容性 | 支持哪些浏览器、手机型号、系统版本 |
这些指标要写进文档，不然上线后“卡不卡、崩不崩”各说各话。
与技术团队的沟通清单
Section titled “与技术团队的沟通清单”| 事项 | 找谁 | 说什么 |
|---|---|---|
| 需求能不能做 | 技术主管 | 目标、场景、约束 |
| 接口字段 | 后端开发 | 请求、响应字段和错误码 |
| 页面交互 | 前端开发 | 交互流程、状态、异常提示 |
| 工期 | 技术主管 | 范围、优先级、交付时间 |
| 上线环境 | 服务器运维工程师 | 部署时间、域名、备份 |