研发主管们如何才能做好过程控制

     主管研发的经理们似乎总有一种冲动，很想知道研发人员每天都在具体做些什么?我曾经共事过的几个研发高级主管多少都有这种渴求。我之前在国内一家通讯企业 公司工作，当时主管我们研发部门的是一个公司VP，这个VP是我的直接主管的直接主管，这伙计就有我说的这个癖好。他每周会组织一个会议，来细问研发的各 个细节(包括，还有多少缺陷没有修改，每个缺陷的修改进展如何，某个客户提出的需求何时能够实现之类的，有时还总是喜欢把我的下属(项目经理甚至某个开发 人员)叫到他的办公室去询问某个具体的技术细节，而且经常就某个问题召开所谓的紧急临时会议(就是不会提前1天安排的计划外会议)，这种讨论会基本上没个 一整上午是完不了事的。每次告诉这个VP某个特性无法在某个时间前安排人力来开发时，他就会叫一大堆相关人员到他的办公室去讨论，这些人从他的职位向下横 跨3-4个管理层次甚至有时包括相关的开发人员。面对这种情况，我心里就会嘀咕：公司应该为这家伙建立一个扁平的组织结构让他管理，他这种搞法根本不需要 项目经理，软件经理，产品经理等，部门二百来人直接“拍扁”了，建立20个团队，每个团队10个人左右，这样他不久可以直接管到底了吗?。

　　离开这个公司有一段时间了，不久前因工作原因与在杭的一个公司的老总交流研发管理时，发现该老总也有类似需求，只是没有我那个曾经的VP上司极端 罢了，我想这应该是一个较为普遍的现象，这不由得让我开始思考这种行为背后的真实动机，我想大致有如下几个可能：

　　1.这种主管是个技术狂人。

　　主管研发的经理们往往是研发出生，有相当一部分是从研发基层逐步做到现在这个管理位置的，由于多年的研发基层工作养成的习惯，对很多东西都喜欢刨 根问底，尤其是对技术细节非常感兴趣。记得不久前在CSDN CTO俱乐部里有一个讨论是：CTO是否应该懂技术，绝大多数研发主管还是比较认同研发主管就应该真正懂技术，而且最好是技术大牛。然而，多数情况下，这 种对技术的狂热往往会导致对下属要求较高，有时总觉得自己能够在研发细节方面帮助自己的下属，于是凡事都倾力亲为。因此这类主管往往工作得非常辛苦，我上 面提到的那个VP就是一个工作狂热，几乎每天工作到晚上12点，第二天战斗力还同样超强，这一点还是让人很是佩服的。

　　2：这种主管不大信任下属。

　　有一部分主管由于授权不够，或者授权后又觉得下属能力不够，总之不大相信下属上报的信息，于是经常越级管理。当听到下属说某个技术有难点，某个进 度因为某个原因要延期，这时他们从自己获得的信息来分析觉得下属说的话不大可信。我上面提到的那个VP，基本就属于这种类型，他经常当着他的下属的下属的 面教导他的下属说应该像他这样精细化管理。搞得最后他的这个下属就得太伤面子，直接辞职了。

　　3：这种主管缺乏信息通道。

　　相对于前面两种情况而言，研发主管缺乏良好的信息获取渠道是个较为普遍的现象。很多主管在研发管理过程中都有如此感慨：不是不想放手，而是放不了 手!我在接触一些研发主管的过程中，经常听到如下声音：

　　."当下属说某个任务没有人力安排时，那么他至少要告诉我目前人力都安排到哪些地方去了吧!"

　　."当下属告诉我说某个任务需要延期到某个时间时，他至少要给我个延期的理由吧，而且不应该在最后一刻才告诉我要延期吧?"

　　缺乏信息获得的通道和手段，研发主管们的方法恐怕也只能是过一段时间就把下属拉到办公室开会，过一段时间就开始清理人力!这种做法的另一个改进方 法是：让自己的下属逐级写报告。员工写员工工作日报，项目经理写项目周报，质量经理写质量报告，产品经理写产品报告。但即使有大量的报告存在，在很多情况 下同样没能解决问题，因为大多研发经理们看到的这些报告，总觉得不是他期望看到的。这些报告要么过于形式而言之无物，要么胡乱记录而缺乏重点。各个基层管 理者大多又不愿意将时间耗费到这些报告上，尤其是对于开发任务紧张的项目经理更是如此，面对这种情况，研发经理们也没啥好办法。

　　来听听研发经理们最想得到的信息有哪些?我在此大致罗列一下：

　　1：我想知道我的员工现在都投入到哪些地方去了?这些人力投入是否合理?

　　2：我想知道我的员工现在都在忙些什么?他们是不是都忙到点上了?

　　3：我想知道我的员工现在的工作效率如何?他们是否一直保持着一个较高效率?

　　4：我想知道我的团队开发出的产品的目前的质量状况如何?产品缺陷正在被放大还是处于一个收敛期?

　　5：我想知道我的几个团队哪个团队做得更优秀?评价一个团队，我希望能够看到团队的整体数据，从进度，到质量，到知识积累等方面的绩效都要能够有 整体了解。

　　6：我想知道我的团队里面哪个成员做得最出色，我想让其它成员看到为何这个成员是最出色的，对他的出色的认定是建立在完善的事实数据统计基础上 的。

　　...

　　再仔细分析一下上面的这些研发经理们“想知道”的信息，有下面几个特点：

　　1：实时性。即现在这一刻我的团队情况如何?不是1周后告诉我现在的情况如何?更不是1个月甚至几个月后才能够得知现在的情况如何?我关心的是现 在的情况如何?项目经理肯定不喜欢一个3天前就开发人员就应该完成的任务过了1周都还没消息，研发经理肯定不喜欢到产品预定发布日前1周才知道发布还需要 推迟几周!

　　2: 统计性。有时告诉研发经理们过多细节也是不合适的，一般来说研发经理们更希望知道整体状况。即使去了解大量细节，也是因为目前的细节让他无法获得一个整体 上的控制。一般情况下无需告诉他每个人现在都在干什么，他要知道的是现在你的这个项目组，这个产品组的人的整体人力投入情况，比如为实现某个版本或需求投 入了多少人力?这些人力何时能够得到释放?

　　3：准确性。告诉研发经理们的任何信息都应该基于研发过程的事实数据，而不是没有任何数据支撑的胡编乱造一番，或者是是误差大得离谱的所谓度量数 据。当然，不要为了这些准确数据而让项目经理或QA拿个本本在研发人员身边做记录，为得到准确数据而耗费大量人力就是得不偿失了。

　　4：全面性。不要只是告诉你的上司你的团队开发了多少任务，他还需要知道开发这些任务投入了多少人力，这些任务有多少是延期的，这些任务产出了多 少成果(代码和文档);当然还别忘了告诉他现在您们团队质量状况，有多少缺陷等待处理，与其它团队相比，是否你们团队更加要注重质量问题?客户源源不断的 需求有多少正被实现，在这些需求上已经投入了多少人力，预计还需要投入多少人力?