大局之困睿思成靖爽.pdfVIP

大局之困 睿思成靖爽 目前网上流传着一个小故事，据说是微软EPG leader 发给所有员工的，且不 论是否确有其事（微软没有实施 CMMI ，不知道他们的过程定义团队是否叫 EPG ），听起来饶有兴趣并且颇需思量： 有一群小朋友在外面玩，而那个地方有两条铁轨，一条还在使用，一条已经 停用。只有一个小朋友选择在停用的铁轨上玩，其它的小朋友全都在仍然使用的 铁轨上玩，很不巧，火车来了(而且理所当然的往上面有很多小孩的、仍在使用的 铁轨上行驶）。而你正站在铁轨的切换器旁，因此你能让火车转往停用的铁轨，这 样的话你就可以救了大多数的小朋友; 但是那名在停用铁轨上的小朋友将被牺牲。 你会怎么办？（据说大多数人会选择多救一些的人,换句话说，牺牲那名在停用铁 轨上玩的小孩...） 问题是那一名选择停用铁轨的小孩显然是做出正确决定——脱离了他的朋友而 选择了安全的地方，而他的朋友们则是无知或任性的选择在不该玩耍的地方玩，为 什么做出正确抉择的人要为了大多数人的无知而牺牲呢？ 另外，一条铁道会被停止使用，自由它的道理。是否代表着这个铁道本身有问 题，未经验证就使用它会遇到潜藏的危机呢？如果切过去之后，被牺牲的就不只是 一个或一群小孩了，而是整车的乘客呢？ 我们从小被教育为“顾全大局”，然而什么是大局？您是否期望在“大局”面 前成为“规范”的牺牲品？ 当然每个读者对这个故事的看法和角度就像看万花筒一样不同，我不想从伦理 和逻辑的角度来分析，只是对号入座到研发管理的过程中： 1、某公司进行软件产品开发，进度非常紧张，项目经理尽其所能裁剪掉了 第 1 页共 4 页 睿思成研发管理咨询 国内首家集成IPD 咨询和西门子PLM 实施的专业服务机构 “不必要”的活动，例如项目估计、详细设计、评审检视、甚至研发内部 的系统测试——结果是“及时”交付了一个版本，并且要求测试团队提高 效率，不要“吹毛求疵”，影响产品按时提交客户； 2 、某公司在洽谈一个项目时，并没有进行认真的商务和技术方面的评估，就 连该项目涉及的业务领域也是一知半解，面对客户提出的要求一律接受， 甚至答应了竞争对手无法超越的低价和交付周期——他们认为签下合同是 最重要的，其他的矛盾都会得到解决； 3、在进行考评的时候，由于竞争对手已经对某员工伸出了橄榄枝，并且该员 工也表现的心猿意马，鉴于这种情况直接主管决定提高其考评结果以进行 挽留，使得其考评结果与工作情况反差较大； 4 、某公司已经建立了比较完整的产品研发管理制度和流程，也要求研发项目 需要遵循规范。但是产品质量仍然参差不齐，有的产品发布后非常稳定， 相安无事；有的产品却 bug 很多，四处起火，开发人员到处救火，公司还 特意嘉奖了他们的努力工作。 我们发现上述研发管理的案例中几乎都出现了目的和行动不符合的问题，这 种错位往往来自于“不由自主”，就像几乎每个项目经理都认同项目成功需要完善 的项目计划和不断的控制修正，而实际上能称得上有计划并得到遵循的却很罕见。 笔者认为问题的症结首先在于研发经理/决策者是否真的具有明确目的并且充 分认同之。这个或者叫做大局，还记得前面那个切换铁轨的故事吧，决策者的目的 是什么？拯救在险境中的孩子们、拯救更多的孩子、拯救更多的人、强调规范、还 是其他的什么。如果明确了目的，决策时就会减少很多瞻前顾后的压力。 例如软件企业在实施 CMMI 咨询过程时，都会具有过程改进和过级的目的— —这与 CMM/CMMI 的初衷一致，评价企业过程能力成熟度以及作为过程改进的模 型，而在实施遇到困难的时候，其真实的意图就显现出来——唯一关注的就是主任 评估师的“明星签名”，姑且不论过程是否可以被改进，连定义出的过程是否机械 的符合 CMMI 的要求都不再重要了。况且成熟规范的过程等同于优质产品的观点 值得商榷，该公司在“过程改进” 过程中出现与商业目标发生冲突时，“铁轨的切 第 2 页共 4 页