离岸开发-报告有效的数据
在离岸开发工作中，做为offshore的我们，经常要向onshore做一些报告工作。例如，每日的进度报告，每周的进度报告。
报告的内容各种各样，但是，我们是否思考过这样的问题：什么样的报告才是好的报告？
请看下面的这个报告内容：
今天做了3个功能，基本都快完成了。
其中一个有一些问题，正在和onshore确认。
另外一个明天能完成。
另外需求上可能有所变动，很可能会影响明天的进度。
乍一看这个报告好像没有什么问题，可是，如果你仔细琢磨琢磨，那这个报告就有很大的问题了。
1、＂基本快完成＂，究竟什么叫＂基本＂呢？有的人觉得还差2小时叫基本，有的人觉得还差6个小时叫基本，有的人觉得写完代码， 不进行简单的测试叫基本。基本上，这个＂基本＂的概念太模糊了，看了这个报告，你基本不知道3个功能到底完成到什么程度了。
2、项目整体的进度到底是正常还是延迟还是提前呢？从上面的报告完全看不出来。
3、花掉的成本与预计的是否一致？是超出了，还是有富余？从上面的报告里看不出来。
4、报告里写了＂很可能会影响明天的进度＂，但是会有多大的影响呢，也看不出来。
可以看到，我们虽然汇报了项目情况，但是和没有汇报其实没什么区别。因为报告里体现不出来有意义的数据。
作为当事的人来说，很多东西其实都是装在脑子里，但是反映不到纸面上。
写报告的时候，觉得这样就足够了，但是对看报告的人来说，好像看到了不少东西，但是一琢磨，却看不到具体的东西。
怎么才能汇报有有效的数据？有一个基本的原则：用数据说话，而不是模糊的词语。
与其说＂基本快完成了＂，说＂进度完成了90%＂会更有效。使用数字，可以避免不同人之间认识的差异，避免造成误解。
对于进度、成本的报告，推荐使用科学的、广泛使用的方式：SPI与CPI。关于这两个数据的计算，可以查阅相关的资料，并不是十分难以理解。
如果项目存在问题，一定要描述清楚，让onshore清楚问题的现状。同时，仅仅提出问题是不够的，我们还需要提出至少一个解决问题的方案。
针对上面的报告，我们可以修改成如下的样子：
1、整体进度
SPI：0.95 CPI：1.1
2、今日进度
功能A：100%
功能B：90%
功能C：95%
3、其他
今天的功能B中，画面跳转有一些问题，正在和onshore确认。
功能C明天能完成。
*功能B的需求有可能会变化。如果变化的话，根据难易度来调整初始的计划。
CR管理需要与某某联系。
从上面的这份报告中，我们可以明确很多之前不明确的信息：
1、整体进度有些迟延（SPI=0.95）。虽然不多，但是onshore如果觉得问题严重，可以立刻发现问题，与我们探讨。
2、开发成本超过了预计成本（CPI=1.1）。
3、今天的三个功能的完成情况一目了然。
4、对于功能B的问题及所产生的后果也很清楚。
自己写完报告后，有一个方法，可以检验自己的报告是否有效。那就是针对报告的内容，自己提一些问题，看看能不能解答。
（记住是站在onshore的角度来问问题）
例如，上面的报告虽然已经很清晰了，但是我仍然可以问一些问题：
1、目前进度有延迟，有没有什么补救的措施？
2、成本有些偏高，原因是什么？有什么补救的措施？
3、功能B出现了需求变更，其他功能是否有类似的情况？
把这些问题的答案写到报告上，我想应该会是一份不错的报告。
报告绝不是走过场，走形式。我们既然花费了时间去做报告，那何不做一个有效的报告呢。
掌握了其中的技巧，我想做一个有效的报告就并非什么难事了。
报告有效的数据，会使我们与onshore的沟通更加顺畅，消除了彼此认识的歧义，会让双方的工作都更加有效率。
