|
在分享今晚的内容之前，我先跟大家讨论一个问题，产品经理为什么要写需求文档，当然这个问题在我上周面试一位刚入职的产品经理的时候也曾问道，所以作为产品经理我们自己必须要清楚什么是需求文档，为什么要写它。 继续我们的话题，产品经理为什么要写需求文档，首先我们将这个问题拆分一下，为什么写，写需求文档是方便让我们的项目经理、程序、设计师、测试工程师、运营、市场，包括我们的老板等相关人员知道我们的产品要做成什么样子，产品需求文档是对商业需求文档和市场需求文档通过产品的角度，用产品经理的专业知识进行更专业化、具体化的描述，将概念化的文档转化为图形化的一个重要文档，同时写需求文档的一个重要目的是让我们的产品设计更加合理，减少疏漏提高项目的开发周期，开发效率。 以上内容是对为什么要写需求文档这样一个目的、概念进行了一个概述，下面我们再来分析，需求文档究竟该怎么写。 我身边的产品经理曾抱怨，自己写了一百多页的需求文档，我们程序根本不按照我写的需求来实现，最终上线的产品，很多流程都走不通，用我自己的话来讲，我这位产品经理朋友可能遇上了富有想象力的程序。这也是我接下来跟大家讨论的第二个话题，我们的程序究竟想要一份什么样的需求文档。这里为什么要强调程序，因为产品的最终形态是有程序来实现，所以我们的需求文档一定要让程序看懂。 这里我将程序分为了3个等级，分别是高明的程序、富有想象力的程序和坑爹的程序。 高明的程序已经具备了产品思维，当你给他一个需求的时候，他会协助你一起分析需求，理清楚这个功能要达到一个怎么样的程度，让什么样的用户来使用更方便、易用、实用、好用。遇上这样的程序，产品经理都不需要写需求文档，你可能只是画画流程图、原型图，最终上线的产品跟产品经理想象的几乎无差异而且还会超出产品设计时的期望。 富有想象力的程序他们偏向于图形化的东西，他们在看需求的时候擅长看信息结构图、业务架构图、原型图，对于长篇文字他们懒得看，所以遇上这种类型的程序，我们尽量多画图，对于一个比较长的需求，我们尽可能用一两句话讲清楚，细节部分多用图形来描述。 坑爹的程序，为什么是坑爹的程序呢，因为你给他需求稍不留神去盯任务，去跟着测试，他就会实现出来一个用起来相当吃力的功能，比如保存完不刷新页面，返回要连续点两次，跳转会到达错误的页面等等，遇上这样的程序只能怪产品运气差，跟这样的程序协作，在过程当中一定要流程化，包括对产品功能的叙述不但用图画出来，还要用详细的文字来叙述清楚，如果稍不留神忽略了一个细节，他们会首先想办法把逻辑串通，只有在串不通的情况下，他们才会找产品，所以遇上这样的程序是比较危险的，今天做什么明天做什么我们一定要盯紧，对于当天完成的任务当天要确认，所以我认为遇上这样的程序是比较坑爹的。 以上我是对程序进行了等级划分，那么我们的需求文档究竟有没有必要写，如果写究竟应该要怎么写，那我们要做到的第一步就是去了解我们的程序是高明的程序、富有想象力的程序还是坑爹的程序。 写需求文档，我常用到的工具是Axure,因为Axure本就有强大的文档编辑能力，而且还可以生成网页，所以我的做法是将Axure里面的文档生成网页，上传到只有内网可以访问的服务器上，我将模块分为了产品、竞品、测试、工作动态和需求提交五个模块，点击产品下拉菜单，选择相应模块，进入需求详情，就能看到该功能的需求描述、用例图、流程图、交互原型等，所以协作起来十分方便。工作动态主要记录团队内人员当天要做的事情，需求提交我在表单大师创建了表单，内部人员可以在上面提需求。 下面我们就来说说需求文档的内容，究竟该怎么写需求文档。产品经理为什么要写需求文档，首先我们将这个问题拆分一下，为什么写，写需求文档是方便让我们的项目经理、程序、设计师、测试工程师、运营、市场，包括我们的老板等相关人员知道我们的产品要做成什么样子，产品需求文档是对商业需求文档和市场需求文档通过产品的角度，用产品经理的专业知识进行更专业化、具体化的描述，将概念化的文档转化为图形化的一个重要文档，同时写需求文档的一个重要目的是让我们的产品设计更加合理，减少疏漏提高项目的开发周期，开发效率。 1、文档的命名和编号，如V1.0,V1.1； 2、文档的版本历史，文档的版本历史需要写清楚文档的版本号、修改原因、修改日期、修改人、修改原因和确认人； 3、目录，方便我们的阅读人员快速找到自己所要看的内容； 4、引言，对该产品的一个整体概述、产品的目标、产品的蓝图规划，我们的产品要做成一个什么样子； 5、需求概述，主要描述我们的产品满足用户什么样的需求，我们的用户有什么样的特征，我们产品对运行环境的要求，设计和实现的上的要求规范、项目计划和我们开发过程中可能会遇到的风险； 6、功能需求，主要描述我们产品当中不同功能的不同用途，业务规则，比如我们的这个功能要做到什么程度，什么样的用户来使用，在什么样的场景下，解决用户什么样的问题，功能需求还包括用户用例图、流程图、界面功能图和交互原型图； 7、可选方案，为我们产品准备两个或两个以上的备选方案，不至于产品的发展陷入困境而不知如何处理，备选方案可以从团队的人、财、物、事、以及对自然灾害、政策原因等多方面来考虑； 8、效益成本分析，比如我们要做这个产品估计要多长时间来完成，需要多少人、需要多少资金，最终要达到怎样的指标才算合格，包括做一个小功能的预估分析； 9、整合需求，比如我们需要跟合作伙伴合作开发某个功能，或者是内容的置换、用户的置换等通过合作来产生更高的商业收益； 10、测试需求，对测试人员的能力要求、内侧人员的要求，测试规范的制定，以及测试出问题以后怎么解决，怎么确认，不至于在测试过程中出现不必要的问题； 11、非功能性需求，包括对产品的运行速度、用户安全、用户隐私、产品的可靠性、易用性、维护性、可移植性、扩展性、可替换性等需求，对产品的营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等需求； 12、运营计划，当我们产品上线后怎么来引流，引流的途径有哪些，以什么样的方式来引流，引流进来以后怎么将我们的用户促活、维系、转换、付费、持续付费，以及做多大规模的活动运营等； 13、版本规划，版本规划主要描述我们当前版本计划做什么内容，需要多少人来做，做的过程中怎么来协作，协作流程是怎样的，以及我们下个版本计划要做什么。 今晚的内容就分享到这里祝大家工作愉快，原文首发于我的个人微信公众号产品精益讲堂，欢迎交流谢谢！ |
|
|
