出现的问题
在前几年运营产品与设计产品的时候，发现了一个很头疼的问题，就是需求方面的问题。相信也是大家都面临的一个问题
场景1
我作为实施人员的时候，与客户直接进行沟通交流。交流后会记录交流的内容，回公司后发送给研发负责人与领导。
场景2
其他部门在使用本产品的时候，想到几个建议，可能就直接发个消息给具体的某个人，那这个人是谁？不是很清楚。
场景3
用户在使用产品的时候，突然想到好的想法或者需要完善的，是直接和实施人员进行沟通，这就是第一种场景，那么这里说的就是没有反馈给实施人员，有时候可能忘记和实施人员说了。
场景4
领导层面，领导喜欢奇思妙想，在会上由会议人员进行记录，然后发送给各自的邮件
场景5
产品执行层，包括研发人员、产品设计人员，也包括我自己。由于因为时间管理，有一个好的想法，但是在当前时间计划上可能不满足去实现这个功能。如果没有记下来，后面就可能忘记，或者记下来了后不知道记录在什么地方。
场景6
销售层面，销售人员是直接和客户沟通的第一个人。需求反馈也是最直接的，最能知道客户需要解决什么问题，需求是什么。口述可能会直接转给研发或者其中某一个领导。那么这个需求最后会去向何方，也是不觉明厉。
以上的场景针对需求都是亲身经历，最后的需求都干嘛去了？
怎么解决？
需要一个统一的入口。需求管理系统。
目前的解决方案由两种
第一、直接指定一名人员作为记录
第二、通过需求管理系统进行管理记录
第三、使用第三方需求管理工具
这两种我都在实行
下面构建需求管理系统的思路以及意义，还有需求调研。
需求的分类：
- 项目需求：
主要是针对时间进度、成本、资源、人员、硬件等等的需求
- 过程需求：
对象是开发过程中开发人员、工具方法，主要包括需求规格说明文档、原型图等
- 系统级需求：
主要包含软件需求、硬件需求、其它需求
软件需求分类包括：
- 功能需求
体现在系统与用户之间的交互，帮助用户解决什么问题，并完成任务
- 非功能需求
a. 性能需求
速度：系统完成任务的时间
容量：系统能存储多少数据量
并发性：系统可以承载多少的并发量
实时性：系统实时要求反应需要在秒级反应
b. 质量属性
可靠性：在一定的时间或者条件下，系统执行所要功能的无故障执行能力
可用性：系统使用中可操作或访问程度
可维护性：为改进系统或修复Bug而修改系统或某功能模块的难易程度
安全性：阻止对其程序和数据进行为授权访问的功能
可移植性：将系统从一个硬件或者软件的运行环境换置到另一个环境
易用性：系统使用的难易程度
c. 对外接口
系统开发以及运行的环境：计算机、操作系统、编程语言、数据库管理
问题的相关标准：包括法律法规、合作协议等等
社会性因素：文化、信仰等社会性因素。
产品经理四大文档：
BC：商业方案
BRD：商业需求文档
战略级需求，说明产品战略和企业战略是如何结合的
一句话来清楚的定义你的产品
一句话说明你的产品有什么创新、解决了什么、满足了市场什么空白
一句话说明相比其他产品你的有什么优势
一句话说明我们团队适合做这个产品，时间周期
一句话简要说明你所需要的资源
一句话说明投入和利润
一句话说明产品的赢利点（短期、中期、长期）
- MRD：市场需求文档
市场级需求，说明市场的问题、机会、风险都是什么，以及需要提供什么解决方案
主要包含特色、优势、用户群体
- PRD：产品需求文档
产品级需求，说明基于解决方案，产品应该解决哪些现实问题
流程首尾逻辑
数据的闭环
多种场景考虑因素
- FRD：规格详细说明书
功能级需求，明确详尽的功能规格是什么
需求优先级排序，顺序不重要，关键在于依据是什么
优先级排序不能只是一个结果，而需要整理出对应的排序依据
需求管理过程不规范
MMF（minimum Marketable Features）最小可市场化特征：主要包括竞争差异化、增加收入、降低成本、品牌强化、增强消费者忠诚度。
简单来说通过一种或者多种方式为产品和企业创造市场价值
举个例子：
想打他吗？我也想。这个需求太无聊了，首先技术上是不是能够实现，实现难度如何。先考虑的一个问题是这个需求对产品的意义是什么，对产品战略目标和企业战略目标的实现能有多大价值。
从 MMF 的角度来看，这个需求是否可靠、真实的需求。
所以比较容易出现的一种问题就是需求不能有效的指导产品发展
如何构建需求管理体系系统
主要目标
为产品的发展创建可行、可信的市场需求，并进行有效的管理
两个关键词：一、可行、可信；二、市场需求
目前我们需求管理的现状
需求获取艰难：获取渠道不统一，经常出现需求反馈的延误
需求工具的杂乱：没有统一的需求反馈、分析和管理工具，无法形成规范接口
需求分析的随意：缺乏标准的需求分析标准，通常是主观或者经验，造成需求不够客观
需求存储的缺失：没有一个长期存放需求的平台，无法形成持续的产品关注流程
需求交流的混乱：没有规范和统一的需求交流平台，效率低下，效果不好
在需求管理的过程中，从输入端、处理段、输出端、存储端，都可能存在一定的问题，如果有一端存在问题，那么就会影响整个系统的运转。
那么构建需求管理系统的要求是什么
目的：统一、规范、标准、高效
建立统一、规范的需求反馈、分析、存储、交流平台
需求管理系统有关的角色分类四类
产品利益相关者：这个利益相关者就是包括市场中消费者和企业，但是从广义的角度说，这个利益相关者就很多了，还包括上下游供应商、投资人、竞争者等等
他们不一定是提出者，但是很有可能是需求失陷后的受益者或者观察者。
产品执行层&产品经理：整个产品的管理组织，类似项目管理中的 PMO；
定义三种：一是 PT（产品团队），二是 PMG（产品管理小组），三是 PTAG（产品趋势分析小组）
研发管理体系：这个体系一般是作为需求的实现端（这里不是处理端，处理端在于产品管理系统中完成的）存在于需求管理系统中
营销管理体系：这里主要作为需求的输入端和最终产品的输出端存在需求管理系统中
下面是角色分类的结构图
需求管理的处理过程
需求管理系统最终的价值是什么
主要在于企业的商业和业务层面的价值。
怎么评判目标是否达到
有助于延伸到后续产品以及持续ROI，可持续的产品计划流程
产品价值链贯穿产品经理和其他相关人员，完成和传递给必要的人员，对市场需求进行共享
能够使市场信息的收集流水线化以及提高可重复利用率
能够简化市场需求的整个管理过程
基于市场导向的需求的数据交换更加容易
周末花了一天时间简单开发了一下：
选择产品或者项目
门户前端页面
进行反馈到不同产品或者项目上面
门户前端提交需求页面
在后端项目管理系统上面将会进行统计这些需求。后面还缺分析功能
需求统一反馈与存储已经完成
后面需要完成的事情
需求的分析与交流平台功能
