七步，改变你的纯文本报告面目

所谓纯文本工作报告，即用纯文本对工作进行总结汇报。由于没有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 客户让我方调查的课题，代码合并问题，已解决。

最后，祝愿大家都能写出高质量的报告，谢谢阅读。有什么更好的技巧，还望指教，以期进步。