总结文档 高效利器

在平时的工作中，你是否遇到这样的情况：

一个棘手的问题急需解决，但是你却没有太多的时间去研究，因为后面还有一堆其它的工作要做，你只记得曾经遇见过类似的问题，但是大脑中只剩下一丝模糊的印象；面对一个新的项目，你有种摸不到头脑的感觉，你不知道如何才能迅速在这个项目上游刃有余；经过谨慎编写的TP（test plan）, 却在客户进行UAT的时候发现测试步骤的描述中出现了重复的序号；在Code Review的时候，你的代码中写了一个让人很无奈的if(a == true)的判断，你的变量后面又一次拖着隐形的小尾巴，没有trim……

 

总结文档，一个简单，高效的工具可能会给你问题的解决带来新的希望！

1. 似曾相识的解决方案

俗话说的好，好记性不如烂笔头。如果能够-在每次遇到问题的时候，不妨把视野放的长远一些，不要只为这次的需求来应急处理，考虑是否同样的问题以后也会遇到，如果会，那就抽丝剥茧，把问题搞明白，然后归纳写到文档中，那么如果下次遇到类似的问题，即使你只有模糊的印象，查看一下你的文档，你就会迅速找到问题的突破口。这个文档即是我要说的总结文档。

笔者之前做AMAX MES的时候，就遇到过这样的问题。一开始，笔者没有总结文档这个习惯，同样的问题会在不同的时间让我重复思考，浪费了时间和精力，吃过几次苦头以后，我就先把问题搞明白（不一定要全部明白，能解决目前的问题就行），总结下来，下次遇到类似的问题，这个文档就很有用处。

 

在pnuts中，时间的处理总是我们很头疼的问题。 例如，客户需要用Form来显示特定格式的时间，time类型和string类型如何灵活转换…… 那么这个时候，如果你对于如何做一头雾水，花了好大力气来四处查询API，研究pnuts中的时间类型，那么我建议你，把这个知识点搞明白，然后归纳写到总结文档中，那么下次遇到类似的问题，你的效率会大大提高，直接查查你自己总结的文档，很容易就知道怎么来做了。即使上次的总结不能完全解决这次的问题，那么上次的总结也是这次解决问题的垫脚石，你的思路不会从零开始，对于问题的解决也起到了加速推动的作用。这次问题解决完了以后，你又可以把这次总结的东西写到文档中，来改进和完善上次总结的知识点，这样坚持下去的话，我想以后遇到类似的问题你基本上都可以轻松搞定。

 

下面是笔者之前总结的部分时间处理文档：

那么，如果下次遇到同样的问题，上面的这个总结可以让你在最短时间内解决问题。

 

下面再举个例子：pnuts中的DCS使用是个较为复杂的知识点。不过，只要你在开始遇到关于DCS的处理问题，花点时间，把DCS的API，On line-help研究一下，对于不确定的地方在PD中试一下，然后把你的总结写成topic为DCS Manual的文字，写入你的文档中，那之后关于DCS的问题，你都有这个资源可以利用。下面是笔者之前总结的：

看过上面的总结，如果你要获取运行时的dcs，你一眼就可以知道只有那么两种方法可以使用了；你一定不会试图去直接通过key查询Dci，因为你的文档中已经明确写了，那是不可能的。

 

同样还有好多有用的东西可以总结，比如如何轻松使用pnuts，调用生成漂亮的Excel；FTPC中有几种用户权限，每种对应的数字是几；pnuts中如何引用Java类；MSSQL中 with rollup, with cube如何用；如何通过用户角色查询所有用户；以至你研究，思考了好久的一段业务逻辑； 你费了好大力气想出来的solution；甚至是你使用的测试环境的用户名和密码你都可以在一个worksheet中记录或总结下来。总之，只要你认为下次有可能能用到，对你有价值的都可以总结到这个文档中。

 

关于如何使用这个文档，笔者有几点建议。

第一， 用最容易理解的文字，简洁明了，清晰的写到自己的文档中。

用最容易理解的文字，这一点很重要，如果你自己总结的东西自己都看不懂，那可就是吃力不讨好了，这个时候应该想想，我用什么样的文字能够让以后某个时间的我很容易理解现在的我。

