大量的报告存在，在很多情况 下同样没能解决问题，因为大多研发经理们看到的这些报告，总觉得不是他期望看到的。这些报告要么过于形式而言之无物，要么胡乱记录而缺乏重点。各个基层管 理者大多又不愿意将时间耗费到这些报告上，尤其是对于开发任务紧张的项目经理更是如此，面对这种情况，研发经理们也没啥好办法。
来听听研发经理们最想得到的信息有哪些?我在此大致罗列一下：
1：我想知道我的员工现在都投入到哪些地方去了?这些人力投入是否合理?
2：我想知道我的员工现在都在忙些什么?他们是不是都忙到点上了?
3：我想知道我的员工现在的工作效率如何?他们是否一直保持着一个较高效率?
4：我想知道我的团队开发出的产品的目前的质量状况如何?产品缺陷正在被放大还是处于一个收敛期?
5：我想知道我的几个团队哪个团队做得更优秀?评价一个团队，我希望能够看到团队的整体数据，从进度，到质量，到知识积累等方面的绩效都要能够有 整体了解。
6：我想知道我的团队里面哪个成员做得最出色，我想让其它成员看到为何这个成员是最出色的，对他的出色的认定是建立在完善的事实数据统计基础上 的。
...
再仔细分析一下上面的这些研发经理们“想知道”的信息，有下面几个特点：
1：实时性。即现在这一刻我的团队情况如何?不是1周后告诉我现在的情况如何?更不是1个月甚至几个月后才能够得知现在的情况如何?我关心的是现 在的情况如何?项目经理肯定不喜欢一个3天前就开发人员就应该完成的任务过了1周都还没消息，研发经理肯定不喜欢到产品预定发布日前1周才知道发布还需要 推迟几周!
2: 统计性。有时告诉研发经理们过多细节也是不合适的，一般来说研发经理们更希望知道整体状况。即使去了解大量细节，也是因为目前的细节让他无法获得一个整体 上的控制。一般情况下无需告诉他每个人现在都在干什么，他要知道的是现在你的这个项目组，这个产品组的人的整体人力投入情况，比如为实现某个版本或需求投 入了多少人力?这些人力何时能够得到释放?
3：准确性。告诉研发经理们的任何信息都应该基于研发过程的事实数据，而不是没有任何数据支撑的胡编乱造一番，或者是是误差大得离谱的所谓度量数 据。当然，不要为了这些准确数据而让项目经理或QA拿个本本在研发人员身边做记录，为得到准确数据而耗费大量人力就是得不偿失了。
4：全面性。不要只是告诉你的上司你的团队开发了多少任务，他还需要知道开发这些任务投入了多少人力，这些任务有多少是延期的，这些任务产出了多 少成果(代码和文档);当然还别忘了告诉他现在您们团队质量状况，有多少缺陷等待处理，与其它团队相比，是否你们团队更加要注重质量问题?客户源源不断的 需求有多少正被实现，在这些需求上已经投入了多少人力，预计还需要投入多少人力?