项目经理（Project Manager）的一些故事 （3）

很久以后，我才认识到一个好的项目经理要有很强的应付各种压力和尴尬处境的能力，要有一种很强的个性（strong personality）。项目经理的压力往往来自至少四个方面：客户、运营经理（Operations，大老板）、市场部、工程部。市场部为了争取客户，往往给出不切实际的承诺；工程部永远是人手不够（under resourced）；营运经理一到月底就数票子；客户永远在那儿抱怨。项目经理的一个主要工作是要平衡各个方面。可惜的是，斯哥特既没这方面的经验，也没一种天生的能力。

在项目的初始阶段，斯哥特与别人的矛盾以及他所造成的矛盾没有显露出来。这个LTE项目组里有许多编码高手，大家一起讨论如何代码、文档等的存储结构（repository），统一版本控制工具（CVS，ClearCase etc）、代码编写格式和约定。我以前在一个软件屋工作过，我在公司东欧的一个软件中心夫人帮助下，制定了整个产品软件的开发流程（process）、规范和文档样本。当这些都搞定后，问题就来了。

斯哥特的第一个任务就是给要开发的每一个模块估算工作量。现在回头看来，这本不应该是他这种项目协调人式项目经理的任务。他去一个一个人地谈。从开发工程师的角度看，为了保证软件的质量，总是希望多要一些时间。另外，谁不想让自己的工作压力小一些？这样，当斯哥特把所有的单个时间与任务相关性输入MS Project后，工程交付日期根本无法满足用户的要求。

为了解决这一问题，斯哥特只要再去一个一个地劝说。有的工程师当然是愿意做一些调整，但有的由于种种原因，比较难以减少到斯哥特期望的工作量。双方一争执，有的说话就说得比较难听，像，“你要认为在这个时间段内能完成，你做就是了。”这种话斯哥特受不了，就去马克那儿告状。马克就各打五十大板。我有一次听到马克在训斥斯哥特，大意是“我（马克）要管理整个部门，你就这点微观管理（micro-management）的事也要找我？”斯哥特就一直处在这种压力下。

为了“更客观”地估计工作量，他想出了一个现在看来是很荒唐的办法，即让两个工程师来独立地估计工作量。他有一次要印度来的无线工程师苏班卡做RLC（Radio Link Control / 无线链路控制）中的一个模块，苏班卡估计要一个礼拜。他不喜欢这个估计，就去问网络工程师肯尼相同的问题，肯尼说最多两天。然后再转回来问苏班卡为什么你们两人的估计相差那么大？弄得苏班卡与肯尼也不和。这样的事做了几次，也就再也没人愿意对不是自己的任务发表评论了。但同事之间由于斯哥特而产生了许多不必要的矛盾，这些矛盾一直到这个组解散都没解决。

工作量估算只是许多事里的一个。其它一些事，如有的同事在使用一个公司专用的版本控制系统（不是流行的CVS或ClearCase）时，由于生疏而造成在模块整合时的错误，他害怕影响项目进度，就会抱怨说这是一个不应该的错误之类的话。有人会指出这应该作在计划里，但斯哥特总是无休止地与人争辩，最后弄得不欢而散。类似这样的事在斯哥特那儿发生过多次。

公平地说，斯哥特是个很努力的人。为了把工作做好，自学MS Project，考PRINCE2等。白天找人谈事、应付客户，后半下午再开始更新计划，经常很晚才下班。组里因为气氛不好，很多工程师们就早九晚五。工期拖了就让管理部门，即马克和蒂姆，去对付。

为此我曾经与马克和蒂姆都谈过。马克好像也没什么办法，只好自己去与有关人员谈，有时鼓励一下，有时就直接质问工作表现。我记得与蒂姆谈得时候，他是有意在下一个项目中换掉斯哥特。如果在项目中间换，一个闲人就多出来了。为了消除或减轻部门里同事之间的紧张气氛，蒂姆还想法弄来经费，让整个部门去苏格兰高地做团队建设（team-building）。

项目就这么吵吵闹闹地进行着，我们赢来的一个LTE客户也就成了最后一个客户。这个充满希望的LTE项目或来成了一个“死亡之旅（death march）”项目有许多原因，项目管理只是其中之一。我离开“高科技先锋”去了“百年老店”后，才慢慢悟出整个事情错在那儿。

项目经理（Project Manager）的一些故事 （4）