产品文档怎么整理？
在悟空问答上的123个问题，只写接地气的科技内容，欢迎关注。
产品文档，是产品经理必须要懂得的基本技能之一，尤其是互联网企业。
产品文档，也是让很多初级产品经理非常头疼的事情。
到底怎么样才能书写一份比较完善的产品文档呢？其实很简单，我们简单来谈一谈。
为什么会有产品经理？实际上产品经理一职，尤其是互联网产品经理，在2010年以前都是不存在的岗位，一般都由技术部门或运营部门的相关人员负责，或者说直接由老板负责。但是自从移动互联网发展起来之后，产品经理角色突然兴起，变得尤其重要，这样的出现，其实来自于分工的变革。
过去的互联网公司，或者说业务形态，主要是以市场和运营为主导，主要是为了卖服务而工作，所以只要实现需要的功能即可，比如QQ，实际上就是提供了各种各样的服务，并且市场足够垄断，所以可以通过各种钻让消费者充钱，我给你服务。
自从移动互联网发展以来，互联网公司快速崛起，仅仅实现功能的需求已经无法满足用户，大家都在谈一个字：用户体验。谁的体验更好，就用谁的；谁的产品更新快，就用谁的。
所以，专门负责用户体验，负责整体规划的产品经理就诞生了。
为什么需要产品文档？产品经理只是一个职业，而不是一个职位，并不代表就是“经理”。
产品经理与UI、工程师、运营、市场一样，都是一样的，只不过产品经理所起到的作用是至关重要的。简单来讲，产品经理的主要作用，就是设计出运营、市场所需要的产品原型，并且交由技术部门开发，在预计的时间交付，并且负责后续的数据跟踪和迭代。
说白了，就是运营和技术之间的桥梁，把运营的需求翻译给技术部门听懂。而需求文档，就是翻译之后的重要产物。
需求文档包含哪些内容？我听了很多课程，也包括像“三节课”这样备受好评的网课。不过总是觉得他们把产品文档讲得太过于复杂，反而让初学者摸不着头脑。其实就我的经验来看，产品文档主要是四块内容:
1.需求背景：讲清楚目前项目的背景，基础状况，基本数据。说明本次需求开发要实现的功能，预计的开发周期，以及所调配的资源等信息，让技术人员对要做的项目有一个大致的了解。
2.业务流程：这一块是产品文档的重点，也就是需要产品经理画出业务流程图，并且备注好业务逻辑。业务流程图，也就是新添加需求所要实现的所有页面，并且每一层级的页面通过怎样的按钮或操作实现，页面原型可以画得详细一些，但是千万不要上色，会干扰UI做设计。业务逻辑备注，也就是在不同状态下产品所做的不同处理，比如同样一个页面，登录的用户是怎样的，未登录的用户是怎样的，必须要备注清楚。
3.数据打点：没有数据接入的产品，都不能称之为产品。所有的产品都必须要埋点进行数据采集，每个重要的按钮，每个重要的页面。点击、曝光、浏览三个维度去采集，到一定时间段后你就知道哪些功能是用户常用的，哪些是不常用的，用于后期迭代的重要分析手段。当然具体埋点工作则由技术来负责。
4.需求复盘：一般需求上新一周后，就可以做需求复盘了，分别从需求设计、需求开发、上线运营三个时间段去反思犯的错误，进行总结，避免以后再犯类似的问题。
基本上需求文档，就包含这四块的内容，涵盖了从接受该项目，到最后上线运营的整个时间段。当然，仅凭需求文档是不够的，拉着运营和技术开需求分析会也是产品经理必须要做的事情。
除了需求文档还需要什么？单说产品经理的技能，光是需求文档肯定不行。需求调研、业务流程图、页面原型图，页面流程图、需求文档、数据分析这些是基本功。
还要有良好的沟通技能，能够顺利与运营、设计和技术沟通，制定相应的方案。那就必须要懂得基础的运营、设计、技术相应知识，不然别人忽悠你都不知道。
对于项目进度的把控也是必不可少的，学会用甘特图管理任务进度，每天定时做好沟通和监督项目，确保产品能够按时交付。
当然，也要有勇于担当的责任。无论中间谁出了错，只要产品出现问题，只要没能够按时交付，产品经理都应该第一时间站出来扛起错误，及时改正。这样别人才会愿意“为你开发产品”。
产品经理确实是一个吃力不讨好的活，但是又有谁懂得产品上线时的那种成就感呢？
PM本来就是个分工合作的协调者，所以文档整理，最多能管好自己的，至于团队中其它角色的，还是交由各部门自己去管的好！
第一个问题：让团队人员知道自己做了些什么？
团队成员做了什么是由项目经理安排的，因为除了产品以外，团队成员中UI、FE、RD、QA都是有具体产出的，所以他们很明确自己做了什么，而这个环节其实个人认为最有意义的事情是，需要告知他们所做的能对业务有什么影响，比如通过设计推广页让渠道流量提升了20%、比如设计的后台系统让人效提升了1倍等等，因为他们在晋级的时候也是需要数据做支撑，而不是做的具体事情；
第二个问题：当项目或者产品结束后团队人员可以有个回顾或者在做之后项目的时候可以借鉴。通常情况下，团队成员的文档都是管理在自己团队的平台中的：
1.UI的素材肯定是自己存着或者上传到CDN上、最后的确认稿也应该有统一的管理平台；
2.FE/RD有自己的代码管理系统，说明文档稍微专业点的都会有单独的版本管理系统，记录每次迭代信息；
3.QA的测试文档和PM的产品文档都是自己保管，稍有不同的是，QA的测试文档会发给研发等人员，而PM得产品文档会定稿后在形成相应的使用文档；
而你说的借鉴，我个人理解的是：
1.研发以后一些接口的定义与调用，或者是一些算法的借鉴等；
2.产品手册一个规范格式的借鉴；
3.设计元素一些参考；
4.QA测试的标准规范等；
富建家具版权声明：对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！
