在基金公司工作了一两年，每晚需要直面各种使用者的意见反馈统计数据，根据使用者的意见反馈重要信息，无数次冲洗重要信息、演示使用者操作方式业务流程，直通找出使用者所言的难题，加以预测解决。
而有时，也会接到使用者的意见反馈重要信息实为宣泄型，没一点有利于解决难题的协助。
但……他们绝大多数还是会秉持的准则：
“每一意见反馈另一面都是两个真实世界使用者的感情抒发，以悲悯态度剖析每一难题”有的是就会聊著“那个机能没了，新体验都不太好、负评、……接着就巴拉巴拉的焦虑宣泄。
整个意见反馈重要信息看下来，发掘不到任何管用重要信息，自然就被冲洗掉（是这么干）。
但也会有好的使用者方法论明晰，抒发精确的给指正，他们是很倚重这类使用者的消息，通常都能接到意见反馈重要信息的当日，就预测得到软件系统，接着在前面的某一版中填入复原。
这就是要讲的内容，怎样做使用者意见反馈统计数据发掘，我归纳了两套方向，主要分五个关键步骤：
使用者意见反馈统计数据搜集意见反馈重要信息预测编写需求全面落实商品改良首先明晰两个规矩，使用者意见反馈重要信息基本可以分为以下四种：
不是难题(多名埋怨，在商品服务项目专业领域外)未知难题（常见难题，错误率相对较低，或已经在项目计划中，还未上架）未明难题（新版难题/之前没发现老版难题）明晰那个规矩后，就开始在心中念著 “每一意见反馈另一面都是两个真实使用者的感情抒发，以悲悯态度剖析每一难题”……
第二步：使用者意见反馈统计数据搜集
通常都是Chhatarpur网络平台为主，重要网页内容更有前瞻性，而
第三步：意见反馈重要信息预测
举个例子：
如下图，用Execl表将重要信息分为：
意见反馈难题、意见反馈时间、紧急程度（P3>P2>P1）、难题备注（不是难题、未知难题、未明难题）、优化建议、需求分类、处理状态。
2.1 紧急程度（P3>P2>P1）
他们的业务涉及跨项目，跨地域（境外团队）、跨公司（第三方合作）对接口、统计数据、有时甚至需要监管单位审核，层层风险把控，所以通常定义在这块时候，需要根据公司的业务情况定义。
比如他们定义的P3级别是重要且紧急，迫切需要处理，限定短期限完成，他们这的时间限定有时是两个早上就有软件系统，下午开发人员就能搞定，商品验收；而有时需要3～4天，需要深入了解公司业务后，跟团队去规范那个级别，才能定义，明白每一级别那个另一面的含义。
2.2 统计数据处理：冲洗/标注
刚他们说了使用者意见反馈重要信息大致分为四种；
「不是难题」就是（焦虑宣泄难题），可以备注“不是难题”标签，就无需再处理了，着手的「未知难题」和「未明难题」。
「未知难题」就是常见难题，错误率相对较低，或已经在项目计划中，还未上架，那个处理就是按照原有计划推荐即可。
「未明难题」就进行预测定位合并，进行下一步商品计划。
2.3 优化建议
大绝大多数使用者意见反馈的重要信息中，多为口语话，有时甚至存在地域性抒发方式，比如以下这句话：
客户原话：“股票显示没了都，自选”
翻译专业意思就是：“客户自选股列表，前端没正常显示”这些都需要你转化成专业的抒发，好在处理该难题时候，精确传递重要信息。
比如以下这句话：
客户原话：”想电脑屏幕可以看自己的股票走势，还能需要的时候快速下单交易，但不想影响屏幕上其他操作方式”
势”（如下图）
需要注意点是，每一使用者的抒发和发现难题都是比较随机的，很难发现商品现状全局的难题，
虽然可能代表一类难题，但是难题的影响面和错误率需要他们深入研究
所以才需要他们保持两个态度：“每一意见反馈另一面都是两个真实世界使用者的感情抒发，以悲悯态度剖析每一难题”。
第三步：编写需求
他们从客户意见反馈重要信息，发掘出新的需求，与开发和业务人员进行评审需求。如那个需求决定做，那就进行该机能相关的成员组建、排期、规划等等。编写需求按照以下8条准则格式来写。
需求背景——解决什么难题？ 需要怎么做？达到什么目的？机能描述——列举需要实现的机能点规则定义——规则定义与机能描述机能接口与字段——机能接口与对应字段业务流程图——机能业务流程图原型图——商品原型图与界面方法论说明待确认难题——需要确认的难题参考资料——竞品预测文档与参考文案第四步：全面落实商品改良
最后一道，无非是跟进设计、开发、测试、验收、意见反馈的业务流程。那个业务流程需要在团队有个统一的认知，并是按照那个标准执行。
最后附一张大致业务流程图：
