产品需求

一、序言 本文从产品经理的角度出发，对产品经理的安全职责、产品驱动安全的内涵、工作内容、工作方法、所需安全资源、以及产品经理的安全工作量进行了分析。希望所有产品经理在没有心理负担的情况下，有目标、有方法、有资源推进产品安全建设。 二、背景 安全是软件产品天然属性的一部分，“无安全不金融”，对于金融软件产品而言，安全尤为重要，因为客户总是能够从各种安全漏洞联想到他的金融资产安全和个人信息安全。以前偶尔会在一些安全沙龙或峰会听见同行吐槽，“信息安全说起来重要、做起来次要、忙起来不要”。吐槽背后的原因很复杂，其中很重要的一点是跟产品经理安全意识淡薄、不清楚如何推进产品安全建设有关，比如不重视产品安全属性、产品安全需求不明确、产品安全资源不充分、产品安全建设无从下手等。本文主要站在产品经理的角度，从产品经理能力维度出发，探讨产品经理如何推动产品的安全性建设。 众所周知，安全性作为软件产品的天然属性，从产品定义与规划角度来看，产品经理对产品安全负有不可推卸的责任，但产品经理如何履行自己的安全职责，业界还没有给出一个清晰可行的行动方案。 目前，软件产品安全需求通常是基于开发人员和安全人员的职业常识提出相应的解决方案，比如目前业内比较通用的敏感信息五要素分析方法： 这种方法简单易行，但往往不能涵盖所有的敏感信息，比如 用户的多系统用户数据关联ID（超级ID）。 交易过程中的音视频等多媒体数据。

一、序言 本文从产品经理的角度出发，对产品经理的安全职责、产品驱动安全的内涵、工作内容、工作方法、所需安全资源、以及产品经理的安全工作量进行了分析。希望所有产品经理在没有心理负担的情况下，有目标、有方法、有资源推进产品安全建设。 二、背景 安全是软件产品天然属性的一部分，“无安全不金融”，对于金融软件产品而言，安全尤为重要，因为客户总是能够从各种安全漏洞联想到他的金融资产安全和个人信息安全。以前偶尔会在一些安全沙龙或峰会听见同行吐槽，“信息安全说起来重要、做起来次要、忙起来不要”。吐槽背后的原因很复杂，其中很重要的一点是跟产品经理安全意识淡薄、不清楚如何推进产品安全建设有关，比如不重视产品安全属性、产品安全需求不明确、产品安全资源不充分、产品安全建设无从下手等。本文主要站在产品经理的角度，从产品经理能力维度出发，探讨产品经理如何推动产品的安全性建设。 众所周知，安全性作为软件产品的天然属性，从产品定义与规划角度来看，产品经理对产品安全负有不可推卸的责任，但产品经理如何履行自己的安全职责，业界还没有给出一个清晰可行的行动方案。 目前，软件产品安全需求通常是基于开发人员和安全人员的职业常识提出相应的解决方案，比如目前业内比较通用的敏感信息五要素分析方法： 1 2 3 4 5 姓名 身份证号 电话号码 银行卡信息 联系地址 这种方法简单易行，但往往不能涵盖所有的敏感信息，比如

目录 需求分析阶段 需求分析方法 需求管理 需求分析阶段 需求分析贯穿在产品整个生命周期。 1. 产品概念期 这个阶段做需求分析，更强调需求调研，目的是定位目标用户群，做产品定位，市场研究并确认细分产品市场。提炼产品核心功能，解决目标用户群痛点问题。 交付物：BRD商业需求文档 。（或类似的相关的文档，如需求调研报告、市场调研报告等） 2.产品设计开发期 这个阶段的需求分析，目的是要设计一个可落地的解决用户痛点，满足用户需求的产品。设计一个目标用户可用好用的产品。深层次的挖掘和分析用户，描述需求，解决问题。实现用户如何通过一步步的使用产品满足其需求。该阶段 交付物：产品原型+PRD操作文档 。 3.上线后-成长期 上线后的需求分析，目的是验证真实产品满足真实用户需求的结果，收集用户需求，优化产品。 4.成熟运营期 本阶段需求分析，目的在为产品提供更好的运营方案，制定竞争策略。让产品持续更好的更多的为企业创造商业价值。 5.产品衰退期 当产品进入衰退期时，需求分析重在研究市场发展趋势，以帮助决策是调整发展战略。 需求分析方法 需求分析三步走： 明确问题-拆解需求-提供解决方案 1.明确问题 明确问题之前，我们首先要从各方搜集需求，然后经过分析，提出真正的需求。 需求获取渠道 公司内部、在线用户反馈、用户调研、竞品、产品数据分析、头脑分包。 收集到的一手需求还不是真正的需求

