产品经理学习文章

陪学PEXUE

来自: 陪学PEXUE(加微信;pexuepexue,进群沟通) 2018-04-03 13:16:50

×
加入小组后即可参加投票
  • 陪学PEXUE

    陪学PEXUE (加微信;pexuepexue,进群沟通) 2018-04-03 13:18:58

    标准化产品需求文档逻辑思路


    PRD被公认为产品经理的标准文档,但你写PRD文档时是否做过这些事:

    1. 下载模版,填入内容;
    2. 不了解的章节内容,略过或删掉;
    3. 找己经做好的PRD,做内容替换。

    以前我所在的公司,PRD管理不太好。常常使用上一个迭代,或其它产品团队的PRD模版,做内容替换。
    按理解删减,严重的就只留下产品功能的内容。结果是需求没有可读性,长篇大论,甚至需求遗失,团队沟通成本极高,项目延期严重。

    我们都说产品PRD是没有人看的,但对于大型项目PRD有着重要的地位,如果对PRD理解不够,应付了事,在项目开发过程中会造成极大的损失。

    PRD是什么
    MRD文档表达的是做什么,PRD是MRD的延续,只一个表达主题是:产品怎么做。
    PRD文档是市场想法落地设计方案的文档,是承上启下的重要文档。尤其在开始过程中,是开发人员的重要参与文件。
    因此在产品实现过程中,PRD的重要性不言而喻。对于PRD文档,我们必定明确:

    1.谁看这PRD文档
    PRD的读者包含但不仅限于以下角色:产品总监、研发、UI、测试、相关产品团队(含硬件团队)、运营、客服。
    最常关注的读者是:UI、测试、开发

    2. PRD文档怎么写

    l PRD文档没有模板

    适合的就是最好的,适合自己团队的文档需要产品经理做内容规划。
    现在项目开发,多采取敏捷模式,提倡过程中文档的合适数量。因些,很多公司对PRD形式没有特殊要求。
    这时,产品经理要制作合适团队的PRD文档,大公司的模版不一定适用小公司。

    例如,有的团队研发能力强,配合度高,团队有长期磨合经历。无需过多表达就能理解产品经理的隐性需求,PRD当然可以不写,当然,这是项目规模不太大的情况下,对于大型项目,还是建议产品经理要制作正式的PRD文档。
    同样的,合作度高的团队,他们的PRD文档,也许并不合适其它团队用,解释很久可能还要返工。
    团队合作情况、项目状况。这些都是形成恰当PRD文档的参考因素。

    l 可以参考Volere产品需求模板
    虽然,前面说没有标准的团队PRD文档。但有没有一个规范的PRD模板文件,能够让我们对内容按需调整,形成自己的PRD文件呢?
    这里给大家介绍一个极全面的一个PRD文档模板,Volere需求模板。大家可以利用这个模板,进行调整。我收集了很多模板,就是这个是最全面的了,这里分享给大家。

    整体概览如下,后面对每个章节分解说明:


    基本结构
    先从前说起,一个需求文档,最前面的内容通常是产品相关信息介绍。但很多产品经理只重视“产品功能”描述,对其它信息空着,或随便填充内容,是一种误区。
    文档是沟通用的,我们认为不言而喻的事,别人未必十分清楚。所以对于前面的内容,也应该有必要的关注。

    A. 项目驱动
    这部分内容表达了构建新产品的根本理由。
    它描述了客户面对的业务问题,解释了产品将如何解决该问题,一定程度上可以展示公司和团队形象。

    其中有两部分内容:项目目标和利益相关人
    项目目标:描述我们希望产品做什么,以及它将为工作的整体目标带来什么好处。
    这里的内容不用太长,简短地解释项目目标,通常比长而杂乱的论述更有价值。

    利益相关人:描述了产品干系人,即与产品有利益关联的人。
    这部分的内容可以让产品经理花时间确定与产品利益相关的人,不知道他们的后果可能非常严重。项目开发过程中,上线后,忽略与产品有利益关系的人,产品经理会掉入自挖的坑中。

    B. 项目限制条件
    这部分主要是描述对产品最终设计的可能形成限制的条件。
    它们限制了你能做的事,从而塑造了产品。限制条件像其他类型的需求一样,需要有描述、提出的理由和验收标准。

    例如,这个限制条件:产品的运行环境应在移动设备中

    C. 功能需求

    l 工作的范围
    工作范围描述了产品中包含的业务领域的边界,工作上下文范围图明确了产品要完成的业务边界。

    l 业务用例
    详细确定业务用例( BUC)对的响应过程,当用户发起产品任务时,应执行的详细业务响应流程,这里是发现详细需求提供基础。
    这部分的内容非常的多,也是产品经理主要完成的内容

    l 业务数据模型和数据字典

    例如:
    地区气象产品的类:

    在这个模型中,每个矩形代表业务数据的一个类。该类的属性在数据字典中定义

    l 数据字典
    数据字典确定下面的内容。
    1.数据模型中的类。
    2.这些类的属性。
    3.这些类之问的关联。
    4.所有模型的输入和输出。
    5.输入和输入中的数据元素。

    l 产品的范围
    这部分的内容主要是用例图,它确定了用户与产品之间的边界。

    Ø 产品用例清单
    这部分描述产品中包含的所有用例,并能够确定用例中的输入和输出数据。

    Ø 单个产品用例
    对产品用例清单中的单个产品用例描述细节。包含每个产品用例的场景或模型。
    例如
    Ø 文本场景描述。
    Ø 故事板。
    Ø 低保真原型。
    Ø 高保真原型。
    Ø 正式的用例规格说明书,包括异常和可选场景。
    Ø 序列图、活动图、数据流图或项目团队熟悉的其他类型的模型。

    l 功能需求
    每项需求的详细说明,是最细节的功能内容。
    写这部分内容时,建议大家用表格一块块去,我尝试过很多次。表格式的详细需求,可读性是最强的。

    D. 非功能需求
    这部分包含了与产品质量相关,用户体验的所有需求。对于产品的体验性需求都记录在这部分中。
    这里的内容重点是需求的可验证,也就是产品实现后,能够对这里的功能进行测试。

    E. 项目问题
    这部分主要描述产品的现阶段存在的问题:如:己经被提出但没有答案的问题、产品可以即刻使用的解决方案、产品出现的新问题、产品开始进度总体计划、费用风险和产品培训等问题。
    这部分的内容是动态添加的,因为在产品开发过程中,产品所处的环境是随时在发生着变化的。

你的回应

回应请先 , 或 注册

17083 人聚集在这个小组
↑回顶部