**这是Kevin的第 707** **篇****原创，**
**持续日更，做产品经理的创业斜杠青年。**
今在知乎上看到一个讨论
**“开发996，是产品经理无能”**
产品经理自然产生了共鸣，毕竟产品经理核心能力是需求调研、需求文档撰写、项目管理能力。
但由于需求文档大型互联网公司有自己的标准，在中小型企业每个产品经理撰写风格也有不同。导致同一个功能也有千奇百怪的需求文档，比如同一个搜索功能，会有不同的搜索逻辑，再加上公司业务不一样，搜索这个功能的复杂层度自然就不一样了。
还有在中小型互联网公司，**由于没有严格的版本管理、项目管理，造成在测试阶段发现无数BUG、和优化项问题，产品经理又将若干优化项问题变成了对应当前版本的新优化需求，优化需求又变成了当前版本要做的任务。**
**工作量就几何提升了，加班就自然是应该的了。**
上线时间节点仍然保持不变，反而需求变得更加“详细”，自然就需要加班完成了。
一个案例说明
下面这个例子是产品经理由于需求没有写清楚，同时产品验收阶段将优化项目当做当前版本任务的案例。
比如PMTalk的活动列表，由于在需求文档中没有仔细思考这一操作细节，文档没有要求做分类跳转如下，增加点击「线上活动」「线下活动」2个分类各自跳转单活动分类列表。
但在研发完成提测试中发现页面路径有点奇怪，点击「线上活动」跳转到了报名的活动详情。
**产生了路径访问不符合逻辑场景。**
1.在需求文档的逻辑是如下
个人中心-点击活动-跳转活动详情
2.在提交测试版本中优化为
个人中心-点击活动-点击活动分类-跳转到活动分类列表页
由此就增加了一个小优化需求。在中小型互联网公司没有严格的需求池管理，就被产品经理塞到了同一个时间一起上线。
同时有的产品经理还有老板的话语权或“尚方宝剑”，还会造成开发信息不对称，自然就“打黑工了”，拼命加班上线。
产品经理是需求上游，自然会影响开发
开头提到的问题，开发996、加班确实和产品经理自然有密不可分的关系
因此产品经理写需求文档、需求调研、需求跟进的严谨性，才可以减少在提测后造成上面页面路径、功能逻辑失误问题。
最快速做法是往往增加需求评审环节、和时间。技术团队严密的过一遍需求，同时项目经理严格梳理清楚需求下的功能点数量。
▲ 项目经理以项目管理软件输出需求数量和开发时间排期
同时产品经理的需求文档严格按照功能逻辑、页面路径、原型图中的字段说明一一写清楚。
**之前我有分享过需求文档怎么写，你可以看这篇文章**
[产品经理基本功（PRD）|将交互、业务逻辑、需求字段撰入文档](http://mp.weixin.qq.com/s?__biz=MzIyODYwMjY2OQ==&mid=2247495555&idx=1&sn=777a9b25304cdd09ec20e716955ba779&chksm=e84dc9c1df3a40d7252c7d3e899e29dc82b54f8e3912f3acc186b9b1157e9621169ce79e0be3&scene=21#wechat_redirect)
需求文档的3个小技巧
需求文档撰写的目的主要是搞清楚需求的层次、深度、边界三个点
**1.层次**
一个功能、一个系统有多上上下游的关联功能、系统。比如我们做活动报名系统就有活动信息流、活动详情、还有用户个人中心的票券状态。
**2.深度**
产品规划能力是需求深度表现，比如1.0做什么、2.0做什么、3.0做什么，一个产品设计的阶段、运营阶段。
**3.界限**
需求的复杂度要做多少、要做多久时间、多少资源的投入，是用第三方还是用付费工具来代替产品研发。
做到上面这三点，即可至少做一份不会太差的需求文档。但是要注意很多公司的开发并不看需求文档，所以仍然会需要需求跟进
需求跟进是什么
需求跟进要求的是产品经理严格依照版本来进行验收、或研发早期跟进项目研发进度以人/天为单位。
需求跟进需要产品经理主动出击，所以你看到比较佛系或内敛的产品经理要么在需求文档阶段、需求评审阶段做的特别细、投入精力才能够减少需求跟进的精力投入。
但有了需求跟进，至少也会和开发打成一片，让需求变成团队的任务和荣耀，而不是产品经理的个人YY。
产品经理只有花时间把需求调研清楚了，同时还要把需求文档、需求评审、需求跟进做的仔细了，另一方面也是帮助开发少加班了。
今天的分享就在这。