无论我们做什么事都讲究方式方法，写 产品需求文档 (以下称 PRD文档 )也是如此，之前我通过四篇文章分享了自己写 PRD文档 的一些方法，而这一篇文章主要是对之前四篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。 产品需求文档(PRD)的写作 四篇章： 1、写前准备(信息结构图) 2、梳理需求(产品结构图和用户流程图) 3、原型设计(手绘原型,灰模原型,交互原型) 4、撰写文档(PRD文档) 5、用例文档(UML用例图、流程图) 1、写前准备(信息结构图)： http://tangjie.me/blog/52.html 在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。 例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。 罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。 2、梳理需求(产品结构图和用户流程图)：

传统的瀑布工作模式使用详细的需求说明书来表达需求，需求人员负责做需求调研，根据调研情况编制详细的需求说明书，进行需求评审，评审之后签字确认交给研发团队设计开发。在这样的环境下，需求文档是信息传递的主体，也是一份契约。 然而详细的需求说明书有以下5大弊端： 单向的信息传递，容易出现理解偏差。 文档很正式，我们会误以为它一定是对的，不去质疑它，让我们停止作出判断。 有了详细的文档，我们不会反复讨论它，相互确认。 书面文档不利于团队共享责任，它扮演了证据的角色。Scrum强调团队共享责任，不论是需求人员、开发人员和还是测试员，大家的共同目标是通过讨论、协作，正确理解需求之后把这些需求变成客户真正需要的功能，而不是单向的任务传递。 编制详细的、表达准确需求文档需要花费大量的时间，如果需求变化频繁，维护成本更高。 敏捷使用产品Backlog来管理需求，产品Backlog是一个需求的清单，按照需求的商业价值排序， 高优先级的需求在Backlog的最上层。产品Backlog是一个渐进明细的清单，它有4个主要特点，称之为DEEP： Detailed 合适的详细程度，高优先级需求更加明细，低优先级的需求粒度更大 Emergent 涌现式的，需求是慢慢涌现出来的，渐进明细的 Estimated 经过估算的 Prioritized/ Ordered 根据商业价值排好顺序的 在产品Backlog中

一：需求要求 由产品经理发起评审会议，评审邮件包含：需求说明书，原型设计，流程设计。 评审过后，修改后的内容（需求说明书，原型设计，流程设计等）由产品经理统一邮件发出。 二、 设计 要求 设计应包含：设计文档（数据库设计，枚举状态流转图，边界图，时序图：时序图应标明事务开始、结束点，包含正反例异常处理方案）。 设计评审前1~2天需要邮件发出设计。评审前2-3天需要和产品经理/负责人确认需求。 评审讲解顺序：需求--- 原型---设计 三：提测要求 1.开发需要不断提高代码质量；修改缺陷，尽可能减少回退情况； 2.若有新的需求改动， 大的需求必须召开设计评审，小的需求必须与相关测试人员详细讲解； 3.提交测试时必须说明：接口的改动影响到哪些功能； 4.开发提交测试前必须做好充分测试（单元测试）； 5. 开发联调测试涉及到第三方的必须联通第三方测试通过，不能只是挡板通过； 6. 开发提交测试时，必须由负责人统一收集相应配置（功能清单，sql，配置文件，数据库配置；然后统一发出给测试。PS：sql应包含可预见的索引； 7.开发提测时，要整理 功能清单所对应的数据库表； 8.开发提测时，前后端分支名称请保持一致； 9.提交的功能不能出现以下问题，出现则打回判为（测试逃逸）： a.功能缺失，与功能清单有出入 b.功能不明确，页面部分开发，文案无 c.主功能冒烟不过，数据库状态、明细不正确 d

1. 什么是 Scrum 　　Scrum 是一种轻量级的框架，适合于小型的、结合紧密的团队开发复杂的产品。 Scrum 是二十世纪后期一些软件工程师协同努力的脑力劳动的成果，现已成为技术领域最具魅力的方法。但 Scrum 并不因此而复杂难用，相反，它不仅适用于技术领域，你还可以轻易将本文中介绍的工具和实践应用于其他领域。 　　一个 Scrum 团队通常由 7 人± 2 人组成，他们在固定的周期用迭代开发的方式一起协同工作。在每个迭代中，他们有充分的时间来评审和反思。“ 检查和调整 ”是 Scrum 的口头禅之一， Scrum 团队还有一个显著的特点就是非常关注 持续改进 ——既包括他们采用的过程，也包括他们的产品。 2. 角色（ Roles ） 　　Scrum 中有三种角色：产品负责人（ Product Owner ）、 Scrum Master 和团队成员。 2.1. 产品负责人（ Product Owner ） 　　从企业的角度看，一个开发团队代表了一笔重大的投资，包括：人员工资、办公室租金、计算机和软件的采购和维护费用等等。 产品负责人的责任在于帮助企业获得最高的投资回报 （ ROI ）。 　　其中一个最大化 ROI 的方法是引导团队做最有价值的工作，同时远离那些低价值的工作。产品负责人控制团队的待办列表中待办事项的优先级顺序。在 Scrum 中

