[若有所悟]七步，改变你的纯文本报告面目
所谓纯文本工作报告，即用纯文本对工作进行总结汇报。由于没有Excel强大的数据处理功能，没有PPT绚丽的表现形式，很多人做出的报告都很难让人读懂、甚至晦涩杂乱。
本文，从最原始的一篇报告开始改起，通过7步法（个人理论），将其变为一篇通俗易懂、合格的报告。
原始报告：
上午看了一个小时的需求说明书，另外参考了OutSpec和InnerSpec，算是又通读整个功能A了，发现了一个需求上的问题，就是哪几种状态的XXX可以对它的xx进行修改。跟组里人和领导商量之后，发现是一个我们这边无法解读的需求，已经作为需求疑问QA出去了。接着，根据上周做完的SD，差不多11点左右开始了PG，上午编了差不多0.2ks的代码。
下午用了一个小时完成了整个功能A的实现，总共0.43ks的代码，有待评审。
A功能的PG完了，领导安排让测试功能B，客户说这个功能好像有问题，想知道是不是我们这边的代码问题，已经登录到Redmine上让我们调查了，所以我就测了一下，最后发现在模拟器里没有问题，但是在实机环境有问题，客户后来说不是我们这边的代码问题，是他们代码合并的问题。B功能测试，之后，进行了C功能的黑盒测试，我测了30个用例，有1个Bug，还有一个因为模拟器无法测试，所以搁置了，可能会耽误进度吧。
随便拉一个普通人，阅读上面的报告都会觉得乱，除非某个上司时间多的用不完，或许会一字一句的“研读”这篇报告。更多的情况，应该是直接丢掉不看。下面，开始修改我们的原始报告。
第一步.分类
分类的方法有很多，而常用的分类方法有两种：时间类和空间类。
■时间类。即以时间段为类，将各时间段的工作放到一起。
■空间类。即以工作内容为类，将耦合度高的工作内容放到一起。
[原始报告]是用于给上司看的，从上司的角度来看，其关心的是你做了哪些工作，而不是你在什么时间段做了什么工作。所以，依照空间类分类，会让上司一眼看出汇报者工作的内容，修改后的效果如下：
A功能编码作业
上午看了一个小时的需求说明书，另外参考了OutSpec和InnerSpec，算是又通读整个功能A了，发现了一个需求上的问题，就是哪几种状态的XXX可以对它的xx进行修改。跟组里人和领导商量之后，发现是一个我们这边无法解读的需求，已经作为需求疑问QA出去了。接着，根据上周做完的SD，差不多11点左右开始了PG，上午编了差不多0.2ks的代码。
下午用了一个小时完成了整个功能A的实现，总共0.43ks的代码，有待评审。
B功能调查作业
下午，领导安排测试功能B，客户说这个功能好像有问题，想知道是不是我们这边的代码问题，已经登录到Redmine上让我们调查了，所以我就测了一下，最后发现在模拟器里没有问题，但是在实机环境有问题，客户后来说不是我们这边的代码问题，是他们代码合并的问题。
C功能测试作业
进行了C功能的黑盒测试，我测了30个用例，有1个Bug，还有一个因为模拟器无法测试，所以搁置了，可能会耽误进度吧。
上面的报告，对于上司来说，可以一眼看出来这个小伙子做了哪些工作，一眼明了，这小伙子一天没有白忙活，做了三个作业。
第二步. 条目化
条目化的目的是让看报告的人一眼观全局，很多新手担心领导不明白自己写的什么，于是大写特写。其实大错特错，领导的经验是丰富的，你只写一句，他或许就明白你要表达什么。所以，在汇报工作上，以简练为佳。
条目化的方法，就是把工作内容核心抽出来，下面是条目化的效果：
A功能编码作业
1.看了一个小时的需求说明书，另外参考了OutSpec和InnerSpec，算是又通读整个功能A了，发现了一个需求上的问题，就是哪几种状态的XXX可以对它的xx进行修改。跟组里人和领导商量之后，发现是一个我们这边无法解读的需求，已经作为需求疑问QA出去了。
2.根据上周做完的SD，差不多11点左右开始了PG，上午编了差不多0.2ks的代码。下午用了一个小时完成了整个功能A的实现，总共0.43ks的代码，有待评审。
B功能调查作业
1.领导安排测试功能B，客户说这个功能好像有问题，想知道是不是我们这边的代码问题，已经登录到Redmine上让我们调查了，所以我就测了一下，最后发现在模拟器里没有问题，但是在实机环境有问题，客户后来说不是我们这边的代码问题，是他们代码合并的问题。
C功能测试作业
1.C功能的黑盒测试，我测了30个用例，有1个Bug，还有一个因为模拟器无法测试，所以搁置了，可能会耽误进度吧。
上面的报告已经条目化了，可以明显的看到在功能A的编码中，汇报人做了两件工作。
第三步. 简练化
报告不是作文，是给时间少的上司看的，所以要避免大篇幅的废话，以最精炼的语言来描述工作内容，描述问题。简练化后的报告如下：
A功能编码作业
1.需求说明书阅读（Outspec、InnerSpec），发现需求不明点，已提QA
2.编码（0.43ks，待评审）
B功能调查作业
1.Redmine上客户提的课题调查，问题在客户方，代码合并遗漏，已解决，具体信息参照Redmine课题。
C功能测试作业
1.黑盒测试，已测30个，发现一个Bug，一个模拟器无法测试（进度延迟可能）
第四步.数据抽出
在七步法里，这一步其实是最难的，需要经验的积累，需要敏锐的直觉。就本报告而言，我们来分析一下，缺少什么数据。
1.A功能编码作业→需求说明书阅读（Outspec、InnerSpec），发现需求不明点，已提QA
作为阅读者，想知道这个式样不明点是什么，他无法找到该问题，因为QA没有编号，没有提到登录的地方。所以，可以追加数据：QA#123，用于指向问题本身的信息。
2.A功能编码作业→编码（0.43ks，待评审）
作为阅读者，想知道这个功能当初预估的代码有多少，与实际代码量的偏差是多少，是不是在计划内完成的。他是无法得知的，所以，可以追加数据：预估代码量，代码量偏差，计划时间表。
3.B功能调查作业→Redmine上客户提的课题调查，问题在客户方，代码合并遗漏，已解决，具体信息参照Redmine课题
同1.作为阅读者想知道问题发生的具体细节是无法得知的，所以，可以挖掘的数据：课题#888，用于指向课题本身的信息。
4.C功能测试作业→黑盒测试，已测30个，发现一个Bug，一个模拟器无法测试（进度延迟可能）
作为阅读者，只知道汇报者测了30个，不知道总量是多少，不知道还有多少量没测，不知道作业是否在进度计划作业内，所以，这里可以挖掘的数据：总用例量，已测占总量的比重，计划时间表。
修改后的汇报内容如下：
A功能编码作业
1.需求说明书阅读（Outspec、InnerSpec），发现需求不明点，已提QA#123
2.编码
-------时间-------------------代码量------------进度------
予定：2012/9/25-2012/9/30 0.5ks -
实绩：2012/9/26- 0.43ks 100%
---------------------------------------------------------
B功能调查作业
1.Redmine上客户提的课题调查，问题在客户方，代码合并遗漏，已解决，具体信息参照Redmine课题#888。
C功能测试作业
1.黑盒测试，一个模拟器无法测试（进度延迟可能）
-------时间-------------------用例量------------进度------Bug数------
予定：2012/9/25-2012/9/30 80个 - 3个
实绩：2012/9/26- 30个 38% 1个
--------------------------------------------------------------------
从上面的报告可以清晰看出来作业进度，以及质量是否在合理的理论阀值内。
第五步.图形应用
图形，就是一些最简单的可以在纯文本里显示的一些符号，主要有：■、▲、※、△、①、ⅱ、→、↑、↓、←、？、★。
图形运用，靠经验，靠自己的美感，所以，如何灵活的运用，靠自己的把握了。这里举两个例子。
1.对于有或可能有风险的地方，用※标识，并在后面注明风险的具体内容。
2.对于大类别，可以用■标识，因为比较易见，可以很快找到类别。
3.对于数据大小发生变化的，可以用上下左右的符号进行标识。
基于以上三点的运用，修改汇报后如下：
■A功能编码作业
1.需求说明书阅读（Outspec、InnerSpec），发现需求不明点，已提QA#123
2.编码
-------时间-------------------代码量------------进度------
予定：2012/9/25-2012/9/30 0.5ks -
实绩：2012/9/26- 0.43ks↓ 100%
---------------------------------------------------------
■B功能调查作业
1.Redmine上客户提的课题调查，问题在客户方，代码合并遗漏，已解决，具体信息参照Redmine课题#888。
■C功能测试作业
1.黑盒测试，一个无法测试※
-------时间-------------------用例量------------进度------Bug数------
予定：2012/9/25-2012/9/30 80个 - 3个
实绩：2012/9/26- 30个 38% 1个↓
--------------------------------------------------------------------
※：无法在模拟器上进行测试，可能会影响C功能黑盒测试的计划进度。
第六步.去冗余
报告类别尽量做到专一，上面的报告还有是有可以改进的地方的，比如A功能编码作业的1和B功能调查作业所提出的课题，属于同一个类型，所以，可以A中的1和B抽出来，去除冗余，做成一个新的类别。修改后的报告如下：
■A功能编码作业
-------时间-------------------代码量------------进度------
予定：2012/9/25-2012/9/30 0.5ks -
实绩：2012/9/26- 0.43ks↓ 100%
---------------------------------------------------------
■C功能测试作业
-------时间-------------------用例量------------进度------Bug数------
予定：2012/9/25-2012/9/30 80个 - 3个
实绩：2012/9/26- 30个 38% 1个↓
--------------------------------------------------------------------
※无法测试用例1个：无法在模拟器上进行测试，可能会影响C功能黑盒测试的计划进度。
■课题&QA
①．QA#123。A功能的需求不明的问题，无法确定哪几种状态的XXX可以将其xx进行修改
②．课题#888。客户让我方调查的课题，代码合并问题，已解决。
第七步.格式化+美化
最后，对于报告的格式要有精益求精的追求，上面的报告还是有美感问题的，格式的调整就看个人的态度和美感了，一下是修正后的报告：
张三的工作汇报 2012/09/26
■A功能编码作业
-------时间-------------------代码量------进度-------状态----------------
予定：2012/9/25-2012/9/30 0.5ks - -
实绩：2012/9/26- 0.43ks↓ 100% ◯（完了，待评审）
------------------------------------------------------------------------
■C功能测试作业
-------时间-------------------用例量------进度------Bug数-----状态-------
予定：2012/9/25-2012/9/30 80个 - 3个 -
实绩：2012/9/26- 30个 38% 1个↓ →(着手中)
------------------------------------------------------------------------
※无法测试用例1个：无法在模拟器上进行测试，可能会影响C功能黑盒测试的计划进度。
■课题&QA
①．QA#123 A功能的需求不明的问题，无法确定哪几种状态的XXX可以将其xx进行修改
②．课题#888 客户让我方调查的课题，代码合并问题，已解决。
最后，祝愿大家都能写出高质量的报告，谢谢阅读。有什么更好的技巧，还望指教，以期进步。
