|
最近刚好负责的一个UGC模块已经进入文档阶段。本周为各位朋友带来一个产品基本功的分享——产品需求文档，这一篇分享将是我3年产品进阶到今天，个人要求需求文档目前的撰写标准。 从腾讯出来已经有大半年，曾经在腾讯工作期间，当时我做的是偏向运营的产品经理，虽在腾讯的时间不长，但期间完成相应任务时，我的导师一直要求我，做什么事要想清楚为什么这么做？ 个人认为：做的很细、复杂与否不是问题，而是认识到做这件事的理由与目的。 3年的产品道路中，常常对于产品新人困惑的交互和功能字段解释，如何将巧妙加入在需求文档中？如果这样做下去，相信开发和测试一定会少很多疑惑，所有的坑已经在文档中被搞干净啦~ 一、需求概述 在需求概述前关于一些基本设置，我采用以WORD WEB版式，并且字体我一直系统是微软雅黑。
WEB版式方便横向内容浏览，字体微软雅黑我总认为看着比较舒服。 在需求概述中，我首先将一个开文数据框图，表示目前该需求的大体情况，让开发或测试相应人员指导该文档是做什么、文档当前的状态、该需求负责人是谁、修订版本（当前文档的修订版本，并不是产品迭代版本
在做产品助理的时候，这个文档的开头基本就在这里结束了。但随着在后期的产品积累上，，我将开头添加了项目背景概述、需求来源、关联负责人、需求执行成员（项目成员）、需求执行周期（项目周期），下面我通过截图的方式更新以上 1.背景概述 目前UGC模块需要优化，提升用户体验。 当前UGC模块功能为：发帖功能、点赞功能、评论功能、转发功能 用户执行发帖流程：发帖入口——输入内容——发帖完成 目前UGC模块功能进行了优化，比如增加了过滤功能，用户可以屏蔽相应的不感兴趣内容，增加了话题功能，用户可以对感兴趣内容进行选取。 将用户发帖流程进行优化，在不阻碍发帖体验的情况下，增加了话题路径，丰富了用户选择性，增加了平台内容多样化 2.需求来源 本次需求来源负责人：KEVIN，部门：产品部 3.关联负责人
4.需求执行成员
这一点要说明的是，很多团队可能没有以上职位，尤其是在创业团队，一人做多事，因此可以将做这个项目的人员拉进来。可能PM会做UI、UE，类似这样的情况，也需要填表。 当然敏捷开发的创业团队，可能会当面沟通，文档中存在执行成员与否反而不重要，本来人就少，大家都心知肚明啦。 5.需求执行周期
这里要说一点，这个是适用于我目前的团队，因为有2次评审。但是开发需求评审的周期和UI评审的周期是反复、漫长的，并不是将每一次的评审开会时间填上去，而是将相应周期。 如：目前评审处于开发需求评审，UI还没做，那么就是开发需求评审，这个时候往往会干掉一些需求，PM需要及时收集并且调整。 二、更新记录 这一块是我认为3年工作中，最为重要的一块。最初做产品助理时候，文档更新可能就是很简单的一句话，但随后发现，开发与测试人员每次最关注的就是你更新记录，他可不想每次都去查找那一小部分更新内容。 这个更新记录可能是在开发需求评审后，也可能是开发中进行更新，毕竟有一些需求是开会中不会遇见的，只有在正在开发中才会发现不合理。
这里值得注意的是首先分为4个属性 新增 删除 修改 新建 新建默认为相应模块的首次使用，后期对于文档的修改用新增、删除、修改即可，并且这里需要将修改、新增的地方加入超链接，方便开发进行查阅。 三、需求结构图 这里主要是设计和技术开发人员了解产品需求的结构，描述顺序为主功能—子功能—子功能详情页
并且这里建议将每个页面超链接后面的页面详情，方便及时相应人员查看。可以链接的地方为功能模块—子功能模块——详情页面，都做可链接。 当然这样式比较费时间的，通吃我是只有梳理结构图，没有做链接形式。 四、数据间关系
|
