从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最后修改，发给测试查看，做文档总结。
至此开始第二个趟坑。
在这个趟坑的过程，先意识到，地域管理系统和生产数据管理系统的不同。管理系统之所以能用简单的EXCEL表达功能点，是因为这个系统的独特性：
地域管理内容标准化，有大家普遍接受的规范；
相对稳定，地域分层固定，地域种类相对固定；
操作界面面向用户和对象相对少量，关键点在于后台解析。
只要把握住地域变更的几种类型，梳理好需求，确定好地域管理系统需要实现的功能即可。但是生产数据管理系统，管理对象多样化，使用用户面向全公司员工，甚至要对接全部产品环节的数据。简单的功能与操作界面绝对不能满足所有的功能。
从网上搜索，一篇产品文档应当具备的要素，开始了第一次规范化的，死板的写作。
在这个坑中，不得不矫情的感谢尊敬的老大。在无数次文档评审中，标点符号正确应用、序号的标注，参考文献的插入、读者阅读引导、生僻概念的提前描述、功能交互的逻辑表达，刚哥细心教导。这些指导让我明白，一个好的文档应该做到怎样的标准。一篇好的文档，不管读者是谁，看到内容后可以明白你想做的是什么，没有混淆生僻概念，阅读体验舒适，有适当引导，逻辑清晰，章节间描述对象明确详细。这样的文档，可以提供给研发作为产品开发依据，可以提供给用户作为说明文档，提供给其他部门和新同事作为业务了解入口 。这次进阶，收获了对文档要求的认知。
四．趟过的进阶坑——体系建立
在生产数据管理系统模块化规划和大数据公共服务平台规划时刚哥发现，要实现对目前杂乱的数据和未来可能扩展的数据进行规范管理，方便内部用户和客户方便查询，支持指标维度和内容的拓展，必须要建立一种指标构建表达方式。这种方式应能适应于所有指标的描述，能支持研发人员做相应的底层设计，能形成公司的指标规范。
10月20日
10月24日
指标列表建立
总结：用一种集群的表达方式，将分组当做是指标的一个属性；而分组的属性应该另外单独说明。指标列表不应出现指标级别，因为指标应该是比较独立的存在，在对某个指标进行计算时，可能会用到。
10月31日
在不断的产品部、研发部会议中达成共识，最终形成了主词、属性、时间、地域、行业为组织要素的指标表达方式。
指标体系的建立，是一种思维方式，应该是产品经理应该掌握的敏锐思维和站在更高角度看问题的能力。这次进阶，收获了产品思维方式的认知。
五. 趟过的终极坑——整体规划
10月31日
总结：建立初步规划文档的错误
将指标列表的能表达的意思在思维导图上重复表达；
将自定义分类定义理解错误；
系统的规划除了切合目前情况，应该有一个更高的全局角度。
11月2日
总结：生产数据的梳理，在于全局了解生产数据后，能够将这些数据组织起来，能站在业务和全局的角度，去查询导入这些数据。
11月4日
完成生产管理系统功能细节规划，召开会议
在做整体规划之初，还是想以之前模块划分的方式去进行数据的导入、查询和导出。在这里，前面的思路会对整体规划产生影响。数据模块化，只是数据组织的一种方式，比如说按照业务去分类时，并不是因为指标天生有业务分类属性，只能服务于该分类。指标诞生的契机可能因为某项业务，但只要形成了一项指标后，它就可以服务于多个场景。
所以，最终需要管理的不是业务分类中的模块，而是一项单独的指标。业务分类的意义在于按照人们的认知，去组织这些数据，以便服务给有相应需求的用户。每项指标，有其独特性，定义、统计口径、组成的要素、各维度范围、生产的实际情况等各有不同。产品的职责是，发现杂乱数据中的规律，明确数据管理系统管理对象的根本，将规律提升到可操作的体系，在体系内去满足各种特性需求。
重新整理认知，了解数据在数据库的存储格式以后，对需求和系统职能有了全新意识。开始进行全局规划文档的编写，得到长期困扰后的第一次认可。
11月11日
完成产品原型，将需求录入和文档更新到最新状态
总结：目前撰写文档遇到的问题：
信息的罗列
名词，概念定义不明确，全文不能统一使用定义
单个功能点的来源与诉求思考不全面
文档的管理混乱，修改前和修改后的文档管理不清晰
撰写原型效率问题，目前影响因素：模块间有可复用部分，但又有单独部分。直接复用会造成后续发现不能满足独特性，没修改完善就开始复用导致重复复用。
解决方法：制作之初，全局考虑有什么模块，主要复用哪些。先把可复用部分做大做全，其他模块在此基础上做减法。某些结构可以做成控件形式，直接复用。
至此，系统从终于进入开发阶段。
11月30日
可以验收。
就这样，花了大量时间，躺过那么些坑，走过那么些弯路。幸好最后的结果是，能为程序开发提供可以在少量时间内完成工作的规划支持。
六. 开启继续趟坑之路
每走一个新的步伐，总能遇到一个刚出炉湿哒哒新坑。下面的坑肯定会更深，我需要能具备独立思考用户需求与产品功能关系的能力，学习统计学，了解数据采集技术，数据处理模型，数据分析方法，各种数据产品的研究……
还有很多未知的深渊。总之，做好趟坑的准备，希望完成了一次完整趟坑过程后，以后能找到比较帅的趟坑姿势。
文章写在上月，想给产品部新菜鸟做反面教材的，逛了这么久人人，发现终于自己有篇文章可以投递啦，哈哈哈。
昨天开发完成了数据审核复核模块的开发，今天刚把指标管理子系统的方案提交上去。
入职后，我的路迹就是：
不知道做什么——别人说什么做什么——别人说什么我能提出疑问——要做什么我给方案
虽然还是很菜，有进步就好。
