项目开发主管费先生：如何让项目经理觉得项目实施过程是有效的？并且如何提高效率？

【解答】睿泰咨询一部经理 资深咨询师 杨俊（新浪微博名：睿泰杨俊）

非常感谢您的提问*，即使我的回答不能给您一个满意的答案，也希望那是开启一扇房门的钥匙。

首先，我觉得十分有必要澄清三个基本事实：

只有在明确了上述三个基本点后，我们才能讨论后续的问题，因为它将决定谁应该倾听下述内容。

作为一种工具的“工作与过程”

诚然，再也没有比下述事实更加显而易见的了：

“成果”必须通过一系列的“工作”才能得以实现；

必须理清一系列“工作”之间的关系，使之形成合理的“过程”，才能让“工作”从整体上变得富有效率。

也许，正因其过于显而易见，所以大多数企业经营者（无论是企业高层还是中层）都坚决相信应该拥有一种更好的工作、过程与方法，但是一旦转入实践，对工作与过程的改进（革）就变成了一线专业团队的自娱自乐了。

我们对于工作的理解还停留在30年前，上世纪80 – 90年代，我们的绝大多数工作都是体力工作，体力工作者从来都不需要问自己工作的目的是什么。如果你是一个装配工，你的工作就是将流水线上滚下来的各种部件进行组装，“装配工”这个名词就能看出一个工作者本身的工作内容。同样，电焊工、运输工、装卸工等等，皆是如此。

显然，对于体力工作而言，工作本身即是工作目的。所以在诸如ISO之类的标准化框架内，工作过程的研究与标准化直接决定了工作的效果和效率，而工人们（雇员），只需要忠实的重复执行管理者或顾问已经发现并定义的最佳实践即可。

但是，这肯定不是IT工作和IT工作者的现实情况，事实上它不符合绝大多数专业性极强的服务性工作的客观现实。因为，对于专业服务工作而言，工作与过程都只是‘术’，而不是‘本’。如果观察一个作家的工作过程，我们不难发现“文字编辑”是占据其主要时间的工作项，但是我们不会说一个作家就是一个码字的人；同样的，一个软件工程师的主要工作当然是“编码”，但是编码也只是一种手段，用以完成一个“IT系统”，研发工作显然不是一种体力工作。我们会说装配工就是用来组装零部件的，但是我们不会说IT工程师就是用来编写代码的，我们会说我们期望他们解决客户问题。这样的情况还包括，测试工程师、项目经理、需求工程师、架构师以及实施工程师。

这意味着，越是希望工作及过程有效，就越是需要团队深刻理解自己的工作目的、目标与成果。理解清楚自己工作的目的与目标未必能够找到合适的工作及过程方法，但是如果不明确工作的目的与目标，那么我们肯定不能找到合适的工作及过程方法，因为我们都无法评判其适用性。

反之，这也意味着，不以提升最终效果与效率为主旨的工作与过程设置（调整），都是耍流氓。

为什么设置的工作与过程总是缺乏效果与效率？

我们始终觉得研发团队排斥“工作与过程”，但这只是问题的表征，就如之前我们提到的，每一个团队事实上都有自己的工作及过程；同样的，绝大多数团队成员私底下都会抱怨工作及流程的不合理性。

真正的问题在于对于工作及过程的设置始终是缺乏效果与效率的。每个中层管理者与一线专业团队都对此深知肚明，每一个高喊要求提高效率的总经理或副总经理也总是在实际的工作及过程设置时就忘记了参照自己的效果或效率目标。

总结，长期以来始终使得工作与过程缺乏效果与效率的主要原因有如下几个：

A．（已经在上文中提及）缺乏对工作目的、目标与成果的有效理解与定义，无法达成共识。

长期以来，测试团队一直处于非议的漩涡中。一方面，人们始终都觉得有必要形成一个专业的测试团队来帮助研发团队处理日益失控的产品质量问题；另一方面，通过实践，人们又觉得测试团队对质量的控制并无多大帮助，研发团队与测试团队之间的对立情绪也愈演愈烈。

问题就出在绝大多数测试团队没有理解自己的工作使命与目标上，测试团队并不是进行测试工作的人（虽然他们的主要工作内容就是“测试”），至少每一个批复预算成立测试团队的高层经理人并不是这么理解的，他们的理解是 —— “控制质量”。

