风险是什么？风险就是不确定性，而项目管理的过程就是不断的消除风险的过程，没有风险的项目一定应该是成功的，如果失败都说明前期没有充分的失败和应对风险。风险和风险管理都谈得比较多，但是其重点往往并不在于系统化的风险管理方法和流程，而在于风险意识的形成和转变。风险意识和危机意识是项目管理最核心的一个思维意识。对于风险管理可以再谈下其重点的核心如下：

* 风险管理是项目目标驱动的，这样的风险管理才有意义。
* 达成项目的目标究竟还存在管理，技术，支持等各个方面的哪些不确定性？这个不确定性如果不解决对目标影响是否可以接受。
* 做计划是对项目目标和结果进行预测，但是预测无法100%准确，风险管理目的就是应对计划本身的不确定性。
* 风险管理的难点在于通过历史经验积累，识别项目的关键风险，只有识别出来才谈得上应对。
* 项目应该预留合适的时间和资金的缓冲，但是缓冲太大确实灾难，它可能让我们忽视了风险本身，因为即使风险已经转化为了问题也没有影响到最后目标的达成。

风险意识重点就是在项目启动前或项目执行过程中都随时有意识的去识别项目的关键风险，只有先把风险识别出来，才谈得上如何去分析和量化，如何去应对。

首先我们应该看到的是从自己的失败中总结前车之鉴，历史的项目为什么失败了？为什么项目目标偏离了？要去分析这些问题的根源，要去考虑如果再接新的项目的时候如何去预防，如何避免问题再次发生。挂在嘴边的不仅仅是风险两个字，而是风险应对措施的真正落地，你需要去考虑哪些事情需要提前预防和提前介入，哪些事情需要制定备选方案，哪些围绕项目团队和环境的事情提前展开，这些工作都必须要做，都是为了降低和消除不确定性。有时候你做了这些事情后，风险没有转变为问题，大家可能看不到这些风险应对措施的价值，但是你仍然必须要去做。有时候可能往往成功救火的人反而得到了表扬，但是这些都不应该影响到你的思维和应对。

其次，从组织的失败中找寻经验。这也是我们说的组织级的风险库，别的团队和项目出现了问题，那么你自己的项目或团队就有可能出现问题，你可以去看他人的经验教训总结，看组织多年积累的风险库来审视自己的团队是否会发生类似的问题，这是一个组织成熟的重要体现。同时你也必须意识到你原来没有发生类似问题并不代表你将来不会发生类似问题。通过组织级的风险库和风险检查单，你就可以从团队，项目，环境，技术，支持过程，客户等多个方向去寻找可能存在的不确定性。

前面两点可以看到都是从自己和组织的历史中去找寻经验，比对现在项目可能存在的风险和不确定性。那么最后一点就是从当前的完整的项目计划中去找寻风险和不确定性。项目的进度是否能够达成？项目的质量和成本如何保证不出现偏差或偏差可控？项目的进度可以通过WBS分解到细化的活动和任务，项目的成本也可以通过预算逐层分解，而这个分解对应的往往正是一个项目的风险树，你需要考虑的就是风险树上的每一个节点在保证质量的前提下成本和进度都是可控的。(注:这里还要提到风险管理不仅仅是项目经理的事情，需要把风险意识下达到整个团队，每个团队成员都应该做这样的思考，如我这周的任务是否有100%把握完成，存在哪些不确定性？如果不能完成我应该这么办？)

原文http://blog.sina.com.cn/s/blog_493a84550100eqea.html

版权声明：可以任意转载，但转载时必须标明原作者charlee、原始链接http://tech.idv2.com/2008/06/05/pm-and-tech-leader/以及本声明。

本文是日经BP上的一篇关于项目管理方法的实践的文章。对于短期的Web小型项目， 无论是开发周期、成本，还是技术上都有很大的风险。然而许多人对此认识不足， 导致项目失败，或是产品发布日期一拖再拖、成本大幅上升，或是匆忙发布后漏洞百出。 本文从项目管理的角度说明，即使在小型项目中，项目经理也不能将项目全权委托给技术主管， 而应当建立合适的体制，从几个方面对项目进行控制，这样才能保证项目的顺利进行。

原文在这里。

通常的项目体制不适合短期开发

在大型机上花费几年的时间构建大型系统时，项目经理通常仅负责一个项目， 手下也聚集着许多软件工程师。在需求定义阶段，项目经理直接与客户进行交涉， 在需求定义中发挥着领导的作用。

这种体制本来十分理想，但对于开发期间只有几周到几个月的小型Web系统来说， 却不尽人意。团队的实际情况是，项目经理和技术主管通常会兼任数个项目， 设计、编码的工作全部交给年轻的工程师或合作方的工程师们。 这时，项目经理的一部分职责通常会交给技术主管分担。

