坑一：数据展示徒有其表
什么叫数据展示徒有其表，就是功能不够设计来凑。刚开始接触DMP、大数据平台的时候，对于接收的数据，通过酷炫的图表展示，柱形图，桑基图等等等等，看起来很酷炫，但是实际的价值，除了国企所谓的给领导看的大屏展示有些实时监控的意味在，大多数情况都是摆在那没有用。
比如我之前设计的资源引入概况，对于运营商来说，需要知道各种互联网资源的引入情况（引入的背景类似于缓存，例如腾讯视频这个网站如果做了运营商的缓存，最终用户上网会更快）。我的设计就是从整体角度去分析资源引入的数量、引入到本网的占比、本省的占比、以及引入的资源归属ICP的排名、各公司引入资源的数量对比、时间趋势等等等。乍一看没有问题，但是，重点是，这样的数据展示，确实能够囊括资源引入的方方面面，但是他能解决什么问题呢，用户能从这个界面读出什么吗？
这就是所谓了数据产品第一坑，图表化展示数据不能解决实际问题，徒有其表。只是单纯的画出来好看。
坑二：万能的BI工具不万能
BI工具是一个好工具，但是，工具的作用是对工作有用。不是所有的场景都适合BI。BI的特点是能够通过界面化的拖拽自助分析，起到灵活分析的效果，而不用像传统系统一样，任何一个报表都需要开发。
他的缺点是，高度依赖业务分析人员。所谓业务分析人员，不是指负责业务的工作人员，而是指专职处理业务问题的数据分析人员。他需要知道业务数据分布在那些数据库表，需要知道业务上的数据流转规则，需要知道业务问题应该用什么样的定位思路去解决。
单纯的BI给到用户，如果用户不是一个分析业务的人员，只是一位甲方工作人员，大概率得到的反馈就是，这个工具非常好，你能帮我解决**问题吗？（哭笑）
所以，产品设计的对象和场景一定要弄清楚，如果甲方没有专职的运维人员或者数据分析人员，不用强推BI，即便它再灵活
以上两坑总结起来是一个同样的问题，没有经过方法论总结下来的图表分析展示，只是一堆图，不是解决方案，而客户想要的是通过视图化呈现的一套解决方案，他希望通过直观的图表知道现在存在的问题，导致问题的原因以及如何去解决。
所以，后来，我的设计仍然是图表，但是确实经过方法论沉淀的图表。（涉及商业机密，不便截图）
总分结构，先说结果，再说原因和方案，形成闭环。
一、结果：通过顶部区域的文字展示，列出问题、原因和解决方案
二、分析原因（倒叙方式）
例如发现淘宝网打开网页时间长。（这是结果）
倒推：哪个时间端时间长->当前时间段的淘宝服务器ip是否正常->途径网路是否正常->用户基站/终端是否正常。（大的分支）
小的分支：如果是淘宝服务器ip，有10个，其中2个IP时延长，则在此分支，分析2个IP归属的网络。
如果IP归属异网，可以考虑资源引入，如果归属本网则继续分析是否拦截、路由策略是否正常...
以上是运维方法论的一个问题处理流程，对于大部分的问题，都是按照一样的套路解决，这些问题就可以沉淀为产品，并且通过图形化的方式去展示（而不是一堆LINUX代码）。
根据分析的原因提出解决方案。（此处如果能跟业务系统打通，一键解决，那是最好不过的了。产品届流行的一句话叫做“把客户当傻瓜”）
所谓数据产品踩的坑就是，过于注重数据和图表化（方式方法），而忽视了解决问题的内涵。
网友评论