一旦团队明确了工作目的（使命），团队至少可以说：“就这个目标，我们无能为力”。但是，另一方面，聪明的测试团队负责人意识到只要稍微改变一些自己的工作内容及流程，就至少可以切实帮助研发团队提升系统质量。这些内容包括：

任何一个不再把自己当成是“缺陷报警器”的测试团队，都会至少立刻缓解与研发团队的紧张关系，从而帮助团队切实有效的提升产品质量。

B．相信有唯一正确的工作及过程

一直以来，我们都在寻找一种灵丹妙药，虽然“软件没有银弹”这句话早已成了口头禅，但是我们开口闭口就是“先进的过程与管理方法”，这只能突出行业的无助。

无论是过去的瀑布型工作流程，还是当下火热的敏捷与迭代，都仅仅是完成工作的手段而已。每一种方法都有自己的适用范围和使用准则，压根不存在某种工作及过程方法比另一种更为先进，但是确有更为适用的说法。

关于软件工程或研发过程的方法论及书籍早已是汗牛充栋，无需在此赘言。但是每一种方法论背后都是声称自己是解决一切问题的灵丹妙药，企业的管理者并不了解适用性问题，所以也只能抱着尝试的心理前进；而尝百毒的人，恰是企业一线工作者。一线工作者的为难情绪是显而易见和可以理解的。

我们至少知道这样一点，越是能够理解一样武器的缺点就越是能够发挥它的优点，管理团队（尤其包括一线开发团队）的当务之急是理解每一种研发方法论背后的环境以及待解决的问题，同时要理解它们分别的优势、劣势和适用准则，这样才能使得研发团队选择合适的工作过程与方法。

不得不说，有时候，糟糕的方法比没有方法更糟糕。

C. 没有依照最终结果重新组织工作及流程

我们太习惯于‘做’，而不是为什么‘做’。CMMI本身并没有什么错误，但是CMMI引起人们最大的误解的地方（也正是它自己造成的这种误会）就是——文档太多。于是，我们说CMMI是一种‘重’的过程，并且加以排斥。

但是，排斥的原因却是可以理解的，比如任何一个管理者都会要求团队编写周报，可是编写周报的目的是什么呢？是使得所有利益相关者能够理解项目当前状态、可能的风险与各自需要互相配合协调的地方。就拿风险举例，我们以为自己的每份周报都详细的描述了这些内容，但是当我们问“上一次处理的周报中的风险是哪一项？”时，我们得到的答案多半是 —— “没有”。

结果我们把对风险（以及其他内容）的记录理解成了风险控制的全部。记录只是其中的一步，我们还包括对风险进行理解、确定风险的优先等级、思考和决策可能的解决方案等等，而这些多半都没有下文。

更关键的是，如果我们从最终的结果 —— 防止严重问题的发生 —— 去重新理解“风险控制”的工作及过程，我们就会发现工作及过程的组织是非常不合理的。比如，至少有一半左右的风险根本不值得去跟踪和维护，多半不会发生或发生了也可以以比较小的代价处理，这些风险要么不会转化成问题，要么就是转化成并不太严重的问题（而我们的最终目的是要提前阻止严重问题的发生）。同样的，那些在短期之内确实无法解决的结构性问题，如“人员缺乏”，是迫不得已必然发生的，也就没有必要去跟踪了。

结果由于我们把精力平均分配到了所有风险与问题上，导致我们什么风险都控制不住。

D．没有建立方向与质量的标准

有效的工作及过程是一种结果，并且这种结果充满不确定性。我们自然是习惯在确定性的环境下提前制定“规格”，但是如果一件工作的成果只能被预期，而不能被确定，那该怎么办呢？　

迄今为止，我们还缺乏在不确定性的环境下制定目标、提供计划与执行监控的手段与方法。但是也并非完全没有可以参照的方向。

律师是一种十分不确定性的工作，不确定性包括委托人到底要达到什么目的？每一个人所说的话是否是真实的？如果环境对自己不利应该如何采取行动？律师采取的策略就是：

这和指挥作战也十分类似。我们不能因为不知道或不确定就放弃提出目标，目标是一种对方向的假设，我们要做的是理解我们提出的仅仅是一种假设，所以我们必须不断的在过程中寻找证据证明我们的假设，而不是自欺欺人。