职责、分工不明确

开发Web系统时，客户企业经常会要求使用EJB、XML、Web Service等较新的技术。 项目经理为了满足客户企业在技术上的要求，不得不依赖于技术主管。 另外，项目经理通常要照看多个项目，因此与之相比，技术主管接触客户的机会更多一些。

这样，在Web开发中技术主管的职责范围变得非常广泛。因此，项目经理和技术主管的 职责分工很容易变得模糊不清。绝大多数情况下，职责分工问题不仅没能形成书面文档， 甚至连简单的协议都做不到。极端的例子就是“除了钱的问题，其他全部委托给技术主管”。

这种现象并不鲜见，但是在大规模项目中，通常会有足够多的时间和人力来规避风险， 因此即使发生问题，也总有办法解决掉。但是小规模、短期的Web项目中，由于职责分工不明确 而导致项目内部的意见不一、决策效率低下等，是项目失败的直接原因。

项目经理无法掌握项目的状况

让我们具体地看一看，在项目最重要的任务之一——需求定义中，职责分工不明确会造成怎样的问题。

在Web系统开发中，客户企业经常会在开发途中增加、改变需求，因此完整的需求在项目初期很难确定。 再加上项目经理要兼任多个项目，无暇顾及每个项目的需求定义，只得将其全权委托给技术主管。

这种条件下，技术主管仅从技术的观点来接受客户的要求，导致项目超过预算、超过预定工期的可能性非常大。 另外，项目经理无法详细把握需求定义，因此无法把握项目的状况，导致项目的范围失控。 最终结果必然是，当问题的征兆出现时，根本无法采取任何对策，如与客户交涉“先实现优先的功能，其他无关紧要的功能下次再实现”等。

想象一下，技术主管完全根据自己的判断来回答客户企业的重要问题时会出现什么后果。 项目经理和技术主管的意见一致时尚可，意见不一致时，必然会招致客户的混乱。 此外，项目经理对技术主管过于依赖，会导致不好的结果。例如，带着“他会做好的”、 “这件事儿是他的责任”的想法，通过邮件给技术主管分配任务，其结果通常是该做的事情 没人负责。

建立职责分工的规则

为避免这样的问题，项目经理和技术主管必须事先决定职责分工。那么应当如何分工呢？ 不同的项目千差万别，所以并不存在万能的灵药。应当综合各种方法，并结合项目的实际来决定。 以此为前提，首先应当制定职责分工的规则。具体来说，要制定以下的规则。

(1) 在需求定义结束之前，实现哪些功能、采用什么开发工具、安全实现到什么程度、 如何应对繁忙时的业务量等，这些关系到系统需求的重要事项必须由项目经理和技术主管协商决定。

(2) 在设计阶段之后，不影响进度、人员计划的功能追加、修改等项目范围内的事项， 首先由技术主管做出判断，交由项目经理确认之后再做决定。可能会导致合同变动的项目范围外的事项， 技术主管应当将判断权交给项目经理。用这种规则，就能回避职责不明确导致的混乱。

共同制作业务场景

同时，也应当建立项目经理和技术主管共享信息的方法。这里，我们以需求定义阶段 项目经理和技术主管合作制作“业务场景”的方法为例进行介绍。

新业务的场景，即根据客户询问、头脑风暴、JAD、原型、现有业务资料调查等方式获得的信息， 来描述新系统的样子的东西。

业务场景可以用讲故事的方式写成，附以图表就更完美了。也可以开发一套能实际运行的原型系统。 制作业务场景的过程中要不断与客户确认，以此为基础来确定详细的系统需求。

场景制作的材料可以完全委托给团队成员，但场景本身必须由项目经理和技术主管协同客户方负责人一起制作。 项目经理和技术主管经过不断的交涉，提炼材料，从开发的角度看哪些重要，现行系统的哪一部分在新系统中如何变化等， 这些问题项目经理和技术主管都要充分认识。这样，两者才能获得一致的意见。

技术主管通过制作业务场景来获得与项目经理一致的意见，在确定需求时才能更容易地获得客户的新人。 另一方面，项目经理也有充分的自信能够“完美地控制项目”。当然，场景的详细程度需按照项目来定。

项目经理也要有技术直觉

即使明确了职责分工，也不能说是十全十美。Web开发项目要想成功，项目经理也要拥有 “技术者的直觉”。认为“最近的技术全然不懂，干脆都交给技术主管吧”的话， 就无法进行风险管理了。