第二， 为这次总结的知识点加个topic，以备下次从文档中很容易搜索到它，我感觉Excel作为这个文档很好用，可以使用表格的一列作为topic，比如你总结的是FTPC的DCS处理逻辑，你就可以在topic这一列，写上DCS Manual。

第三， 把这个文档直接放到电脑的桌面上，比较显眼的地方，每次遇到问题想要查阅的时候，直接Windows+D，你就可以打开这个文件了。

第四， 这个文档可以有多个页面，比如Excel中多个WorkSheet，分门别类的总结，比如，把关于DB的总结放到一个页面，命名为DB SQL Tricks，把代码逻辑放到另一个页面，命名为Common Tricks，当然你也有总结业务逻辑的页面 Business Unit……

 

不要认为这样是浪费时间，等下次，你遇见一个似曾相识的棘手问题时，你的文档可能就是救命稻草，反而节约了时间。

也许你会说，不是有API可以查阅吗？是的，API是可以查阅的，第一查阅API总要浪费时间来查，API一般都很庞大，第二API的东西是别人系统总结的，你很大程度上要先理解别人的东西然后才能思考该如何做，而你自己总结的东西确是可以直接拿来用的。（当然，如果你感觉对于某个知识点API写的很清楚，查询也很快，那就不用总结到这个文件中了）

2. 持续改进的有力工具

总结文档还是持续改进的有力工具。

回想一下笔者从最初的对AMAX MES系统的不了解，到后来的熟练分析，设计，编码和测试，这都是一步步积累起来的，总结文档在这其中起到了关键的作用，通过总结文档来持续改进，让客户的满意度有了明显的提高。

 

面对一个新的项目，可能会让人无从下手的感觉，尤其是当项目的文档不全面，项目经历了好多年，好多人的加工，那么想早点上手可能确实是件很困难的事。笔者就有这样的经历，但通过总结文档，在工作中，不断的总结新的问题，对于之前遇到过的问题，总结文档已经提供了之前思考的成果，这样就有更多的时间来考虑，是否有新的，更好的解决方案，如果有，那就更新这个总结文档，在总结文档不断改进和完善的过程中，我们的产品质量也越来越高，这让笔者在这个AMAX MES的项目上走的越来越顺畅。

3. 保证工作质量的秘密武器

总结文档还有另外一个好处，就是可以作为一个提高工作质量的工具来用。

在平时的工作中，你是否会遇见你写了一个让人看了很无奈的判断if（a == true）；你的Form大小没有达到标准，控件颜色不符合要求；你没有check可恶的NullPointException；你的TP（Test Plan）中，序号有问题，你测试的scope不全……

问题很多，也很烦，我们有的时候不能够专注于最核心业务的解决方案，却把大量的时间花在这些小问题上。你可能会说，我工作很严谨，一般不会出错，但你是否每次检查你的成果的时候都要提心吊胆，小心翼翼，生怕出了一点小的纰漏以至全盘结束；你是否能够保证以后不会发生同样的问题，如果你不能，那就可以听笔者说说这个秘密武器。

 

在Excel中建立一个新的Work Sheet：Check Point。比如你是程序员，你要写大量的代码，那么在提交代码之前，你一定需要检查一下代码，那你就可以总结你经常出现的，容易出现的一些问题，把这些问题总结成1，2，3，4，5，写到你的文档中，每个都有一个topic和详细的Description，你在检查代码的时候，就可以对照着这些容易出错的点来发现问题。每次遇到新的问题，都可思考一下，同样的问题是否以后还会出现，如果会，那就把它总结到你的文档中，文档会不断的改进，工作的质量也会有明显的提高。

下面是笔者之前总结的部分代码检查点总结和TP检查点总结：

使用上面的Code检查文档，你的没有trim的问题就会及早发现，而改正。

如果你严格按照上面这个TP Check Point来检查你的TP，你的TP一定不会出现序号的错误，因为第一个检查点就是关于序号的，那意味着你要首先检查所有的序号。

 

总结

文档的总结能够给忙碌的工作一个喘息的机会，能够收集你工作中一个个弥足珍贵的经验，能够提高你的效率，保证工作的质量，能够为棘手的问题指明方向，能够让工作忙而不乱，拙见成效。