一位律师或者一位出色的将军始终把握的就是官司或战场的方向感，而不是具体的内容。面对不确定性，我们并不是在寻找十全十美，我们是在寻找基本正确。同时，正是因为事先假设了目标，事后采集了证据，我们才能通过反馈获得调整的信息，否则我们的任何一次判断或决策都是无根的树，无源的水。

还远远不够

让IT研发的管理方法声名狼藉，狼狈不堪的原因并不仅仅是上述几点。不知道从什么时候起，我们总喜欢说“归根结底是人的问题”，虽然我们都喜欢那么说，但是真正理解这点的人几乎没有。

工作及过程是客观的，不具人格的，不会因为你是男人或女人，因为你是本科毕业还是博士毕业而变得有所不同。但是当工作及过程制定完成后，怎么去执行却是关于‘人’的问题，不同的人因为其行为、能力、价值观、期望的有所不同而变得极为不同。

一个刚刚毕业的孩子关心的是未来的前途，赚多少钱自然也是关心的，但并不是首要关心的内容。但是当这个孩子年过30成家立业后，他们关心的就是工作的稳定与家庭的协调了。这些都是显而易见的事实，但是最容易让人忽略。

不同的人，在面对相同的工作时所展开的行为方式是南辕北辙的，我们尚未考虑如何组织不同的团队成员以适应工作与过程（注意是适应，而不是压迫）。事实上，是相互适应的过程，工作及过程很有可能因为临时的团队配置而不得不做出适当的妥协（这是很有必要的）。同时，帮助团队适应整个工作及过程，并且明确最终结果则是高层团队自始至终的责任。

我们应该怎么做？

改进（革）研发工作与过程是谁的责任？我们之前就提到，完成项目目标是项目管理者的责任，所以改进（革）研发工作与过程自然也是项目管理者的重要责任。

但是，高层管理者不能仅仅提出要求，事实上想要做出改变，高层管理者就必须首先做出改变。

首先，高层管理者必须依据项目的不同目标与性质进行分类，通常公司一旦达到一定规模就必然存在多种目的性与性质的项目组群，如果用统一的政策要求不同目的的项目组，就会犯上述A类错误。

其次，多半管理者还能做到上述第一条，但是高层管理者就停留在了原地，高层管理者没有让中层经理人与一线的专业人士理解不同的项目及使命，并且达成一致。绝大多数高层管理者认为这是没有必要的，中层经理人或一线的团队只要完成工作就可以了，但是正如我们所说大多数人都不知道自己要完成的是什么工作。

第三，必须要有一个专职机构（如PMO或EPG，绝大多数人都可以是兼职形式）负责工作及过程的制定与完善，但是这个专职机构不能把自己当成是管理与控制机构，这样就会形成阻力，这个机构的绩效是真正帮助项目经理人有效制定和利用工作及过程来完成自己的项目目标。同时，这个团队还应该起到高层经理人与中层经理人之间的沟通桥梁的作用，这非常重要。一个衡量这个组织绩效的有效依据是其项目经理团队是否觉得获得了帮助，而不是收到了命令。

第四，在制定工作及过程的过程中，必须要让真正重要的专业人士参与，让专业人士和项目经理人做出决策，只有他们认为正确的决策才会具有执行力。但是，高层管理者至少不能双手一摊说，你们交货就可以了，高层管理者必须要能够指导（但不是决定内容）整个过程的进行，并且帮助中层经理人和专业人士处理那些繁琐的支持性杂活（如文档编写、PPT制作等）

第五，要提供反馈。没有什么东西是在开始时就正确的，对流程的改进与改革也是一种研发工作，所以也是在不确定性的环境下摸索着前进的，我们不能试图期望一次性正确。所以专职机构必须提供绩效的反馈，必须能够说明目前的做法对结果产生的影响，否则改进（革）就将陷入僵局。

第六，要提供试点。不要试图一次性铺张开，选择在某个项目或某个部分开始做小范围尝试，选择愿意和相信改进（革）能帮助他们更好参与整个过程，在没有极具说服力的证据之前不要尝试推广，否则只会遭受抵制。渐渐的团队就会说：“瞧瞧吧，之前我说什么来着？”，一旦养成了这样的氛围，再想改变就困难重重了。

总之，以上的建议只能涉及方向，而不是具体的行动，那是因为行动必须在具体环境下去分析与计划，但是方向却是可以较为明确的，希望以上内容能够帮助你开启思考，而不是提供现成的答案。