数据管理后台产品，入职3个月躺过的坑.docVIP

数据管理后台产品，入职3个月躺过的坑 　　从8月到11月，花了大量时间，躺过那么些坑，走过那么些弯路。幸好最后的结果是，能为程序开发提供可以在少量时间内完成工作的规划支持。 　　 一．我尝到第一次甜头　　8月19日 工作总结：老大对需求表指导以后，地域管理将功能落实到可操作层面，优先级确定会议20分钟开完，需求得到认可，较顺利。　　就这样，一个简单的地域管理需求梳理，功能梳理，用简单表格描绘出单个功能，需求得到认可，进入开发阶段··· 　　咦，貌似没那么难。就这样，开始了下一个阶段——生产数据的管理。 二．趟过的初级坑——认知层　　8月26日 工作规划与总结：梳理生产数据；一天处于混乱当中，数据太多，27加班整理。　　8月29日 梳理专项数据和综合指标；专项数据和综合指标数据并不多，开始整理数据组织原型。　　8月31日 初略数据组织方式原型结束，和刚哥讨论。研究数据指标体系，理解并 背诵注释。数据指标重新整理分类；数据组织结构原型结束，几个问题：组织数据时，完全根据业务表格进行采集，仅分析维度的相似性和实现方式的统一性，而不是从公司业务、数据性质和意义去进行规整分类。对各数据的标准定义，没有深层次理解，以至于在规划时没有很明确的界限，导致混乱。对公司数据指标，维度这些概念没有清晰认识。　　这是趟坑的开始…… 　　这是一个初级坑，在对数据进行整理时，按照对接文档，将所有出现过的数据整理一遍，罗列在一起。在出现例如“交易额”“零售额”的字样时，没有去考虑其中包含的维度和统计范围，公司定义和公众普遍认知的定义，而只是将这些名词，按照提供的数据，完全无脑罗列在一起。在需要对数据进行分类时，没有去考虑分类的意义究竟是什么。 　　所以，我有了这样的原型设计。 　　咳咳，先说一下设计的思路：所有指标都有时间、地域天然属性，在对接文档中的，交易额又有行业属性，我把这些有共性的提出来，只需要选择好共性的东西，再去选择具体指标内容就好啦。分组方面呢？交易数据挺伟大，单独成为一组；成体系的指标单独一组……这样，从页面扫过去，我一下子就可以看到我想要的指标内容啦。 　　可是，问题： 交易数据的各种转置，从哪里实现；综合发展指数指标体系这种惰性指标数据或者其他数据，不需要同比环比的计算与显示，这些功能作为全局放在这里的意义；最low的是，全部具体指标内容罗列与此，有大量新增时内容查找如何实现等等。　　这些问题的出现，源自于整理数据之初，对各指标的意义、诞生、应用没有清晰认识，对产品的认识不够深刻，没能把握需求的根本，以及产品的要义。 　　当你发现你以前做的东西就是坨狗屎的时候，你就成长了。但是我看这个坑，里面是一万坨。 　　9月22日 总结：各种类型的数据，所需维度，彼此间的相关性都会有所不同，不能做成统一的格式去满足所有类型的数据查询，将所有数据放在一起实现查询功能会显得杂乱，且不能对个相关性数据进行精细的查找。必须实现模块化。　　有这样认识后，有了这样的原型 　　等等…… 　　虽然将数据按照模块划分进行管理，却没有真正按照数据其本身具有的特征设计功能，还是一坨屎。 　　9月第4周 计划：PPT2.0进入开发阶段，完成生产数据库规划；总结：之所以对数据的梳理花了这个多时间，是因为没搞清楚为什么做梳理工作，目前公司数据是什么状况，要达到什么目标，改善什么，用户需要什么，开发需要什么。　　直到这里，我才意识到问题，显然，走了接近3个周弯路··· 三．趟过的中级坑——操作层　　在意识到以上问题后，从另一个方向出发，数据模块化管理。 　　9月2日 生产数据管理系统——交易数据模块规划。总结：研发部关心的数据是这类数据的维度，以便设计数据底层结构。这些数据维度最好的体现就是具体提交的数据表格，但是除了交易数据，对于其他数据而言还没有统一的较规范的生产数据格式和维度，这个可以从研发、数据部、产品出发一起去规范。而产品应该关心的是公司整体有什么数据，要对哪些数据进行管理、查询、提取等操作，必须要对数据有整体的认识，并且根据用户实际使用需求和数据的生产情况，对数据进行整理归纳，对有相关性的数据实现模块化管理。　　9月30日 对交易模块进行产品需求梳理，寻求需求表达之道。　　10月8日 修改产品需求文档，交给刚哥评审。总结：将查询流程和查询流程中的名词定义放在查询模块下面，将逻辑表达清楚。　　10月9日 修改产品需求文档，交给刚哥评审。总结：切记，不要还没有说是做什么的，就告诉大家怎么做。文档的目的在于能够很好引导读者去明白你说的事，当有相对生疏的概念出现时，应该及时作出相应解释，关键问题应该及时举例。　　10月10日 完成PRD最后修改，发给测试查看，做文档总结。　　至此开始第二个趟坑。 　　在这个趟坑的过程，先意识到，地域管理系统和生产数据管理系统的不同。管理系统