夜雨聆风大家好，我是刀哥。
前两天一个粉丝私信我，说跟开发吵了一架。
原因很经典——他写了上万字的PRD，每个按钮、每种状态、每条异常链路全写清楚了。结果开发拿到文档基本不怎么看。
他气得半死。
这个场景你熟不熟悉？PM觉得写得越细越安全，开发觉得你写那么多我看不完。两边都有理，两边都委屈。
那问题来了：需求文档到底写多细才算够？
先说一个真相。
文档的详细程度，跟你和开发之间的信任成反比。信任越高，文档越粗。信任越低，文档越细。
你跟一个合作了三年的老开发说"把这个下单流程优化一下"，他懂的细节可能比你还多。你跟一个刚入职的应届生说同样的话，他能把按钮画错位置。
所以"多细"没有统一答案。但有一个判断标准：当开发打开文档后，需要找你确认的问题不超过3个，这个粒度就够了。
超过3个？你写少了。一个都不问？你写多了。
那具体怎么写，才能让开发不骂娘、自己也省事？
根据我这么多年的实战经验，总结了一个"三三三法则"。
先说什么事不需要写
你做的是App还是小程序还是PC后台？你们团队用不用组件库？有没有设计规范？这些东西不需要写进PRD，放团队wiki里就行了。
大多数PM的文档废话就废在这儿——长篇大论当前产品的架构、用户画像、行业背景。这些东西开发要么知道，要么你开个会五分钟就能讲清楚。
真正需要写进PRD的，只有三块内容。
第一块，改了什么。这次需求和上一次相比，新增了什么、变更了什么、删除了什么。这是给开发看的"变更日志"，让他一眼知道这次要动哪些地方。
第二块，怎么做是对的。正常的业务流程、各状态的预期表现、用户操作后的反馈。这是给开发看的"标准答案"。
第三块，什么情况是错的。异常链路、边界条件、错误提示文案。这是给开发看的"防坑指南"。
字数要精炼，太多了真看不过来。
我知道有人要问了：那我不写清楚，上线出bug谁负责？
问题是，你写清楚了，开发就一定按你写的做吗？不会的。开发拿到PRD会自己重读一遍，自己理解一遍，然后按他理解的方式去写代码。你写得再细，也控制不了他的理解偏差。
那怎么办？别靠文档，靠评审
文档只是载体，评审才是核心。评审会上，你拿着文档一条条过。开发问什么你答什么。他理解偏了当场纠正。这才是解决问题的有效方式。
文档是让你跟开发对齐的工具，不是你的免责声明。
还有一个更扎心的现实。
很多PM心里有杆秤——文档越细，代表自己越专业。屁。
文档写一万字不叫专业，叫不自信。真正专业的PM，能用500字把一个功能说明白，让开发看完直接开始编码。他知道开发需要知道什么、不需要知道什么。
文档是手段，不是作品。
你花三天写了一份完美的PRD，结果开发花三分钟扫了一眼就开始做。你觉得自己被冒犯了。
但反过来想：你真的需要他逐字逐句读完吗？不需要。你只需要他理解你想要的，做出来符合预期。
那就够了。
写在最后
文档这件事，网上有无数模板。但模板只是形式。真正决定文档质量的，是你对自己功能的熟悉程度，是你跟团队之间的默契水平，是你的表达能力。
文档写得细，开发不看。文档写得粗，开发骂你。
核心不在于你写多少字，在于你写的每一句话都打在开发最关心的点上。
你用什么标准定文档粒度？评论区聊聊。
近期热文：
