您现在的位置: 高手心水论坛 > 高手心水论坛 > 正文
需求文档你怎么写?为什么这么写?如何写一份
更新时间:2019-09-17

  很多产品新人,入门产品时,最想先了解的都是如何画原型,如何写需求文档,这很奇怪。就像在平台上可以搜到很多关于需求文档的文章(截至当前,通过搜索关键词“需求文档”,有610条搜索结果),告诉大家需求文档要怎么写,却很少有说为什么这样写的?

  大家把关注点都在放在如何实现,如何呈现,却没有关注为什么这么写?像很多大咖常说的术与道,术重要,道更重要,知其然更要知其所以然。

  碰到任何问题,最长见的思维方式即为:问题三要素——是什么、为什么、怎么做。这是几乎所有行业、所有人群面对事情时,最常见的思维方式。

  笔者认为基于最经典、高效、实用的思维方式的基础上,可以每个人针对不同的知识体系、思考方式、经验总结等维度,总结出自己的思维方式。

  在特定的时间、特定的地点、特定的人群因为特定的原因而做了特定的事件。达成该特定事件前,有哪些预期,实际达成的效果是什么样的,中间有怎么的落差,以后处理该类事件时,如何优化方式。

  按照上述思维方式,我们将要写的需求文档当做一个特定的事件,通过剖析该特定事件被触发的前置条件、后置补充内容,来实现对需求文档的分析。

  即为说明要开发的产品是什么。此处的“是什么”区别于产品说明文档,产品说明文档类似于商品说明书,用于告知使用者我的产品该怎么使用。

  而此处的“是什么”是告知该产品的相关人员,该产品有哪些功能,这个功能要怎么呈现,该怎么实现。具体包含以下几个方面:

  该产品是来自哪里的需求,是内部版本迭代优化、Bug修复、新增功能点,还是来自业务部门的需求,或者来自用户的反馈需求。

  必须交代清楚做该产品的项目背景,一方面有利于开发人员更好的了解整体项目,从而更顺利地制定项目计划、项目进度、项目达成;

  另一方面,产品开发完成后存档的文档,有助于后续对该产品的复盘、版本迭代,Bug问题溯源,甚至对出现人员异动时,有助于接盘人员快速了解项目,熟悉产品整体的前因后果。

  在与用户开展调研、访谈等沟通时,充分了解用户的冲突,及急需解决的痛点,有助于产品经理在产品规划阶段,更精准地把握好方向,做出更符合用户诉求的产品。

  同时,在了解冲突的沟通中,除了精准获取到用户的核心诉求,还会得到很多非核心诉求,这些来自于用户潜意识中的需求,为以后产品的发展提供了很好的帮助。

  将这些需求罗列出来,整理到需求池,有助于以后与用户、业务进行再次沟通时作对比,从而去伪存真,对需求池中的需求做好优先级排序,并根据实际业务发展阶段和公司整体要求,划分好产品阶段,对需求池中的需求进行实现,从而促使产品朝向更好的方向发展。

  任何产品的实现,不仅仅要满足用户的需求,更要在解决冲突时达成更多的目的。而这个目的分为物质层面和精神层面两个维度。

  产品的上线,解决了公司业务层面的流程,满足了业务需要,满足了用户的使用,这是产品首要,且是最核心的目的。

  而在满足最核心目的之后,是否有一些延伸的产品需求——减少了操作步骤、优化了交互流程,为实现公司层面的获客、激活、留存、转化、二次推广等各环节起到促进作用。

  产品的上线,解决了用户的困难、疑惑和焦虑,解决了业务部门无法正常使用过程中的烦躁不安,这是产品最核心的目的在用户心里的反馈。

  同时,在解决用户优先级最高的负面情绪的前提下,使得用户对产品的感官,对企业品牌的好感度提升,是产品上线所能达成的最好效果了。

  即该需求文档是给哪些协同人员看的。此处的“协同人员”不仅仅是开发人员,而是产品从交付原型至最终上线,过程中所涉及的所有参与者。

  这些协同人员基于各自岗位和职责,对需求文档的要求也是不一样的,这是所有产品经理在编写需求文档时应尤为注意的点。

  产品经理:大部分公司都会有不止一个产品经理。每个产品经理在负责自己的产品线时,所输出的需求文档对其他产品经理的工作是有必要性的。

  前端开发:以输入静态页面、交互动效为主,包含各类判断逻辑,最终以HTML为输出样式的专业人员。

  测试工程师:检测产品在常规环境、非常规环境,检测所有存在因素及隐患的专业人员,是确保产品上线无Bug的最后一道防线. “阐述”与“满足协同人员”间的关系

  凡事的存在,皆存在因果。满足协同人员,此为因,而为了满足协同人员,输出的需求文档,即为果。因果之间互相作用,促成了产品最终的交付及上线。

  在版本任务的讨论中,在与其他产品经理讲述所规划的功能时, 版本记录、项目背景、项目框架图、流程图,可以快速让其他产品经理了解整体项目,并根据项目背景,给出意见。

  当一个完整项目,每个产品经理负责部分内容的时候,各自负责部分功能的需求文档有助于其他产品经理从文档中发现交叉点中的衔接是否合适,各功能模块的整体融合性。

  再厉害的程序员也不敢保证产品上线后不出现任何问题,当产品上线后出现问题,需求文档有助于产品经理快速找到规划的初衷,根据之前的情境给出精准的解决方案。

  当产品在不同时期,做不同的版本迭代时,之前的需求文档尤为重要,有助于负责该项目的产品经理快速熟悉往期规划的初衷、目的和当前的效果及不足,并在迭代版本中对往期问题进行修复,在新的规划中避免不必要的坑。

  如果出现人员异动(人员项目变更、人员离职等),有助于新接手的产品经理快速熟悉项目,确保项目规划不会因个人经验、个人喜好、习惯等原因,出现太大的偏差。

  设计师是项目实施阶段的第一步。确定版的需求在落地执行时,首先是由设计师开始制作设计图。项目的整体功能有哪些、基于什么背景、未来的规划方向,需要在文档中给出建议和说明,有助于设计师按照产品经理的设想,设计出符合或高于期待的产品设计图。

  基于上述场景和目的,针对设计师角色,产品经理在编写需求文档时,需要告知的信息:因为什么原因,给什么特点的群体,做什么图,当前竞品什么情况、公司什么情况、市场什么情况,想达到什么效果,后期发展方向(业务、功能、设计方向等)。

  后台开发:开发过程中,侧重了解功能、这些功能在后台的数据结构搭建、如何建表、功能逻辑、与前台兼的接口参数传递;

  测试工程师:在产品实现过程中,侧重从产品规划中了解整体功能,从而写测试用例,以及产品上线前根据设计图的样式、文档表述的功能规则,做功能测试。

  基于删除场景,产品经理在编写需求文档时,需要告知开发人员的信息:因为什么原因,针对什么项目,做什么功能,包含哪些页面元素、页面样式、交互逻辑、实现效果。

  尽信书不如无书。各公司的组织架构、部门角色划分、业务开展的推动因素、公司发展所处的阶段均不相同,虽大道同源,但总有差异化表现。

  版本号:便于记录产品不同版本的节点做了什么内容及调整,同时,针对不同的系统,有助于使用统一的版本号做管理。

  上线计划:依据上线计划倒推测试周期、开发周期、设计周期,从而给参与该项目的协同人员约定好时间,便于更好的把控项目进度。

  评审及修改:项目完成后的需求评审建议和结果,针对初稿内容做了哪些修改。此处一定要详细,后续调整内容时,评审建议和修改事项是很重要的可参考的细节点。

  设计规范来源于产品经理对该产品的整体了解:在做完市场分析、行业分析、竞品机构分析、用户调研之后,针对自己要做的产品,产品经理会形成自己的整体构思和产品走向模型。

  信息与意向:传递产品信息,告知设计师关于该产品的设计原因、行业情况、要做的产品对标竞品是哪些,以后对产品的规划是什么、产品经理的意向是什么。

  功能列表为产品经理在经过足够多的调研和分析,从汇总的产品需求池中筛选出的当前应处理需求列表。

  整体流程图:整体流程为将产品各大模块之间的交互流程,一般做正向流程居多,辅助以部分判断流程和异常处理机制

  前端:针对前端部分,页面如何来、页面元素、各功能点的规则、交互、跳转规则、非常规流程的页面元素、交互、跳转规则等等。

  非功能需求为用户常规操作产品时的极端情况,涉及很多内容,以下列举几个比较重要且常规规划中需要考虑的点:

  可靠性:用户操作中出现异常情况,是否可继续操作,遇到异常情况时数据或使用状态是否可被恢复等。

  拓展性:拓展性主要针对公司内部而言,产品完成后,无论是设计师、开发人员,还是测试人员,针对产品所做的工作,是否可以被复用到其他地方。用户在产品中的使用情况是否可被系统获取后用作不同维度的分析等。

  需求文档中,对于功能的表述是尤为重要的,针对各功能点考虑的越详细,越有利于开发人员评估实现难度、评估时间、顺利达到所要的效果。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。


香港118图库彩图| 香港马会开奖结果直播| 现场报码| 香港跑狗图| 最快开码| 新聚宝盆心水论坛| www.399830.com| 报码图片| 开奖直播现场| 87833.com| www.585kj.com| www.89kj.com|