Web系统开发经常使用大量的新技术、新产品，技术方面的风险十分大。例如，不经深刻的讨论 就采用螺旋形方法进行开发，很容易陷入需求膨胀、不知何时才能最终完工的黑洞。 此外，面向最终用户的B2C的电子商务网站，若不在认真计划的基础上进行有效率的测试， 就会有测试量剧增的风险。

为防止这些风险，项目经理必须拥有“技术直觉”，努力管理项目，在技术问题上与技术主管充分交流， 而不能完全委托给技术主管。

所谓技术直觉，并不是要求精通技术本身。重要的是要了解技术的“意义”， 对于技术给项目带来的影响具有敏锐的洞察力。遗憾的是，有些项目经理抱有 “发生问题时，只要增加人手就能解决”这种简单的想法，但它正是没有技术直觉 造成的最为悲剧性的看法。

对于影响到项目进程的技术瓶颈，就算是增加人手也只是徒然浪费金钱而已。

项目经理要求有“技术直觉”，同样，技术主管也要有“项目管理直觉”。 特别是经常接触客户的技术主管，如果没有项目范围、进度、成本、质量管理这些 项目管理的基本知识，就容易仅凭技术来接受客户要求，不知不觉中就会使 成本和进度失控。项目经理和技术主管应当了解的知识如下所示。

• 项目管理技能(参考PMBOK)
  • 综合管理
  • 范围管理
  • 时间管理
  • 费用管理
  • 质量管理
  • 人力资源管理
  • 沟通管理
  • 风险管理
  • 资源调配管理
  • 领导力
  • 交涉力
  • 问题解决能力
• 软件技术技能
  • 需求定义
  • 系统设计
  • 编码、测试
  • 性能计划
  • 容量计划
  • 配置管理
  • 变更管理
  • 问题管理
  • 过程管理
  • 开发手段
  • 开发工具
  • 质量管理
• 共通技能
  • 一般的IT知识、业务知识

在中国做管理

我在美国做过管理，在中国也做过管理，我发现管理中国的员工是很难的，因为价值观不同。在美国更多的是宣扬一种商业价值观，管理者和员工间的 关系，是一种业务关系；在中国，人们追求更多的是一种人性。中国的企业缺乏一套规范化的管理体系，它们需要规范和平台，不过目前很多在中国的企业还很难做 到这点。

我曾提出“4＋1”的核心竞争力说法，其中的“4”包括：品牌、技术、市场和资本，而关键的“1”即“公司管理”。如果一个公司缺乏良好的管 理团队，那么它就无法把前面的4个因素转变成企业最终的核心竞争力。以资本为例，很多的中国企业不知道上市的目的，于是它们圈完钱就走。上市实际是为了获 得一个平台，为了公司的持续发展不断融资。对企业而言，上市是开始并非终极目标。中国有些公司在上市几年后，公司的账务处于瘫痪的状态，就是目标未理清。 我曾说过：目前中国最顶尖的100家民营企业，过几年只会剩下20家，被淘汰者一定是毁在管理上。

中国式个性化

管理是一件很复杂的事情。中国式的管理与西方的管理是不同的。规范是中国企业今天面临的最大问题，中国企业的管理太个性化；但是在中国做管 理，光有基本的管理理念是不够的，也需要一些个性化，这缘于中国文化。中国人最怕的是被感动，如果你感动了他，那么他会为你赴汤蹈火，这是中国人的性格。

在美国做管理，你不需要感动员工，只要按合同支付报酬就行；而在中国，人们追求的更多不仅是金钱，还有感觉。因此企业的领导人需要提供这种感觉给员工——让他觉得他在公司里是很重要的。

我任微软中国公司总裁时，有一个不成文规定——任何到微软工作的人，都需要经过我的面试。当时很多人不太理解，认为CEO这么做有浪费时间之 嫌。事实上，我的用意是：通过面试，让所有进微软的员工感受到公司对其的重视。有一次，我在美国开会，而国内有一个岗位急需招人，因此有位员工“逃过”我 的面试直接进入微软。在接下来的试用期，他表现得很出色。不过几个月过后，他来找我，让我再面试他一次。原因是：在平时，员工间互相调侃时，大伙喜欢拿他 开玩笑，因为他没经过我的面试，是溜进来，类似“非正式军”。我对他说：他已经表现得很称职，不需要面试，不过他很坚持。最后我满足了他的愿望，面试让他 从心理上感觉自己是个纯粹的微软人。

