2. PRD的受众分析

写PRD这件事，我踩过最大的坑就是——一份文档想讨好所有人。

结果呢？工程师嫌太啰嗦，设计师说没重点，测试看不懂逻辑，老板直接扔一边。嗯，这锅得背。

所以这一章，咱们聊聊PRD到底写给谁看。说白了，不同角色关注的点完全不同。你不可能用同一套话术搞定所有人。

2.1 工程师：我要的是「怎么做」

工程师是PRD的第一读者。我个人习惯，写PRD时脑子里先过一遍：这段逻辑，开发能不能直接上手？

工程师最烦什么？模糊的需求。比如「用户能快速找到商品」——什么叫快速？3秒还是10秒？

他们关注的核心点：

• 输入输出：数据从哪里来，处理后变成什么
• 边界条件：用户没登录怎么办？网络断了呢？
• 异常处理：接口超时、数据为空、并发冲突
• 性能要求：接口响应时间、并发量、数据量级

举个例子，我之前写过一个搜索功能的PRD：

// 错误写法
用户输入关键词，系统返回相关商品。

// 正确写法
输入：用户输入字符串（长度1-50字符，去除首尾空格）
处理：
  1. 调用搜索接口（POST /api/search）
  2. 参数：keyword, page, pageSize
  3. 超时时间：3秒
  4. 空结果：返回空数组，前端展示「未找到相关商品」
异常：
  - 网络错误：展示「网络异常，请稍后重试」
  - 接口500：展示「系统繁忙，请稍后再试」

你看，这样写，开发连问都不用问，直接开干。

2.2 设计师：我要的是「长什么样」

设计师和工程师的关注点完全不同。他们不关心数据怎么流转，只关心用户看到什么、怎么交互。

我遇到过最尴尬的事：PRD里写「弹窗提示用户确认」，结果设计师做了个全屏遮罩，开发说「不对，应该是底部弹出」。三方吵了半小时。

设计师关注的核心点：

• 页面状态：加载中、空数据、错误、正常展示
• 交互细节：点击、滑动、长按、手势
• 文案规范：按钮文字、提示信息、错误文案
• 视觉层级：什么信息最重要，什么可以弱化

我现在的习惯是，PRD里附上关键页面的线框图，哪怕只是手绘的。重点标注：

状态	展示内容	交互说明
加载中	骨架屏 + 旋转加载图标	自动加载，无需用户操作
空数据	插画 + 「暂无内容」文案 + 去逛逛按钮	点击按钮跳转首页
网络错误	插画 + 「网络开小差」文案 + 重试按钮	点击重试，重新请求

这样做的好处是，设计师拿到PRD就能直接出图，不用反复确认。

2.3 测试：我要的是「怎么测」

测试同学是PRD的「质检员」。他们拿着你的文档，一条一条写测试用例。

你想想看，如果PRD里写「用户可修改个人信息」，测试会怎么测？

• 修改姓名：正常输入、特殊字符、超长字符、空值
• 修改手机号：格式校验、已注册手机号、未注册手机号
• 修改头像：选择图片、取消选择、图片过大、格式不支持
• 并发场景：同时修改姓名和手机号

测试关注的核心点：

• 功能逻辑：每个操作的前置条件、后置结果
• 边界值：输入长度、数值范围、时间格式
• 异常场景：网络中断、权限不足、数据冲突
• 兼容性：不同机型、系统版本、屏幕尺寸

我建议在PRD里专门加一节「测试要点」，把关键场景列出来：

测试要点 - 用户注册功能
1. 正常流程：输入正确信息 → 注册成功 → 跳转首页
2. 手机号格式：11位数字、含空格、含+86、含特殊字符
3. 密码规则：6-20位，含大小写字母+数字
4. 验证码：60秒倒计时、重新发送、错误验证码
5. 异常场景：手机号已注册、网络超时、服务器500

这样做，测试同学能直接复用你的文档写用例，效率翻倍。

2.4 老板/产品负责人：我要的是「为什么做」

老板看PRD，通常只花5分钟。他们不关心技术细节，只关心这个功能值不值得做。

我见过最离谱的PRD，开头直接写技术方案，老板看了三页就放弃了。嗯，那项目后来被砍了。

老板关注的核心点：

• 商业价值：能带来多少用户、收入、留存
• 投入产出比：开发周期、人力成本、预期收益
• 风险控制：有没有法律风险、技术风险、市场风险
• 优先级：和现有项目比，哪个更急

所以，PRD的开头一定要有「背景与目标」部分。我通常这样写：

背景：
- 当前注册转化率仅32%，低于行业平均的45%
- 用户反馈注册流程繁琐，需要填写7个字段

目标：
- 将注册转化率提升至40%以上
- 将注册流程缩短至3步以内

预期收益：
- 每月新增用户增加约2万人
- 按5%付费转化率，月收入增加约30万元

开发周期：2周（3人）

你看，老板扫一眼就知道：值不值得做、多久能上线、能赚多少钱。

2.5 一张图看懂：不同角色的关注点

为了方便你记忆，我画了个简单的对比图：

2.6 总结：一份PRD，四种写法

写PRD不是写小说，不需要统一的文风。我的做法是：

• 给工程师看：技术方案、接口定义、异常处理
• 给设计师看：页面状态、交互细节、文案规范
• 给测试看：功能逻辑、边界条件、测试要点
• 给老板看：商业价值、投入产出、风险控制

你可能会问：那PRD到底怎么写？

我的答案是：按角色分层写。开头放老板关心的背景和目标，中间放工程师和测试需要的技术细节，最后附上设计师需要的交互说明。

这样，每个人都能快速找到自己关心的内容。嗯，这才是PRD该有的样子。