最近接触了很多预备进入产品经理岗位的人（转岗+应届毕业生），大家多半都很有一套自己关于产品的看法，但是随着聊下去基本上却对互联网产品经理的日常工作一无所知。在我看来有些“本末倒置”了，我也想开个大坑，讲一些产品经理日常工作最常接触的事情。 那就先从如何写一份“完美”的需求文档开始吧，毕竟PRD是产品人最基本的武器。

一 需求文档的载体

Word/Excel/PDF 在网上有各类Axure为载体，造型华丽的文档模型，我觉得是本末倒置的，文档作为需求的依据，是与多方沟通的载体，重要度排在首位便是通用性，用许多花里胡哨的工具，未必所有人都打得开。 PDF格式我更推荐是和企业外部人员沟通使用，其一样式不会乱，其二不会被恶意修改。

二 需求文档的框架

*并非所有项目都要按照该框架，在使用途中要注重适当裁剪，互联网产品还是要追求“短平快”的。

1 修订记录

因为现阶段的互联网产品迭代在多半采用了敏捷开发的生命周期，需求从开始到结束，不断进行着增量且迭代。 需求都是渐进明细，其一随着交互/视觉/开发不断开展，总会有细节进行改动，甚至整块的需求被砍或者修改；其二，对于人天较长期的项目，需求方在参与途中会不断添加新的需求点进来。 对变更进行记录其实是变更讨论的一种结果，其一，保证需求参与人员明确项目变更点；其二，方便产品经理核查项目是否偏离范围基准；其三，保证了多个产品协同的效率和定责。

2 产品价值

这一部分，内容上比较务虚，实际作用是用来评审或者对外衔接的时候，和别人开场说的第一句话，也可用于立项申请时描述需求背景。

3 用户角色

这一部分，我是采用了项目管理中的干系人登记册+RACI矩阵杂糅。 外部用户的用户故事一定要好好思考，你做了什么（产出），用户用来干什么（成效），能为用户带来什么（影响），成效和影响部分千万不要意淫，要有实际的用户调研或数据支撑才行。填写外部用户故事是提醒产品人需求是为用户而做，并非是做给运营或是领导（当然事实并非总是如此），这样撰写文档时会思考到用户体验的问题和用户想看到得到什么。 内部人员只需要关注一点，每个参与方需要有且只有一个终责人，出现问题只联系此人，不然之后实施中对接同一职能多人耗时耗力。

4 主体功能

粗略记录需求包含功能点以及各功能点重要层次，基本评审需求也就按照这个顺序。排列要按照一定逻辑，我个人偏好如下：第一部分：纯前端功能（包括前端对外联调）；第二部分：前端+服务端需要联调部分；第三部分：纯服务端部分（包括对外联调）。按照这个逻辑是避免多方人员在评审时，东一榔头西一棒槌的，一个前端开发却要听和自己关系不是太大的服务端需求细节，这样评审体验很不好。

5 产品结构

和主体功能相似，只不过会将“主体功能”中的需求转化为原型，流程之类的。

6 信息结构

整个需求文档的核心部分，不要让需求文档只在描述你想要什么，也要涉及一部分怎么做，这样才会显得专业。逐渐熟悉了自己负责产品的数据结构，也会让产品经理在承接需求、评审需求时占有更大的话语权。 在此处要罗列出需求需要涉及的数据，不管是现有的还是新增的，自制的还是外接的。要尽可能的能细化到数据对应字段，这样既能减少开发大量时间也能帮助产品了解自己的需求。 写这部分之前，你需要尽可能了解自己负责的产品，数据库的结构和包含了哪些字段，这样做一定程度避免一些异想天开的需求诞生。产品经理本身肩负外部接口文档流转、保存的职能的，所以了解数据也是近水楼台先得月。

7 产品明细

整篇文档，篇幅最长，耗时最久，修改最多的部分，也是文档的灵魂部分，该部分包含了，需求的原型、规则、细节点等等一系列细枝末节的事情，至于到底做了什么就由此处决定。 此部分是真正考验一个产品见识、功力和境界的部分。做好该部分只有不断竞品分析，不断学习才行。对于新人产品来讲这部分多数是将领导需求逐渐明细，只要保证逻辑清晰，要将每个功能点撰写清楚即可。

8 评估数据

KPI永装我心，需要了解自己负责产品线的核心考察指标。写需求，做产品的时候要三省吾身，符合KPI么？做了有用么？投入产出是多少？ 不要总是为了改变世界而去写需求，在公司工作很现实的，宝贝儿~

9 项目节点

将需求评审时拟定好的里程碑记录好，这是后续跟进项目的有力武器。进行晨会时，只需要将此部分拿出来核对一下，哪个部分需要跟进，哪个部分状态良好便一目了然。不然最终延期或者完不成你都不知道从哪一步开始崩盘的。 到这儿基本上算一份完整的需求文档框架了，面对不同的需求场景要学会进行裁剪或者增添，前期可以对流程“生搬硬套”，逐渐你也会形成自己文档风格。

讲些闲话：

现在社区大多数文章基调还是上升到理论高度的，更多的是讲述一种思想或者方法论，也就是所谓“道、法”的部分，很少涉及到去讲工作中一些事情具体怎么去处理，但其实新人产品更需要些对“术”的讲解，这样才不至于在日常工作中太过冒失，只会理论不懂执行，给人留下“纸上谈兵”感觉。 产品这份工作在脱离了初期之后，你就很难静下心来去打磨你的文档了，不说别人，我在自己负责两条产品线后大多数时间都去处理项目进度问题和多方沟通上，分到撰写需求文档的时间自然就会减少。所以还是要在工作前期打好基础，不然会很难再拿出时间再去做这些对业务帮助较少的事情了。

Tips:需要文中描述的文档模板的，可在留言处索取，我会逐一发送，谢谢。