•　　产品说明 　　–　　包含： 　　　　　 　•　产品信息结构 　　　　　　　　–　　信息结构图是只按照产品经理思路中的产品表现来整理产品的一种示意图（后面会举例） 　　　　　　　　　　»　　信息结构能帮助我们整理产品结构， 同时是研发人员建立数据库的参考 　　　 　　　•　　产品结构图 　　　　　　　　–　　产品结构图是按照产品的逻辑与表现方式，结构化的表现产品构造的一种示意图 　　　　　　　　　　»　　通过这个产品结构图，我们大致就能将之前抽象的逻辑形象化的表现出来，也便于文档 　　　　　　　　　　　　阅读理解我们的产品思路 　 　　　　　•　　用户使用流程图 　　　　　　　　–　　用户使用流程图用于表述用户在使用产品过称中的行为走向 　　　　　　　　　　»　　通过用户行为串联信息结构与产品结构，阅读者通过用户使用流程，能更好的理解产品经理设计 　　　　　　　　　　　　的用户行为。 　　　　　　　　 ①产品信息结构图 　　 ②产品结构图 ③产品的用户使用流程图 PS: 一份国外数据分析，样本数据30万份，其中71.3%的人左手持手机左手拇指进行操作，82.6%的人在iPad上右手操作，平放在腿上时用拇指， 　　双手握时用右拇指 　　•　　是不是和我们想象很不一样？ 　　•　　做产品，有时候需要感觉，有时候需要数据 来源： https://www.cnblogs.com

•　　深刻理解三大文档的写作目的与应用场景 •　　理解并掌握PRD文档的用途与作用 •　　理解并掌握PRD文档： 　 　 –　写作思路 　　–　写作方法 　　–　写作格式 ♦　　产品需求文档（Product Requirement Document,　PRD）的英文简称 　 　–　　PRD文档向上是对MRD内容的继承与发展，向下则是要把MRD文档里面的各种理论要求 　　　　技术化，向研发部门与设计部门说明产品的功能和性能要求。 　　–　　PRD文档是产品文档中最底层最细致的文档，所以写作的时候，需要细致耐心。 --------------------------------------------------------------- 再看下这三个文档的区别 •　　BRD-这么做有什么好处，并说明好处在哪里 　 　–　　举例：唐僧出发前，参见唐黄，告诉唐黄西去取经的重要意义与大兴佛法的好处，唐黄答应，并发放免签 　　　　护照，于是唐僧带着任务出发了。 •　　MRD- 通过BRD明确了这个事情值得一做后，描述应该怎么做，并说明这么做的原因 　 　–　　举例：唐僧上路了，但是他需要选择走哪条路线，带几个人，为什么这么走，为什么带这些人，要说清楚 　　 　　 •　　A路线：妖怪多 　　　　•　　B路线：神仙多 　　　　•　　C路线：美女多 　　　　•　　经过分析，唐三藏决定C路线 •　

♦1.0　　产品说明 　　– 1.1　　产品定位 　　 　　•　　产品有越做越复杂的可能，但在一定时间内，定位决定了产品的一切 　　　　•　　产品定位与市场定位是有区别的，但经常容易混淆 　　　　　　 　–　　市场定位：我们对用户或者用户市场的选择，例如：手机发烧友，白领，或者移动通讯设备市场 　　　　　　　–　　产品定位：我们用什么样的产品满足用户或用户市场。例如： 　　　　　　　 　»　　陌陌，一款基于地理位置的移动社交工具 　　　　　　　　»　　抖音，短视频分享平台 　　　　　　　　»　　哔哩哔哩，专注于二次元社区，提供动漫，周边的平台 　　　　 　　　 –　　用户定位的描述： 　　　　　　　 　»　　针对什么目标群体，做什么事情，用最本质的，无修饰的语言表态 　　 –1.2　　产品核心目标（产品本身要达到什么，一个目标） 　　　 　–　　互联网产品的核心目标，往往表现为要解决目标市场（目标用户）一个什么问题 　　　　 　　•　　这个问题分析的越透彻，产品的核心目标也就越准确 　　　　　　•　　确立好核心目标，不会使我们产品推进过程中迷失 　　　　　　•　　例如： 　　　　　　　 　–　　360安全卫士：解决用户使用电脑的安全问题 　　　　　　　　–　　微信：在最早的阶段，微信的核心目标是工具类的，为用户提供流畅的移动应用 　　 　　　　•　　通常来说