在中国有一个很重要的节日是中秋节。大多数中国公司在这天会给员工买月饼，这时它们往往会面临一个尴尬的境地：只发月饼，员工会认为没创意； 不发月饼，员工会抱怨公司不人道。那么公司到底该不该发月饼？应该发！因为至少员工不会抱怨！关键是公司要考虑到底要怎么来发月饼。当时微软做了一件事 情：我们让员工提供两个地址——他们希望月饼能够送到的地址，而后公司帮他们将月饼送达目的地。同时，公司会在这些月饼中附一张小卡，卡片上有两段文字， 第一段文字是表达感恩之情；第二段文字是描述我们的公司，主要表达的是：“我们的公司是世界上最优秀的公司，特别是我们所在的分公司又是微软全球分公司中 最好的，世界上最优秀的员工在我们的公司，我们很自豪，所以我们也希望：作为我们员工的朋友或家人的你也会觉得很自豪！”

事实证明，这种做法是有效的。许多员工提供诸如父母、过去的同窗、老师，甚至同事的地址。很多父母接到这卡片后，很自豪，甚至还将卡片裱装起 来，而后告诉他们的亲朋好友，他们的孩子是在世界上最优秀的公司；同时他们还会给他们的孩子打电话，让他们珍惜在微软的机会。这是善于运用各种资源的效 果。

在任微软中国总裁期间，我大约面试了2500多人，都快成“人精”了，后来差点发展成惯性动作：看见一个人，我就有面试的冲动。如果有人在我 面前呆上约2分钟，我就能作出判断：他适合哪类工作。不过一般在面试的时候，我给对方10分钟，而事实上我在2－3分钟内已可以做出结论，剩下的时间完全 是“以人为本”的体现，毕竟要尊重被面试者。最后我把面试经验总结成三道问题，如果被面试者答对一道问题，那么他可以得到一份工作；答对两道，他的工资比 别人高100％，答对三道问题，他可以自己开工资，面试者是可以动用一切资源来回答。大多数公司在面试时，要挖掘的是被面试者的观察力、分析问题的能力、 与人沟通的能力和资源整合能力，我也一样。

让他人变得伟大

企业文化的根本核心是什么？它的终极目标是什么？那是要让公司的每个员工都热爱这家企业。前几天我看到新浪上的一个调查报道，觉得有些悲哀。 只有16％的人发自内心的喜欢自己的企业，72％的人是非常不喜欢自己的公司。76％的人表达正等着某天离开所在公司。以这个调查为参照的话，那么我们必 须要考虑中国企业的向心力在哪？中国企业的后续发展动力在哪？问题出在哪？有人说是机制问题，例如国有企业的机制不那么灵活。我不赞同，机制是人创造出来 的，更重要的是企业文化。

要是从字面上看，几乎所有公司的企业文化差不多都集中到几个字眼——以人为本、科技创新、勤奋、诚信等。但事实上，中国的大多数公司在培养企业文化时有些表面，主要体现在标语上。

我从微软上海调到微软北京工作时，北京分公司的氛围不是很好，这主要是以上海分公司为参照。当时上海分公司的员工满意度在微软内部是很高的， 而北京分公司的员工满意度则很低。我到了北京后，做的第一件事情是召集所有的秘书开会！为什么呢？因为秘书在一个公司内扮演很重要的角色，他们往往是公司 内部信息的集大成者和高效的传播者。在会上，我所传达的一个信息是：秘书是很重要的，我需要依靠他们。并说明我接下来需要做的事情要他们的协助。很自然 地，我获得他们的认同和忠诚。同时，会后我的这些想法也很快地传达到公司高管，秘书在这方面的传播效率确实很高。

外企内部最大的问题是：企业内部采取的是淘汰制，因此员工和员工内部是一种竞争的关系，团队合作关系成了一个难题。从理论上，这似乎是无法解决的循环。

我的一个尝试是在内部灌输一种理念——“让他人变得伟大”。理念提出后，我需要制定一些手段，让理念得以强化。首先，由所有员工选出20个“ 公司最优秀员工”，这个方法的作用是：人们往往倾向于选择那些帮助过自己的人，因此选出来的员工，在帮助其他员工方面一定做得不错；其次，我宣布：未被评 为“优秀员工”的人，将无法享有各类晋升机会。这一步骤的作用是：让那些最初对评选“优秀员工”无所谓的人，有了想获奖的冲动。这样实行了一年后，在接下 来的员工满意度调查中，北京公司的排名从原来的亚洲倒数第二位，上升到全球销售公司中满意度最高的公司。不过，总部对分公司的考察，考虑得更多的是硬指 标，也就是业绩问题。那年北京公司的业绩也是得到大幅增长，这表明，这些做法是有效的。

（ 推荐《创业的核心方法经验》这本集子。请参见“创业与经营”小组的相关链接：http://www.douban.com/group/148169/ （本文不在其中））