1.只对数据做了一个定义
我在想为什么统计分析里面的数据到了测试的阶段会有这么多的问题？
由于系统本身的复杂性，数据的复杂程度非常高，有一些数据会出现在好几个地方，很容易造成当初规划时的考虑不周，很难明确到数据的来源，比如说收入金额与退款金额，大家都知道实际收款是收入-退款。然后文档里面也只是给了这么一个很简单粗暴的定义，因为本来是想让更熟悉系统数据的技术人员去直接定位出我想要的数据，呈现给我。所以开发的过程当中，技术看到这个定义，是明白怎么开发的，可是到了测试那里去，就是悲剧了。
测试的时候测试人员就是个小白，他们指望的就是产品文档里面的描述及定义，他们也许对数据库也很熟悉，可是他们不是开发啊，他们要测试的时候就要知道哪个是对的做法，而我的文档里面，恰恰是少了这部分的数据来源说明。造成了有定义有公式，可是就是没有明确数据来源给他们，雾里看花终隔一层。然后我这边就少不了被测试怼了，怼你你也得接着，因为这是你的锅。
规划统计的内容时，首先要有个定义，然后给出公式，明确数据来源。
面对一些复杂的系统，数据来源本来就似是而非的系统，必须要明确好，不然很容易造成开发、测试、产品的一脸懵逼，然后耗费大量的沟通时间，很容易造成开发工程延期。
2.项目升级单的必要性
为什么线上的版本的达不到预期的效果？
当项目新版本开发完成，并且顺利通过测试之后，升级单是一个非常必要文件，它要明确升级的内容，升级后的效果，甚至连升级的步骤文件都要表明，方便运维人员的查看备份。
很多小公司里面，就没有升级单这事了，或许也没必要写升级单，为什么？因为开发是那个人，升级的也是那个人，所以升级单在这个时候就显得有点鸡肋了。其实不然。
飞行员每次起飞前，都要按照飞行检查单里面的每一项内容进行确认，即便你有着非常丰富地经验，都要严格地按照这份检查单清单的内容进行确认。在我看来，升级单的作用与飞行检查单的作用是一致的，都是为了避免人为的因素而导致的事情出错。
公司项目的升级是交给运维部门的人员去进行的，开发是技术部的事情，测试是测试部的事情，每个人的职能是区分得十分清楚的，而运维人员由于之前并没有参与到版本的开发当中，是不了解你这个版本的升级效果。很多时候只根据自己的经验以及咨询一下技术人员要升级哪个文件哪个包是不够的，对于一些大版本，各部门的负责人都会留下来确保版本的升级迭代正常，如果是一些小补丁，就没有这个待遇了，往往只是运维人员一个人去处理。
升级多数会选择深夜，因为影响得范围会最小，如果没有这个升级单，在升级的过程中出现了偏差而导致与升级的目的不符合，那你整晚都不用睡了。升级单在这个时候就显得尤为重要了，首先明确了要升级的内容、效果、文件，另外还可以附带测试结果以作参考，最大程度地保障了你想要的升级效果，另外还可以明确责任，避免运维与技术相互扯皮，杜绝一些不必要的麻烦，譬如线上以前并没有的问题，升级之后有BUG，技术人员找了半天，才发现原来是由于运维升级的时候升少了一个文件或者是一行没报错的代码，技术人员这时候的心情之差可想而知了。
所以嘛，作为一名产品人员，你的升级单还是需要写一下的，无论公司之前有没有这个规定，写下来对项目的升级质量都会有个保障，起码你自己会心里有底，夜晚也能睡得香。
升级单的格式是什么？根据自己项目的需要或者根据公司原有的升级单格式去写啊，当然了你也可以去百度谷歌一下的，反正我觉得只有适合才是最好的。
