从To C 转到了To B、从用户体验到数据产品、从移动端到pc端、从用户产品转到了数据产品、从通信行业转到了更偏底层技术的流媒体行业；工作内容从每天看用户反馈意见、看运营数据去挖掘用户需求，到现在每天看数据库、看代码去梳理业务流程、找业务人员了解需求、接触数据分析建模、数据分析效果验证、产出数据后台原型等，三个月的时间，从0 到1搭建了卡顿数据监控平台、也从0.5到1重构了线路调度平台。
从偏执行做需求到自己规划和试错，有过成夜的思考方案，有过焦虑、迷茫和变着花样的挫败感和成就感。但坚信办法总比问题多。既然不天赋异禀，甚至算不上聪明，那么就不要停下来休息。
写这篇文章的目的，其一是自我总结和复盘，其二希望能分享从To C转To B、从纯用户体验产品转数据产品、从偏执行到自己主导设计产品过程中的思考逻辑和内容的转变，因此会剔除项目细节，不会包含公司敏感内容，只讲思考方法。
为了方便大家理解文章内容，简单介绍下所做的卡顿监控后台的项目背景和业务逻辑。
一、项目背景
目前正在做的项目是流媒体行业中在线直播课程相关业务，通俗来说即做直播课程中“卡顿”这个影响用户使用体验问题的底层技术支持。为降低卡顿情况的发生且能够在发生卡顿时及时进行处理，因此需要做卡顿情况实时监控、且能智能定位卡顿发生原因、并基于一定报警规则通过消息触达策略及时同步给技术支持人员进行处理解决，从而保证直播课程质量。
二、业务逻辑
1、一堂直播课程内容数据传输全链路流程大概可以描述为：老师端进行推流——数据推送至源站——经过CDN厂商进行内容分发——学生端进行拉流；
2、数据监控的原理可以概括为：基于客户端上报日志埋点（是否发生了卡顿、卡顿持续时长等）数据——通过数据库实时计算处理——得出卡顿数据——按照预设条件区分卡顿报警数据和普通卡顿数据——前端展示；
3、智能定位卡顿原因原理可以概括为如下图：
三、执行流程
1、确定项目背景
（1）从产品特性出发：直播课程相比于娱乐直播，为工具型产品，包含密集知识点，对卡顿情况的容忍度低，一旦发生卡顿学生将有可能因错过重要知识点而影响学习质量，因此需要实时监控卡顿、及时定位原因并迅速处理；
（2）从处理效率/成本角度出发：现有流程中，当卡顿报警或学生反馈卡顿后，需人工定位卡顿原因，存在耗费人力且耗时较长的问题，无法快速定位问题并解决问题；
基于以上背景，需做可视化后台，提供卡顿全链路数据监控、智能定位原因功能，从而实现提升处理实效、释放人力成本的目标。
2、明确产品定位，界定产品边界
针对普通用户（运营同学）和专家用户（技术同学）需求是有差异的，比如前者看到卡顿情况及卡顿原因即可，而专家用户希望能够查询到用户行为日志。在需求调研过程中，有专家用户提出新的监控后台要完全取代已有的日志查询后台，即包含全量的老师及学生行为数据，这样不仅可以在新平台中定位卡顿原因，黑屏、闪退的原因也一并能定位到了。
如果真的这样做的话，对产品设计的痛苦点在于：其一全量数据过于庞大，会导致查询效率极低；第二开发工作量和开发工期都会受到影响，项目会整体延后；其三如果做全量日志查询功能，如何界定新平台和已有平台的差异？
因此，需要给新平台的定位设定边界，要保证解决80%问题的功能可以按时上线。最后明确新平台只展示与卡顿原因相关的上报的用户行为数据，且将卡顿时间过短的不影响用户体验的数据过滤掉。
3、提出数据假设
做数据产品最重要的就是日志数据埋点了，数据监控、卡顿原因定位等均基于数据埋点进行。
在做产品方案之前，先找技术还原当前卡顿发生后的处理流程，明确影响卡顿的关键因素有哪些，即明确哪些埋点数据可用于原因定位，比如可以通过数据传输中丢包率、输入及输出帧率等数据监控卡顿原因，接下来从这几个相关数据入手确定参数阈值，即确定某个参数当上报数据达到某个值时，发生卡顿的可能性最高。
完成这一步即确定了卡顿可定位原因及上报数据达到什么值时归为何种原因。
4、需求分析及功能设计
（1）从需求方出发明确需求
基于以上需求分析，确定产品功能包括卡顿监控、原因定位及针对专业用户提供上报日志查询功能。
（2）从功能设计角度如何满足用户需求
针对（1）中不同角色的不同需求，设计产品，明确不同需求在产品中的用户操作流程及解决路径。
A、针对需求1——卡顿原因定位及卡顿原因核实
B、针对需求2——单一学生卡顿原因定位
C、针对需求3——卡顿数据监控、个例case分析
根据需求类别操作流程及对应功能同1和2
（3）设计页面及输出文档
通用流程，包括设计页面交互-ui设计-输出文档，不再赘述。
5、数据开发及验证
接下来开始设计数据库及数据开发方案。大概内容为：首先，建表1将上报日志埋点数据做事实呈现，其次，建表2将按照验证通过的数据方案（何种情况判定为卡顿、何时报警、卡顿原因是什么）自动执行脚本的展示在表2中，涉及到敏感数据，不详述。
6、页面开发
产品及数据方案确定后，即开始前后端开发，将数据在页面中做可视化展示。仍通用流程，不再赘述。
四、心得体会
1、为什么转行？
拥抱产业互联网，且数据是核心价值，与数据相关工作会越来越值钱。
2、数据产品和用户产品的工作内容差异在哪？
最直观的是增加了“数据处理”这一环节，衍生出来的工作内容包括：设计数据上报规则、设计数据库结构、了解数据处理逻辑、跟进数据开发；核心思维转变即数据驱动。
3、To B和To C产品的差异？
一些常规的差异不讲了，说我的感受：
（1）To B相对比较寂寞；经历过发放用户调研问卷仅回收了一份的尴尬情况，相应的，成就感也会小些；
（2）业务流程主导，业务流程主导，业务流程主导，产品最终为了业务服务，即使不直接盈利，也是为了促进盈利；
（3）有机会当面接受或不小心听到用户吐槽你的产品。
4、如何快速了解业务？
首先，了解行业专业术语，比如什么是推流、拉流、帧率、码率、源站、首帧等；
其次，把握核心环节，比如刚接触项目即主动申请去重新梳理上报日志埋点文档的工作，因为了解了上报日志埋点，业务就熟悉了一半了，所有的数据分析、数据统计都是基于上报日志的；
最后，多问多问，有个经验，刚进新的项目可以尝试早到晚退，尤其晚退很必要，因为一般晚上大家心态比较放松，可以准备一些问题请教同事，哪怕是纯粹沟通感情也好。
5、关于项目管理
自从主导过40+人的项目之后，一般的项目都能hold住了。
首先，需要严格管理时间点，包括启动开发、提测及上线时间，每天全团队同步进展、风险；
其次，当多方同时且相互依赖上线的情况，考虑到每一方上线失败的处理方案；
再次，真诚的欣赏团队里的每个人，比如在开发过程中前端小哥乐观的态度、比如测试小哥认真负责要了解全局逻辑的心态、比如测试小哥哥从用户体验角度提出来的质疑，都是动力；
最后，自己没考虑清楚，错了就是错了，及时认错改正能保证及时止损，至少大家跟你做事儿心里不委屈。
6、关于是否一定要懂技术？
上家公司领导教会我受用终生的道理有三个，其一，复杂的实物可以简单理解，比如虽然不能完全理解技术架构，但可以通俗的按照信息层级和信息流向来理解，这样能解决60%的问题；其二，事情只有适合谁来做，没有不该谁来做；其三，真诚的认同别人，她和我们沟通的口头禅是『你说得对』、『就像你说的...』、『按照你的想法继续延伸...』
另外，走到哪，都会有个和我超好的技术小哥哥~~哈哈哈哈