PGC(Professional Generate Content)即专业产生内容，具体就是指文字编辑人员撰写的内容。
UGC(User Generate Content)即用户产生的内容，通过筛选，从用户那里得到优质的内容。
OGC(Occupationally-generated Content,职业生产内容)通过具有一定知识和专业背景的行业人士生产内容,并领取相应报酬.
DAU(Daily Active User)日活跃用户数量。
曾经需要写产品相关的文档时总是不知道从哪里下手需要表达出什么，主要还是商业需求文档和市场需求文档，
根据情况，总结一下：
| 文档类型 |
需要做的工作 |
提纲如下 |
要达到的目标 |
| BRD阶段 |
一、 市场分析； 二、 销售策略； 三、 盈利预测； 四、 （注：不出现产品细节） |
一、客户价值； 1、我要服务哪些客户？这些客户是什么样子的？ 二、商业价值； 1、我可以为企业创造什么样的价值？ 三、路线规划； 1、我先满足什么需求？再满足什么需求？为什么？ 四、历史回顾； 1、客户价值和商业价值是否发生了变化？ 五、成本估算； 1、整合各类资源所需要的运营成本、营销成本。 六、评估方法 1、为什么指定这个目标？这个目标是如何显现出来的？ |
向公司申请需要的费用、资源得到各级领导支持；
|
| MRD阶段 |
一、 更细致的市场与竞争对手分析； 二、 通过哪些功能来实现商业目的； 三、 功能/非功能需求分哪几块； 四、 功能的优先级；
——可能产出物有Mind Manager的思维图，Excel的Feature List |
一、产品介绍； 二、用户描述； 1. 用户/市场统计； 2. 用户剖析； 3. 关键用户需求； 4. 替代品和竞争品 三、产品轮廓； 1. 产品前景； 2. 产品定位 四、功能需求； 五、非功能需求； 六、 附件：用户需求调查报告 |
收集、分析、定义主要的用户需求和产品特性 ——不用考虑系统如何满足这些需求以及需求的技术和资源局限 |
| PRD阶段 |
一、 功能使用的具体描述； 二、 Visio版功能点业务流程； 三、 界面的说明； 四、 Demo (注：可是dreamweaver、ps、画图板的简单版，有时也会有UI/UE支持) |
一、项目边界； 二、验收标准； 三、业务流程图； 四、用例说明； 1. 用例总图； 2. 单个用例说明 五、性能需求； 1. 响应时间； 2. 空间使用量等 六、维护性需求； 七、质量需求； 1. 安全性； 2. 可操作性； 3. 可靠性； 4. 兼容性； 5. 移植性 八、接口需求 外部接口需求； 内部接口需求 |
对MRD中的内容进行指标化和技术化；明确产品的功能和性能 |
| FSD阶段（类似概要设计） |
产品UI确定; 业务逻辑的细节确定; 表结构设计 |
|
|
DMP(Data Management Platform)数据管理平台
7.0
Android 7.0Nougat（牛轧糖）：2016年8月22日 [10] [12]
Android Oreo （8.0）：2017 年 8 月 21 日
产品实耗工时统计
以各种原始记录为根据的产品实耗工时统计
以现场测定各为基础的产品实耗工时统计
仓库流程分为入库，生产，出库，入库包括，收货组，复核组，上架组，理货组，订单问题处理组，退货组，还有个高值组和内配组，生产包括，拣货，复核，打包，出库包括分拣和发货。
SKU=Stock Keeping Unit（库存量单位）。即库存进出计量的基本单元，SKU是物理上不可分割的最小存货单元
RDC：分拨中心，用作物流运输节点上，汇集货物，然后按照合理的运力再次分配；
FDC：转运中心，二级仓库类似，用做暂存货物，用以拼整车、正线路发运；只是为了攒货用。
PCB是一块空的板子，在板子的表面什么东西都没有；而PCBA是在空的PCB上加工，安装电阻、电容、芯片等元器件，形成有一定功能的板子，所有电子产品的核心部分都是由PCBA组成的。
物料清单（Bill of Material，BOM）
一般先有BRD，决定是否要开发一个新产品；其次是MRD，决策如何开发这个产品；最后是PRD，决定这个产品开发成什么样子。
CNZZ中文数据分析平台
让产品往正确的方向上持续前行。
软件开发中的完成测试环境所包括的环节包括：UT、IT、ST、UAT
UT = Unit Test 单元测试
IT = System Integration Test 集成测试
ST = System Test 系统测试
UAT = User Acceptance Test 用户接受测试(俗称:验收测试)
1 软件项目测试过程
测试阶段从横向看有以下活动：
测试从需求分析开始介入，测试人员参与需求的分析活动，确定测试的需求。需要了解测试需求及测试进度，即需要验证什么功能需求点，采用什么测试策略，描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、压力测试等）。详细阅读分析需求文档，进行逻辑梳理并勾勒出功能的大概流程图；与产品经理等相关人员探讨表述不清楚的地方，细化业务流程；考虑正常流程中的测试难点；考虑与其他功能的关联；考虑非正常流程；考虑版本数据兼容。
目标：
（1） 理解产品的设计意图和设计思路。
（2） 功能确认，充分理解个功能的细节。
（3） 根据功能的大小、复杂预估测试需要的工具、环境、时间
测试计划在需求分析完成后，程序修改完毕前准备。测试计划要描述测试活动的范围、方法、资源和进度。
目标：
（1） 为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。
（2） 为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。
（3） 开发有效的测试模型，能正确地验证正在开发的软件系统。
（4） 确定测试所需要的时间和资源，以保证其可获得性、有效性。
（5） 确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。
（6） 识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。
输入：
项目计划和测试需求
输出：
《项目测试计划》
《项目测试计划评审会议纪要》
内容：使用各种测试用例设计方法进行用例设计。测试用例的基本要素包括测试用例编号、测试标题、重要基本、测试输入、操作步骤、预期结果等。
测试用例文档是“活的”，测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
目标：
（1） 使测试用例反映不同的场景、条件或经由产品的事件流
（2） 测试用例必须要能完整覆盖测试需求
输入：
测试计划
输出：
《项目测试用例》
《项目测试用例评审会议纪要》
当测试用例编写完成通过评审后，并已提交的可测试的系统， 然后按照测试计划和测试用例搭建测试环境，开始测试执行。对修改的bug进行回归测试。
测试的具体步骤：
（1） 建立测试系统，搭建测试环境
（2） 准备测试材料、测试工具
（3） 执行测试
（4） 验证预期结果，测试不通过，反馈回给编码人员修改。代码修改重新提交后，返回2继续
（5） 记录缺陷
（6） 评估测试需求的覆盖率
（7） 分析缺陷
测试开始标准：
（1） 测试计划评审通过；
（2） 测试用例已编写完成，并已通过评审；
（3） 存在已提交的可测试的系统；
（4） 测试环境已搭建完毕。
测试退出标准：
（1） 测试用例全部通过；
（2） 存在的问题已得到合理的处理。
测试停止标准：
（1） 近半数以上测试用例无法执行；
（2） 测试环境与要求不符；
（3） 开发中需求频繁变动。
目标：
（1） 所有的测试用例都被执行，并每条用例至少被执行一遍。
（2） 存在的问题已得到合理的处理。
输入：
测试用例
测试环境
测试脚本
输出：
《测试执行记录》
《系统bug清单》
测试报告是对测试过程和测试结果进行分析和评估，确认测试计划是否得到完整履行、测试覆盖率是否达到预定要求并最终在报告中给出测试和产品质量的评估结论。
输入：
《测试执行记录》
《系统bug清单》
输出：
《测试报告》
软件部署后，给客户提供产品试用，给客户做相关培训。
输出：
《用户手册》
《客户培训PPT》
软件V模型结构图如：
主要是测试程序代码，为的是确保各单元模块被正常编译。有具体到模块的测试，也有具体到类、函数的测试等。——一般是由开发来完成
单元测试后，将各单元组成完整的体系，测试软件单位之间的接口是否正确，数据能否正常传递。——比如注册和充值这两个功能能否连通
把软件系统搭建起来，按照《软件规格说明书》中的要求对各项功能进行测试，看是否符合需求、在系统运行是否存在漏洞等——根据测试用例，进行完整的系统测试
系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统——用户对软件进行验收
回归测试是指重复以前的全部或部分的相同测试。新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。
| 阶段 |
活动 |
产出物 |
模板 |
| 设计 |
系统设计 |
测试计划 |
|
| 测试计划评审会议纪要 |
无 |
||
| 开发 |
测试用例设计 |
测试用例 |
|
| 测试用例评审记录 |
无 |
||
| 需求跟踪表 |
无 |
||
| 测试 |
测试执行 |
测试用例执行记录 |
无 |
| 测试工作阶段报告 |
无 |
||
| 测试日报 |
|
||
| 缺陷管理 |
缺陷bug清单 |
无 |
|
| 验收 |
系统验收 |
验收测试报告 |
|
| 系统发布 |
用户手册 |
无 |
缺陷状态一般分为：新建、打开、已分配、已修复、关闭、重新打开
中间会有：延期、重复、拒绝等状态
缺陷管理流程：
A类--严重错误，包括以下各种错误：
1、由于程序所引起的死机，非法退出
2、死循环
3、数据库发生死锁
4、因错误操作导致的程序中断
5、功能错误
6、与数据库链接错误
7、数据库通讯错误
B类--较严重错误，包括以下错误：
1、程序错误
2、程序接口错误
3、数据库的表、业务规则、缺省值未加完整性等约束条件
C类--一般性错误，包括以下各种错误：
1、操作界面错误(包括数据窗口内列名定义、含义是否一致)
2、打印内容、格式错误
3、简单的输入显示未放在前台进行控制
4、删除操作未给出提示
5、数据库表中有过多的空字段
D类--较小错误，包括以下各种错误：
1、界面不规范
2、辅助说明描述不清楚
3、输入输出不规范
4、长操作未给用户提示
5、提示窗口文字未采用行业术语
6、可输入区域和只读区域没有明显的区分标志
E类--测试建议
艾瑞APP指数提供海量数据实时查询
阿里指数是定位于”观市场”的数据分析平台,旨在为中小企业用户、业界媒体、市场研究人员,了解市场行情、查看热门行业、分析用户群体、研究产业基地等
腾讯移动分析|免费移动应用APP统计| H5统计|渠道统计|用户画像
Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of
角色
产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。
Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
一张图说起，标注红色的为今日输出部分。
洋葱圈图
就软件产品和项目领域而言（包括互联网，当然还有其他领域），敏捷其实就是一种方法论，无非就是这种方法论较其他而言，相对节奏更灵活，信息更透明，产出更高效，风险整体更小，对各种反应更快，当然对人的要求也更高。
没有对比就没有伤害，关于传统项目全生命周期，言简意赅的说个我曾经作为PM项目经理来跟进的项目交付方法论。背景为财富五百强TOP10的某国企，项目体量千万级别，周期8个月左右。全生命周期流程为：1项目需求挖掘→2项目立项申请→3项目投标竞标→4项目组成立→5项目规划（颗粒度到周）→6项目实施（每周周报+周期成果演示+需求变更+提交变更流程+反复研发+测试+再汇报）→7项目阶段性交付验收→8重复项目实施*N→9项目验收→10项目转运维。
作为传统项目实施方法论来讲，需要PM的前瞻能力值基本跟上帝平级，望眼欲穿到一百天以后是常有的事情，那么问题来了，随着外部环境变化，周边政策变化，以及信息化高度发达的今天，诸如此类的项目真的可以实现信息化先进生产力吗？
答案是需要思考的。但从概率角度来讲，传统方法论较为低了一些。
而敏捷套路用我所理解的一段话概述即为：驱动自组织跨职能的人员团队，用高频率短周期的持续迭代交付方式，快速得到有效用户反馈，并针对过程和结果进行持续优化和改进，由产品负责人掌控整体方向，由敏捷教练SM来引导方法论，实现整个团队的高度信息透明+高效沟通，用渐进明细的方式来交付最终成果。
敏捷价值观▼
（洋葱圈最里层）
个体与互动高于流程和工具
可工作的软件高于详尽的文档
客户协作高于合同谈判
响应变化高于遵循计划
敏捷原则▼
（洋葱圈第二层，自己总结的简洁版）
也是衡量方法论是否为敏捷的标尺
-目标是满足客户
-时刻拥抱变化（后期也一样，技术支持重构）
-持续交付（短周期）
-跨职能相互合作
-充分信任激发个体
-面对面交谈
-可用的软件是首要度量标准
-可持续开发
-不断完善追去卓越
-简洁，够用就好
-自组织团队
-及时复盘
敏捷实践▼
（洋葱圈第三层）
最后基于价值观和原则之上的第三层洋葱圈，就是各实践通过敏捷技术百家争鸣的区域，这里面有各种各样的方法，有适用于大型组织的SAFe，有适用于单团队单迭代，又可以融入组织级方法里的Scrum、XP等，有适用于整合起来按需使用的敏捷方法， 如用户故事、重构、持续集成等等。
说Scrum之前需要说一个承载需求的载体，也是实践其中之一，即用户故事。可以理解为说白话的需求说明书，核心是从用户的角度出发，用一句话在卡片上来描述需求：我作为xx角色通过实现xx功能从而达到xx价值，卡片背面描述该故事具体的测试场景，用这个方式来描述需求对于用户、产品负责人Product Owner（以下简称PO）、敏捷教练Scrum Master（以下简称SM）、研发团队（以下简称开发Team）都比较浅显易懂，从而使信息更透明。而用户故事也是分颗粒度，分别是史诗级故事＞特性故事＞具体故事＞围绕故事拆分出来的任务Task，整体团队是从充分理解用户故事的角度来开展具体任务工作，从下往上，逐层汇集。
进入正题，开聊Scrum▼
下面从最流行的方法论Scrum说起，一句话描述，就是3个角色、3个工件、做5个活动。（还有5个价值观，参考以上就好）
3个角色即PO、SM和开发Team。
3个工具即得产品待办事项清单、迭代待办事项清单、可交付的产品增量。
5个活动即迭代执行、迭代计划会、每日站会、迭代评审会、迭代回顾会。
整体流程如下
（偏实战干货，每条控制在100字左右）
1-团队组建，宣扬方法论
目的：组建好用的团队，灌输结果导向以及敏捷方法。
成事在人。敏捷方法里对于个人和团队的技能要求有三点，一是跨职能，即在懂研发的基础之上，可以跨到测试甚至设计甚至更多；二是主观能动性要高，都是为了解决问题而不是卖骚秀工作量；三是认同结果导向，即我们用此方法，可以更快更高质量的输出可用产品。
（这条是加戏，不在正式的Scrum方法论里面，各类实践都假设团队已成立）
2-创建产品待办事项列表
目的：输出有排序的，有故事点估算的用户故事列表。
此环节里PO进行产品梳理，排序现有用户故事，同时帮开发Team理解需求。开发Team根据理解的用户故事来进行故事点估算，产出可输入至迭代计划里的用户故事。SM来绘制燃尽图，表示产品进度，在每个迭代后进行更新。
备注：用户故事也分颗粒度大小，排序就是优先级越高的故事越具体。
3-通过迭代计划会议产出【迭代周期+事项列表】
目的：通过会议产出本轮迭代的任务。
迭代周期：根据交付要求进行评估后产出产品迭代周期，一般为15天-30天不等。周期太长不灵活。
PO与团队从产品待办事项列表中选取待完成的用户故事。开发Team负责将这些用户故事拆分成任务，给出任务估算，任务一般可在8小时内完成的，可量化。SM绘制针对迭代的可视化图，表示迭代进度，在每个立会进行更新。最后将本轮迭代的任务放置在To do（准备做）一栏。
4-通过每日立会【沟通及领取、交付任务】
目的：保证整体团队每天高频的沟通，了解每个任务的进展及大家进度情况。
整体团队每天花15分钟快速的勾兑昨天做了什么、今天准备做什么，需要什么问题。
每个人主动在To do（准备做）一栏中的选取今日要完成的任务放入Doing一栏并且开工，第二天立会继续按此勾兑，同时将已完成的任务放入Done（完成）一栏
备注：只有PO、SM、开发Team能发言，其他人旁观，有事儿单独聊。
5-通过评审、回顾会议【评审本次迭代的成果和输出改进项】
Scrum方法论里是两个会。
评审会是邀请客户等利益攸关者一起针对本次迭代的成果进行评审（可交付的产品增量）。团队进行演示，PO来讲解整体产品情况。
回顾会是团队内部针对本次迭代内发生的各类做的好的、可以改进的、存在问题的输出改进项， 改进项作为单独的任务为下一轮迭代做输出，也就是持续改进。
6-会后更新产品待办事项列表
整体过程中：
SM需要确保开发Team不受外界干扰，作为敏捷教练更多的是确保会议执行、确保大家理解方法、遵循时间盒规则。
PO把控整体方向及对接外部需求，只有PO可调整产品待办列表优先级，另有权中途取消迭代。
开发Team负责任务的同时还需要遵循敏捷的核心方法，同时按需运用如持续集成、自动化测试、结对编程等组件级方法。
Scrum流程图
（附事项+角色+负责事务）
Scrum思维导图
最后总结一下精华：
前期贴合需求，浅显易懂的说明（用户故事）
价值观一致(褒义方向)
自组织跨职能团队(人&技能)
信息发射源(可视化看板+燃尽图)
高频短时沟通(每日立会)
高频迭代及优化机制(持续改进)
周期性评审及回顾(交付增量＋下一轮改进)
始终认为，敏捷只是达成目标所使用的方法，而Scrum、XP等诸多实践只是提供了一种验证过的可行的参考，而是否适用于本团队，以及团队里每个人具备的技能和方法认知，还需要管理者自行斟酌和思考。
永远不是为了敏捷而敏捷，而是为了更高效的交付更高质量的可用产品。通往罗马之路放眼望去遍布脚下，选择以及实践出最适合自己的为好。
以上为自我学习及结合实践的总结，如有不当之处还请指教，相互进步。最后也印证了一句话，适合自己的才是最胖的。
从管理的角度讲,项目经理是纵向的,而产品经理是横向的
产品需求文档包括：
- 业务背景
- 产品功能概述
- 产品前景分析
- 产品功能整体流程
- 产品逻辑关系
- 面向对象
- 应用对象
- 名词解释
- 参考文档
业务背景描述：
这里，你必须将业务提出方描写出来，并且细致到业务方为什么将这个需求提出来！为什么？一方面，你要告诉研发人员，你为什么设计这个产品或功能，这个需求从来源到设计是有原因的。另一方面，拉上相关业务部门，你至少不是一个人在战斗。
产品功能描述：
对当前功能进行概述，所设计的产品或功能的功能模块，新增、完善、优化那些产品功能；
产品前景描述：
本产品或功能，希望对那些转化率指标或实现那些目的；
产品的整体流程：
Visio、Axure（Axure画的流程图好丑）。
通过而言，简单的需求将主业务流与逻辑关系流表达出来便可以；但涉及复杂的业务，便将产品或功能涉及的主要流程绘制出来；而流程目的，主要是清晰的将前后台的逻辑关系与数据结构表达出来；一方面方便开发理解业务与数据流，另一方面也方便产品人员梳理自身需求的业务逻辑；利于后续与研发进行沟通。
具体的流程数量，根据业务的复杂程度决定，一般只需要将核心的流程绘制出来便可；
前台：主要是交互、数据流程；
后台：主要是业务逻辑判断、数据流；
前后台的流程凑在一起，能清晰的看到前后台的模块之间，是如何进行耦合的，数据储存、提取、处理、分析。
功能框架：
Mindjet Minmanager、Xmind画的框架图好丑。
框架图的意义在于，能让查看或了解业务的人，全方位的了解功能之间的功能点的逻辑关系。同时，一份优秀的框架图，能让PM站在全局的基本面上，对个人所负责的产品进行全局的规划，对前后台的功能进行把握，达到支撑平台业务。
产品架构：
对前后台的各个系统与管理模块的逻辑关系，一般是对业务极其熟悉的业务构架师与资深的产品总监搭建，里面涉及每个接口如何进行对接耦合。
功能架构：
所负责的产品或功能的前后台功能的逻辑关系，简单点的就是一个产品或功能的前后台，大一点就是一个系统涉及的功能点之间的耦合。
功能框架：
功能点所涉及的逻辑关系。
功能结构：
功能点所涉及的逻辑关系。
而“架构、框架、结构”区分在于，所负责的业务究竟有多大。但不论如何，它们的表现的原理是一致的。将分解的功能点，之间是如何联系的功能结构关系清晰、简练的表达即可。
关于架构，包含“功能分解、面向用户”就够用了。若再深入，可将分为：“应用对象、BI分析（BI需求也写上去）、系统集成….”。后续可根据BI数据，对产品进行版本迭代与优化。
面向对象
表达产品或功能主要是为那类用户服务的。将面向用户是谁，拥有哪些权限清晰的表达出来即可，对个人进行功能设计也有很大的帮助。
应用对象
本功能需要在那些应用端或版本进行上线，清晰的描绘出来，方便后续进行业务交接。
名词解释
将本次文档涉及一些奇葩的明词进行解释，这点很重要！有些PM喜欢将一些非常简单的内容包装成非常牛逼，让人看起来很难懂，而事实上也就做哪些一件简单事，但是看的人会很痛苦：看PRD时会想：“这玩意，究竟想表达什么。
参考文档
将所做的本次功能，所参考的那些文档，附属上来；目的的在于，方便后续的业务方、研发方进行查看。
三、功能描述功能描述能否描写清晰，描写清晰，开发找茬都不怕了。如何才能完整的对功能点进行描述呢？围绕三个点“功能是谁？功能来自哪里？功能要到哪里去？
同时，功能需求主要分为核心功能、其它功能。不论是核心功能还是其它功能，都可以由以下元素构成：
功能名称
面向用户
用例图（Axure、mocking（适合移动端进行敏捷性开发）)
前置条件
后置条件
功能简述
详情描述
而具体的功能描述内容，则根据业务（功能点）的复杂程度，进行筛选描写。可以全写，也可以不全写。但务必记住：不论何种方式，目的在于将业务价值完整、清晰、有条理的传递给查看文档的参与角色。
功能名称
（我是谁）
本功能在系统里的命名。
面向用户
本功能的使用对象。（在前台，功能的参与者是少数的；但后台与企业级应用里，功能的参与者是多个的）
用例图
表达功能在表现层的逻辑图；可以是传统意义上的用例图，或者是简化版的原型图、流程图；
前置条件
（我来自哪里）
使用该功能的前提、逻辑关系说明；公司大了后，每个开发都只写个人所负责的业务，所以一定要将每个模块来源都清清楚楚的表达出来，方便开发之间的衔接。
后置条件
（我要到那里去）
使用该功能后，对业务、数据功能，产生的影响与结果；
功能简述
描写本功能需要实现的商业价值或目的；
详情描述
将功能”我怎么来，我怎么去“清清楚楚的表达出来。变成计算机逻辑便是，页面布局、操作逻辑进行详细的说明。常规而言：
前台：
主要是字段、交互逻辑组成；
后台：
主要是判断逻辑、列表表单、查询条件、交互逻辑组成；
四、其它功能其它功能目的在于，功能描述针对于本次产品功能的核心业务，而其它功能针对于触发或需要其它功能变动的业务。功能描述清晰的让开发了解核心，而其它功能便让开发清晰的了解非核心。
而其它功能，主要由以下内容组成
其他接口
对其它系统产生“字段、业务流程”进行说明；本次产品或业务，对前后台那些非主流程模块产生影响；
系统风险评估
当前设计的功能存在哪些缺陷、注意事项与后期的功能拓展如何解决这些问题；
其它需求
对一些非核心的功能点进行详情描述。如：一些需过滤的关键字、新增某个栏目字段。
五、综述通过上述内容，能以通用版的形式，清晰的将所负责产品与功能表达出来，而业务描述、功能描述、其它功能。是产品需求文档重要的组成部份，将产品需求较为全面、有效的描述出来。
同时，能训练PM逻辑思维，提升文字表达能力、业务理解能力，从整体上让PM在需求管理上，明显更加专业，所负责功能的逻辑关系、数据流的来与去都能很好的把控。
六、附语不论是什么格式，倒爷坚持一个观点，适合团队才是好的模板。当前很多的公司在进行MVP迭代的时候会使用Axure 内容描述的形式。虽然，这种形式，是很难将逻辑关系表达清晰，同时会有非常多的思维漏洞。在进行文档归档时，也很难对根据关键字进行检索。但，确实挺适合进行MVP迭代，出现问题修改起来也方便，这种方式比较适合项目流程完善的企业平台使用。
而在敏捷性开发汇总，倒爷习惯流程图 功能框架（功能点） Axure（原型图绘制），从核心的业务流开始，逐渐迭代至功能完善，这个过程也将文档补齐。
但有些公司会在EXCEL里进行需求文档撰写，进行版本管理（这个也不错）。
但，作为新人，需要记住：你能写复杂的东西，简单的东西也能能写；但当然一开始只写简单的东西，那你一辈子只能做简单的东西。
大道至简，简难而繁易；经历过复杂的训练与要求，才能简化再简化。
产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等 PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。
OKR是Objective & Key Results的缩写。中文意思是目标与关键结果。
OKR是在一定周期内为企业和团队设定的战略和目标。在每一个周期结束的时候，OKR能够帮你评估团队目标的执行和完成情况。
高绩效的OKR系统一般有3个共同点：
- 目标和结果可以被量化。
- 个人或者团队的OKR必须在每一天、每一周、每一个月都有露脸的机会。说白了就是持续性，OKR的使用者必须时刻将目标和结果铭记于心，这样才会时刻将自己的行动与之匹配
- 目标要设置的有野心，最好超出能力范围。一个百分百被完成的OKR几乎没有任何推动作用，而一个70%完成度的OKR却近乎完美——它能让你知道你这一阶段你和你的团队的极限在哪里，这样你才有更多的上升空间
—-广告指标—-
不同时期产品的宣传必要要选择合适的投放媒体和渠道，这就需要我们了解基本的广告相关数据指标。
CPM
cost per impression，按千次展示付费，指通过某一媒体投放广告，听到或看到此广告的人达到一千人平均所要花费的广告费用。
CPM=（广告费用/到达人数）×1000，比如投入广告费用200元，有10000人浏览过此广告，则CPM=（200/10000）×1000=20元
CPM取决于产品的印象，不是评价广告效果的单一指标，是对不同媒体进行衡量而制定的一个相对指标，通过比较不同渠道的广告收入找出效果最好的渠道。
CPA
cost per action，按行为付费，通过广告使用户产生一定行为而计费，不限广告投放量。对于用户行为的定义依产品而定，包括形成一次交易、获得一个注册用户、下载一次软件，或是填写一次有效问卷等，这些统称为用户行为转化。
CPA=广告费用/有效转化次数
转化次数的统计较为困难，另外由于广告被点击后会触发用户的后续行为（如注册或消费行为），在网站中不大受欢迎。
CPC
cost per click，按点击量付费，对某一广告点击所产生的广告费用，统计点击量可以设定一定标准，比如对于同一个IP，在一个时间段内重复点击，统计为一次，也可忽略IP的限制，直接统计总点击量。
CPC=广告费用/点击量
CPC为网络广告投放效果的重要参考数据，但也有其缺陷，比如虽然用户没有点击广告，但他已经看到了广告。
CPS
cost per sales，按销售付费，按照广告点击之后产生的实际销售笔数来计算广告费用，
CPS=广告费用/有效销售量
适合购物类、导购类、网址导航类网站，需要精准的流量才能带来转化。
CPT
cost per try，按试用次数付费，主要是移动应用渠道营销平台以试玩或试用为付费标准。
CPT=广告费用/有效试用次数
这种方式的特点是按用户使用时长或使用周期计费，可以从根本上杜绝刷流量，是最真实有效快捷的营销方式之一。
—-网页指标—-
PV
page view，即页面浏览量，用户每1次对网站中的每个网页访问均被记录1次。用户对同一页面的多次访问，访问量累计。在一定统计周期内用户每次刷新网页一次也被计算一次。
可通过后台运营获得数据；也可通过相关统计工具获得，如Alexa、百度统计、Google Analysis等。日均 IP/PV 访问量约为 600/2400的意思是今天访问首页次数为2400次，访问IP为600个，也就是说这600个IP一共访问网站2400次。
一般来说PV与来访者数量成正比，但是PV并不直接决定页面的真实来访者数量，例如，同一个来访者通过不断的刷新页面，也可以制造出非常高的PV。
UV
unique visitor，即独立访客，访问网站的一台电脑客户端为一个访客。
00:00-24:00内相同的客户端只被计算一次。
使用独立用户作为统计量，可以更加准确的了解单位时间内实际上有多少个访问者来到了相应的页面。
PR
pagerank，即网页的级别
安装Google Analytics等统计工具
一个PR值为1的网站表明这个网站不太具有流行度，而PR值为7到10则表明这个网站非常受欢迎(或者说极其重要)。
跳出率
指用户到达你的网站上并在你的网站上仅浏览了一个页面就离开的访问次数与所有访问次数的百分比。这里的访问次数其实就是指PV。
浏览单页即退出的次数/访问次数。比如，在一个统计时间内，一个网站有1000个不同访客从某一链接进入，并且其中有50个人没有二次浏览行为，是直接退出网站的，则针对这个链接的网站跳出率为50/1000=5%。然而有些退出的行为不能作为退出考虑，比如页面上刻意添加的导出链接，如合作伙伴的网站等，还有联系我们，付款页面等，都不算是负面的跳出，所以要根据不同情况统计有效的数据才能得出可靠的跳出率。
是评价一个网站性能的重要指标，跳出率高，说明网站用户体验做得不好，用户进去就跳出去了，网站没有满足用户的期望与需求或是人群定位不精准，反之如果跳出率较低，说明网站用户体验做得不错，用户能够找到自己需要的内容。而且以后他可能还会再来光顾你的网站，提高了用户粘性。慢慢的可以积累大量的网站用户。
退出率
对某一个特定的页面而言，从这个页面离开网站的访问数占所有浏览到这个页面的访问数的百分比。
从该页退出的的页面访问数/进入该页的页面访问数，可采用访问统计工具如Google Analytics进行统计
从某方面反映了网站对于访客的吸引力，如果退出百分比很高，说明访客仅浏览少量的页面便离开了，因此当你的网站退出百分比很高的时候就要想办法改善你网站的内容来吸引访客了。
跳出率与退出率
跳出率适用于访问的着陆页 （即用户访问的第一个页面），而退出率则适用于任何访问退出的页面（用户访问过程中在你的网站上访问的最后一个页面 ）。退出率是对于特定的页面来说的，对于网站整体来说并无意义，因为来到网站的访问必然最终都会离开网站，对于网站整体来说其退出率必然是100%。而跳出率则可以适用于着陆页面，也可适用于网站整体。
跳出率只能衡量该页做为着陆页面的访问， 跳出率分母等于Landing Page的visits ，分子也是指跳出的visits。
退出率则是针对全部的访问页面不限于着陆页面（Landing Page），任何页面都有退出率。
退出率的分子=退出的次数（包括一次访问过程中用户浏览单页即跳出的次数，也包括浏览多页后从该页面退出的次数。）
平均访问时长
指在一定统计时间内，浏览网站的一个页面或整个网站时用户所逗留的总时间与该页面或整个网站的访问次数的比。
访问总时长/访问次数，如一个网站在一定时间内总的逗留时间为1000秒，在这段时间内，总的访问次数是100次，那么这个页面或网站的平均访问时长就是1000秒/100 = 10秒。
是体现被统计对象的用户黏性的重要指标之一，进而可以评估网站的用户体验，指导改善页面。平均访问时长越短，说明网站对用户的吸引力越差，可用的有用信息越少，也说明网站需要优化或都添加有用信息了。
转化率
指在一个统计周期内，完成转化行为的次数占推广信息总点击次数的比率。
转化率=（转化次数/点击量）×100%。
以用户登录为例，如果每100次访问中，就有10个登录网站，那么此网站的登录转化率就为10%，而最后有2个用户订阅，则订阅转化率为2%，有一个用户下订单购买，则购买转化率为1%。
转化率反映了网站的盈利能力，重视和研究网站转化率，可以针对性的分析网站在哪些方面做的不足，哪些广告投放效果比较好，可以迅速的提升用户体验、节约广告成本，提升网络转化过程。
重复购买率
指消费者对该品牌产品或者服务的重复购买次数。
重复购买率有两种计算方法：一种是所有购买过产品的顾客，以每个人人为独立单位重复购买产品的次数，比如有10个客户购买了产品，5个产生了重复购买，则重复购买率为50%；第二种算法是，单位时间内，重复购买的总次数占比，比如10个客户购买了产品，中间有3个人有了二次购买，这3人中的1个人又有了三次购买，则重复购买次数为4次，重复购买率为40%。直与复推荐企业采取第一种算法。
重复购买率越多，则反应出消费者对品牌的忠诚度就越高，反之则越低。
—-用户指标—-
ARPU
Average Revenue Per User，即每用户平均收入
在一定时间内，ARPU=总收入/用户数，一般是计算长期的ARPU比较有意义，如平均每月每用户收入。
而用户数可以是总平均在线用户数、付费用户数或是活跃用户数，不同产品标准可能存在差别。
ARPU注重的是一个时间段内从每个用户所得到的收入，衡量互联网公司业务收入的指标。ARPU值高说明平均每个用户贡献的收入高，但高未必说明利润高，因为利润还需要考虑成本。ARPU的高低没有绝对的好坏之分，分析的时候需要有一定的标准。
用户流失率
是指那些曾经使用过产品或服务，由于对产品失去兴趣等种种原因，不再使用产品或服务的用户。
用户流失率=总流失用户数/总用户数，流失用户数依产品而定，并且有各自的不同标准。
分析用户的流失情况可以找到流失的原因，针对产品所处的时期再找到解决办法。一般流失用户都是对于那些需要注册、提供应用服务的网站而言的，比如微博、邮箱、电子商务类网站等。对于流失用户的界定依照产品服务的不同而标准不同，对于微博和邮箱这类用户几乎每天登录查看的网站而言，可能用户未登录超过1个月，我们就可以认为用户可能已经流失了；而对于电子商务而言，可能3个月未登录或者半年内没有任何购买行为的用户可以被认定是流失用户。因此这里有个流失期限。
活跃用户
是相对于“流失用户”的一个概念，是指那些会时不时地光顾网站，并为网站带来一些价值的用户。
活跃用户用于衡量网站的运营现状，而流失用户则用于分析网站是否存在被淘汰的风险，以及网站是否有能力留住新用户。
每个产品活跃的定义千差万别，如果是有帐号的客户端产品，例如IM、端游等，通常以帐号登录作为活跃标识。如果是某些工具软件，有的以启动作为活跃，例如看天气的。有些需要进行一些核心操作，例如拍照软件，至少是完成一张照片拍摄，才能算活跃吧。
日活跃用户
DAU，Daily Active User，指某个自然日内启动过应用的用户，该日内的多次启动只记一个活跃用户。
月活跃用户
MAU，Monthly Active User，指某个自然月内启动过应用的用户，该月内的多次启动只记一个活跃用户。
这两个指标一般出现在在线服务的分析统计指标中，比如在线文档，或者是网页邮箱服务，网络游戏，SNS游戏等等。一般用来衡量服务的用户粘性以及服务的衰退周期。
DAU/MAU比例是SNS游戏的重要参数，一般最低极限是0.2，这保证游戏能够达到临界规模的病毒式传播和用户粘性。
周活跃用户
WAU，Weekly Active User，指某个自然周内启动过应用的用户，该周内的多次启动只记一个活跃用户。这个指标是为了查看用户的类型结构，如轻度用户、中度用户、重度用户等。
用户保有率
用户保有率指在单位时间内符合有效用户条件的用户数在实际产生用户量的比率，也叫用户留存。
保有率=保有量/实际量
次日留存率：（当天新增的用户中，在第2天还登录的用户数）/第一天新增总用户数。因为都是新用户，所以结合产品的新手引导设计和新用户转化路径来分析用户的流失原因，通过不断的修改和调整来降低用户流失，提升次日留存率，通常这个数字如果达到了40%就表示产品非常优秀了。
第3日留存率：（第一天新增用户中，在往后的第3天还有登录的用户数）/第一天新增总用户数。
周留存率：（第一天新增的用户中，在往后的第7天还有登录的用户数）/第一天新增总用户数。在这个时间段里，用户通常会经历一个完整的使用和体验周期，如果在这个阶段用户能够留下来，就有可能成为忠诚度较高的用户。
月留存率：（第一天新增的用户中，在往后的第30天还有登录的用户数）/第一天新增总用户数。通常移动APP的迭代周期为2-4周一个版本，所以月留存是能够反映出一个版本的用户留存情况，一个版本的更新，总是会或多或少的影响用户的体验，所以通过比较月留存率能够判断出每个版本更新是否对用户有影响。
渠道留存：因为渠道来源不一，用户质量也会有差别，所以有必要针对渠道用户进行留存率分析。而且排除用户差别的因素以后，再去比较次日，周留存，可以更准确的判断产品上的问题。
留存用户和留存率通常反映了不同时期获得的用户流失的情况，表现不同时期用户对产品的适应性和黏性，分析这个结果往往是为了找到用户流失的具体原因。
如果老板问你「我们应该提升销量还是提高利润？」一定要记得，无论你怎么回答，都是错的。
因为，企业利润最大化并不在于「卖的贵」或者「卖的多」，而是尽量“榨干”消费者剩余（消费者剩余=消费者愿意支付的最高价格-实际成交价）。要怎么“榨干”呢？这就需要引入经济学概念：价格歧视。
价格歧视：同样的产品，针对不同的消费者收取不同的价钱。
案例：有三位想吃冰淇淋的顾客。土豪出价10元；白领出价8元；而小学生零花钱只剩6元。如果你是老板，冰激凌成本5元，怎么定价合适呢？
如果追求利润卖10元，只有土豪买得起（损失客户：白领、小学生），你能赚5元。
如果追求销量卖6元，三人都会买，但利润太低只赚3元。
如果定中间价8元，能赚6元（损失客户：小学生）。
难道最多只能赚6元吗?
当然不是，其实可以赚最高利润9元。具体做法是：分别卖土豪10元，卖白领8元，卖学生6元，
可是问题来了，不会有人主动把他愿意支付的最高价告诉你。那怎么办呢？
答案就是：给优惠设置重重障碍。企业通过区分消费者是否愿意付出时间成本或被限制选择权，窥视其支付意愿。
1.优惠活动：用时间成本区分消费者
电商网站上充斥着各种优惠信息：积分返现、买2免1、满199减20、满399减50、优惠券、定金立减……
消费者想要获得最低价，不仅要通晓所有优惠规则，还要知道“满减和积分能不能同时使用？”、“特价商品是否参加买2送1”等复杂信息。甚至网上还会流传每年双11的优惠攻略。
既然降价可以提升销量，为什么企业不简化流程直接打折呢？
这是因为，企业需要通过规则复杂的活动来区分愿意付出时间研究优惠信息的「穷人」和不在乎优惠信息直接下单的「富人」，让他们都支付了他们愿意支付的最高价格。
例如，大晚上不睡觉抱着手机抢秒杀，就为了便宜20块的「穷人」和宁愿多花钱也懒得搜集优惠券的「富人」相比，前者就能以更低的价格买到同样的商品。（PS：本文的「穷人」与「富人」是指消费者对待某件商品的支付意愿，并非单指经济状况。虽然经济状况会影响支付意愿，但并非唯一因素。）
除了占用消费者的时间，还有其他方法吗？
2.限制购买：通过限制主动权区分消费者
买打折的衣服可能要等到换季，为什么不能想要的时候立刻拥有？为什么iphone一样的配置，土豪金要贵一些？为什么买一送一往往都是赠送指定商品？
这可能也是一种商家区分「富人」和「穷人」的手段。通过限制消费者主动权（限制下单时间、限制购买品类），从而达到区分消费者支付意愿的目的。想要低价，「穷人」只能在双十一下单；想要低价，「穷人」只能在参加活动的几款商品中选择。而「富人」更有可能情愿不参加活动，随心在任何时候买自己想要的任何商品。
小结
需要说明的是，我们不应该把价格歧视看做是不良商家“欺骗”消费者的恶劣手段。从某种意义上说，正是因为价格歧视，才让一些收入偏低的人群也能享受到更高品质的商品。例如文章开头的小学生，虽然只有6元，却能和土豪一样尝到美味的冰激凌。
企业降价促销的原因有很多，价格歧视只是其中一种。但无论基于何种原因的的促销活动，客观上都可会引发价格歧视现象。
一、什么是产品定位
官方说法：产品定位就是对产品目标、范围、特征等内容的约束条件。
我的理解：就是让你的产品“从宇宙具体到地球”、“从食物具体到米饭”、“从单位具体到厘米”，简单来说就是让产品从“大”到“小”的一个过程。
举个例子：假如你在做一个关于电子邮件的产品，如果你只用电子邮件来描述你的产品，那是没有任何价值的，因为你说的太泛了，这时候产品定位就能够告诉你，你是在做一个什么样子的电子邮件，比如说“给白领移动办公的高效快捷的电子邮件”。
但其实产品定位还远远不止这些内容，那它到底由哪些内容组成呢？
二、产品定位的组成内容
我们先看一遍产品定位的组成结构，内容如下图：
产品定义
产品定义是我们工作中经常会提到的内容，也就是一句话描述你的产品，它包括三个内容，使用人群、主要功能、产品特色。
举个例子：一款为单身男女更容易成功约会的即时通讯工具。这其中
使用人群：单身男女
主要功能：即时通讯
产品特色：更容易约会成功
用户需求
用户需求一般都是基于产品定义的基础上提炼出来的。包括目标用户、使用场景与用户目标。
目标用户：在“使用人群”的基础上进行细分。比如还是上面那个例子，使用人群是单身男女，我们将使用人群细分为：18-25岁、25-35岁、35-45岁和45岁以上的单身男女。最后将目标用户定为25-35岁的单身男女，当然为什么选取这部分人群需要一些理由，比如这部分群体的经济比较独立，年龄更适合步入婚姻的殿堂等等。
使用场景：在“主要功能”的基础上进行延展。比如我们的主要功能是即时通讯，那即时通讯会分为很多使用场景，比如上下班的路上、睡觉前，起床后等等。
用户目标：在“产品特色”的基础上展开分析。比如产品的特色是“更容易约会成功”，那为了达成这个大的产品目标，我们需要细化，将其分解成多个小的用户目标，如快速看到周围单身异性的信息状态、快速了解周围哪些异性对自己有兴趣等等。
综合上面三点，我们可以清晰得得出多个用户需求，例如：让25-35岁的单身男女在睡觉前快速了解周围哪些异性对自己有兴趣等等。
总结
以上就是产品定位的组成内容，在这里需要强调以下两点：
1.目标用户、产品特色、主要功能是产品定位中最核心的内容。
2.不同的产品进行内容细分时的维度会有所不同，例如，在对使用人群进行细分时，可以利用年龄进行细分，也可以利用职位、性格等等。千万不要被案例和规则限制死。
三、产品定位对交互、视觉设计师的作用
说了这么多，那到底产品定位对我们交互和视觉有什么用处呢？
首先可以帮助我们对整个产品有个大局观，至少清楚我们到底在做什么。但这一点可能听着有点虚，那我们来举几个简单的例子。
1.使用人群对我们有什么作用？
如果我们的产品使用人群是50岁以上的老人，而你设计的界面字体大小是下面这样的那或许你还应该给用户再配一个下面这样的东西：
再比如一个产品的使用人群是高端商务人士，而你却采用五彩缤纷的颜色，是不是有些不搭调呢
当然上面这些例子可能有些夸张，目的是为了让大家有一个更好的记忆点，希望大家在做交互、视觉的时候可以在产品定位的基础上去进行创意延展，而不是天马行空的乱作一通，不然及时你做的再好，都没不会产生太大的商业价值。
2.使用场景对我们有什么作用？
如果产品的主要使用场景是在晚上，那我们是不是可以提供一个夜间模式并将其设置为默认模式呢？
当然以上只是简单的举几个例子，其实产品定位对于我们的帮助还远不止这些，比如还有思维上的帮助等等，大家平时可以多多思考，希望这些例子可以对你有一些启发。
对于交互、视觉设计师来说，短期内了解基础的知识点就够了，研究的太深反倒会本末倒置，我个人觉得以上这些知识点只要你能够理解透彻，在实际工作中完全够用了，后面如果你真的觉得这些都是小儿科，再继续深造也完全ok。
