项目实战笔记之一：高效会议的组织方法

关于开会大家应该都不陌生，而且应该有不少人被过度频繁的会议“伤过”，甚至”谈会色变“ 。当一个组织的人员较多，结构复杂时这个问题会更加突出。如果开发人员/测试人员参加会议过多，会导致工作打断严重，直接影响到团队工作效率。如果管理人员参加会议过多，就会导致管理人员离开所负责的管辖范围时间较长，不能及时响应事情，从而导致团队整体管理效率变低，典型表现是很多事情没有及时处理、开始积压。

当然会议是需要的，主要是我们要总结出一套高效的方法。下面分享一些总结，有兴趣的同事可以一起探讨。

第一，确认会议类型及目的。我认为在我们公司的研发体系里以会议目的划分，会议大体可以分为以下6种：

1. 团队建设：激励团队，培养员工的团队意识，让每个参与人员了解共同的目标，树立全局观念，无形中能够帮助团队减少协调成本。 例如：版本项目周会

2. 报告绩效：向上级管理层汇告版本当前绩效情况，并且根据需要可以获得适当的资源支持，例如：RDM的项目分析会议

3. 平级沟通：针对问题通过会议讨论形成解决方法或是达成处理协议. 例如：开发和测试周会，跨部门合作会议

4. 信息传达：将信息传达出来，让相关人得到信息并理解信息，以方便进行下一阶段的工作。例如：新流程培训会议，经验分享会议

5. 创意开发：针对某一个问题的解决方案或是某个方向的创新主题进行讨

6. 评审会议：技术方案/需求文档评审，疑难问题讨论等

确定好会议类型及目标之后才能选定出需要讨论哪些内容，汇报哪些信息，以何种方式组织。这里举个示例：

示例：一个项目组对RDM做绩效汇报（项目分析会）。我们首先确定会议目标为：

a. 向RDM提供版本总体计划情况，当前进展，当前存在风险及计划应对措施，趋势预测等

b. 申请关键资源支持，因为RDM听过完整汇报时，对版本有了比较系统的判断，此时如果确实需要资源协助，比较容易得到批准

确定目标后，我们就可以发现开发和测试在这里是被作为一个团队看待的，因此在这个会议过程中开发和测试的意见应该是一致的，并且汇报的内容不能重复，但可以各有侧重。因此会议前开发和测试应该进行明确的汇报分工，各自总结完后，内部讨论得出一致结论。基于这样定位而组织的项目分析会，就会非常高效，并且能够在短时间内将版本整体情况展现出来，同时也促进了开发和测试内部一次完整性总结。而如果没有这些前期工作，项目分析会过程中，开发和测试意见就可能非常不符，甚至进行争吵，更严重的是发生互相责怪，推卸责任的情况。

第二，开有准备的会议。有准备的会议需具备以下三个特点:

1. 有清晰的会议历程及会议预期

例如：大多数开发和测试的例行沟通会议，是以明确问题及达成协议为主，而不是解决具体的某个问题，如果过于深入会导致时间浪费，更严重的是随意决策。

2. 选择合适的人参与

会议召开前需确定好哪些人要必须要出席，哪些人得到讨论结果告知即可。将会议控制在必要范围里的好处在于，避免会议浪费其他人员时间，同时保证会议的发言质量。

3. 选择合适的时机

合适的时机是指要评估与会人员的时间繁忙程度、解决问题的条件是否成熟，这个时间开会的效果如何？例如：项目进度非常紧张的情况下，项目组每周举行耗时很长的个人知识及读书经验分享是不合事宜的。

第三，议而有决，决而有行，行而有果。

从结果导向来看，会议都是基于某种目标而召开的，因此达成预定目标是非常重要的，会议过程中，组织者要进行有效的时间控制，出现跑题情况时要及时引导纠正，防止参会人员天马星空或过于深入细节，浪费大量时间。这个过程可以简称为议而有决。决而有行是指，会议讨论出的决策要形成任务分解，并落实责任人。行而有果是指，已经分解的任务要进行跟踪，产出效果。第三点总结起来比较简单，但是往往是我们最难以落实的地方，所以经常会出现诸如“这个问题，我们好像上次讨论过”的这类情况。

其他一些小技巧罗列如下：

1. 大会之前通常要有小会，从而达成高效

2. 会议开始前先讲解会议历程及预期

3. 会议上以明确问题、达成协议为主，不深入问题讨论

4. 会议上的决策直接指派落实责任人

5. 会议记录要在24小时内发出，最晚48小时之内

6. 对于例行会议，可以收集参会人员的会议质量反馈，进行持续改进

项目实战笔记之二：风险管理

风险管理是项目经理必备的硬功夫之一。风险管理贯穿于整个项目生命周期。根据风险的状态划分，可以将风险分为两个阶段：风险发生前，风险发生后。在不同的阶段里，需要我们使用不同的技能。

一、风险发生前

（一）关注风险效用函数

由于风险决策者的个人偏好、价值观和背景不同，不同的决策者对于同一风险事件会做出不同的决策，这种现象被称为风险态度，传统的效用的理论被广泛应用于分析决策的风险态度。根据效用理论，风险态度分为三种：

1.厌恶型：对风险极其敏感，要求在前期消除所有不确定性，会带来一定的成本浪费，中后期的版本风险将会递减或持平。

2.爱好型：喜欢挑战困难，自信满满，对风险神经大条，识别不出风险，通常版本风险在中后期会出现持续递增。

3.中性：随着项目的进展，问题的暴露对风险的态度随之加以变化，典型表现为前期对风险不关注，版本进展到中后期对版本风险投入更多关注。

因为风险管理是由人来执行的，执行人本身的偏好，将很大程度上影响到风险识别的敏感度及风险的应对方法。项目经理可以在以下两方面中使用风险效用函数：

1.了解公司对风险持有的通用态度及对本项目持有的特有态度，并且明确风险上报的标准

2.根据自己的风险偏好，结合项目的特点，寻找合适的管理搭档或组建管理团队（通常这件事应该由上级领导决定，但是我们可以反向影响领导的决策。这是作为优秀的项目经理都应该具备的能力）

（二）识别风险

风险管理中强调的一个观念：无法识别的风险是无法预防的。因此识别风险是风险管理的一个核心。识别风险需要做好以下两点：

1. 整体性的全局分析，识别出关键风险

就像将军通过沙盘推演把握战事一样，项目经理需要对项目做整体性的沙盘计划，部署优势兵力在关键风险处，降低版本失败概率。以结果导向的角度来看项目，通常组织或客户对项目的期望是“cheaper，faster，better”。根据这三点，我们得出项目的制约三角形：

加上项目团队是由人组成的，全局性分析风险可以从以下五方面进行：

从范围角度：当前项目是存在清晰的需求，需求是否复杂，市场定位是否明确等。

从成本角度：项目的预算是多少，风险储备金是多少，是否充裕？

从时间角度：工期要求是不是限定的，是不是签署了相关合同，进度和计划的可跟进性等

从质量角度：当前的技术方案是否存在风险，预研是否充分，人员的经验是否充足

从人力角度：人力组成是否充分，关键人力是否得到保证，是否存在不可替代的人员等

2.保证信息的透明性，发挥群体力量

除了敏感的信息外，项目经理应该尽量保证项目相关信息的透明性。信息透明可以从两方面来描述：

1)项目经理要将自己对版本的整体性分析、风险分析、趋势预测等信息告知团队，并获得共识

2)建立相对独立团队间的沟通机制（例如：开发团队、测试团队、规划团队）

信息透明化的好处在于，能够培养团队成员的风险意识、团队归属感，从而能够对管理人员的风险识别起到正向的纠正及补漏作用，而且能够让整个项目上下同欲，达成统一认识，对风险的应对方法减少抵触情绪。

风险识别应该贯穿于项目的整个过程。识别出的风险可以登记在风险登记册或风险管理表上。

（三）定期评估风险状态

风险状态通常包括这三点：风险发生的概率，风险发生的影响，风险的优先级。紧急不重要的工作因为时间的限制，通常优先级会被夸大。因此如果没有定期评估风险的机制，项目经理容易被当前紧急事情所驱动，难以集中精力处理重要的事情。定期评估风险的意义便在于跟踪风险变化的趋势，帮助版本经理集中精力处理高优先级的工作，从而保证项目的成功率。这里可以参考使用概率影响矩阵。

二、风险发生后

（一）资源协调，解决问题

风险发生代表风险已经转化为版本的实际问题，需要我们立刻进行解决。由于风险的存在及其不确定性的特点，通常在版本计划中版本经理会预留应急储备。应急储备可以用资金，+时间来进行衡量。这种情况下，我们需要评估应急储备是否能够消化该问题，如果不能消化，则需要采用变更进度计划，申请资源支持，或者加班赶工的方式来挽救项目。一个计划管理和风险管理意识不强的项目经理所负责的项目，通常会有”进度前松后紧，质量前面是太平盛世，后面是水深火热“的现象。

（二）持续做经验总结

聪明的人会从自己的经历中学习，智慧的人会从别人的经历中学习，没有反思，没有总结，就没有成长。风险管理是一项尤其依赖于个人能力及经验的过程组。只有我们不断反思、总结和别人交流，才能快速积累起这方面的经验。

项目实战笔记之三：时间估算的三步曲

项目绩效的重要衡量指标之一便是时间，这里总结下亲身经历的三步曲

第一个阶段：项目经理简单估算+倒推+部门预备机动人员

优点：估算速度非常快（很多时候，项目计划都是从上级给的发布时间倒推出里程碑）

缺点：计划非常不准，项目成功率不高。主要原因是：

1）项目经理个人思维限制考虑事情不可能百分之百周全，尤其遇到新的项目经理，项目成功的几率更是直线下降。

2）部门的人员总是要干活的，当项目发生风险时，原计划的机动人员总是不够用，或是不能停下手头的事投入项目中，如果遇到多个项目同时需要机动人员支援时，整体部门基本要全线加班，集体奋斗了。

3）项目组成员参与度不够，如果工作加班，有一定怨言

总体来说：还好每当这时候项目经理都能身先士卒加班，这时候部门的同事都是难兄难弟，总是很辛苦，但是项目结果总是不理想，不能按期交付。

第二个阶段：公司级形成估算团队做专家估算

为了改进估算，同时保证各部门绩效的公平性，公司针对A部门的项目会找其他的部门的专家参与估算，估算使用3点发计算出版本时间点，如果某个专家估算的不 准，则要求重新估算或当面讨论，最终取得一致后将成为项目发布的绩效点.

优点：相对公平，有一定信服力

缺点：

1）容易出现扯皮现象，项目估算时间很长，并且外部估算的时间计划难以转化为内部计划，工作量浪费很大

2）专家质量与主动参与度难以保证，尤其是参加多次估算后，专家容易倦怠

3）公司不关注人员分配，不考虑具体项目的最长路径，计算时间公式为：工作量/人力=项目时间

4）项目组成员参与度不够，如果工作加班，有一定怨言

总体来说：公司级的估算是CMMI引进到公司的，起到了很大作用，但是一定程度上造成了公司级的RDM组织和部门的对立，能力强的项目经理能够做很多线下活动，从而得到自己的绩效时间期望。

第三个阶段：部门自下向上估算+专家指导

其实第二个阶段和第三个阶段在一定程度上是有重叠的，第二阶段中，有一些先知先觉的项目经理，在公司开始进行估算前，首先进行了内部自下向上的估算，这样自己知道了自己的底限，如果有关键路径消除不掉，则要在总工作量加大，以达成自己的预期.

第三阶段主要的特点是项目估算以部门及项目为主导，当出现关键路径后，部门或公司专家帮助消除，如果消除不了，以项目估算为准做绩效点。

优点：

1）能够保证信服力

2）鼓励项目经理一开始把版本事情考虑周全，如果项目计划可行性非常高

3）全体项目人员参与的估算，更加准确，并且成员愿意为自己估算的时间负责

4）RDM和部门关系形成互助关系

5）估算结束后，直接产出可执行的项目计划

缺点：

1）估算周期稍长，通常需求基线后1-2周能给出

总体来说：这种方法是我个人最推崇的方法，能够有效提高员工的参与度及估算的准确度，同时维持组织的互助性，对版本成功非常有帮助。

项目实战笔记之四：团队建设（尊重）

知识型工作者只有让他们感到被尊重，被认可才能激发出他们的工作热情。制造业工厂监工式的管理方法，绝对量化的考核指标在知识型团队管理中将会失效，

这是管理人员面临的挑战，德鲁克也在《卓有成效的管理者》中对管理者和这种监工做了明确区分，其中的观点是监工是上司，但不是管理者。

一个抱着积极、认真负责，打拼事业心态的员工做事的有效产出和机械完成任务的人员的有效产出是多么的不对等，这里不需要再列举各类研究结果。尊重是激励文化构建的基石，如果没有尊重，激励就是空中楼阁亦或是短暂的激情。本篇笔记重点谈谈在项目管理过程中对如何给予员工足够的尊重。

1、项目的意义

成就感是让团队努力向前的最好激励方案，任何项目的成立都是有意义的，如果能够让整个项目团队时刻清晰的认识到自己是再做一件对部门、乃至对公司意义重大的事，则往往能够焕发出团队很强的战斗力。受到关注就会给人被看重感，人就感觉到要对事情付更多的责任。

推荐策略：

1）项目启动时，高层领导进行动员，宣传项目意义

2）项目中期，规划负责人/项目经理要能定期发出一些市场人员/客户对项目的期望

3）项目结束后，高层领导要能够反馈项目获得的成绩

2、项目时间估算

我个人比较推崇的估算方法是自下向上的估算（具体可以上篇文章：时间估算的三步曲），自下向上的估算能够给予项目组员一定的发言权及主人翁感，并且能够调动大家责任心，通常大家愿意为自己的决定负责，但是如果是领导直接压下来的任务尤其比较紧急时，通常有些抵触。当然在自下向上的估算中，要有专家进行指导和把关，包括估算漏掉的哪些事情，项目组内例行需要消耗的时间等，并且针对”狮子大开口“的时间需要进行讨论，达成一致。

在这种估算方法做出的项目计划下，如果项目最后出现了问题，尽管项目经理要承担直接责任，但是项目团队成员通常会比较自主的愿意与团队共度难关。因为决策是大家一起制定出来的。

推荐策略：

尽量使用自下向上+专家指导的方法进行估算，如果有人员到位或者估算周期的有限制，至少要保证关键人员的参与，而慎用自上向下的估算方法.

3、善用加班文化

IT公司加班是件很自然的事情，如果哪家公司没有加班情况，反而会让人感觉不正常。做为项目经理应该首先理解，加班虽然是IT公司的普遍现象，但是确实是组员为了项目做出了额外的奉献，他们牺牲与家人团聚的时间，牺牲了休息时间，甚至影响了健康。这种行为值得我们尊重，我们要小心使用这项权力。

1）不要动不动就抛出一句“这个今天搞不定，就打地铺解决”等，这种言论是对员工额外奉献的一个严重的漠视，而且带着很强的个人意愿

2）时时保证项目的进展的透明性，可以通过周会，日报的形式在团队中发布。当遇到赶工时，跟当事人讲解当前团队面临的困难，总之，加班是个艰难的决定，是为了整个团队的绩效，不是项目经理的个人意愿

3）任何加班时项目经理都应该尽量身先士卒带队

4）在一些公共场合，尤其有上级领导在时，公开表扬那些为团队做出很多额外贡献的人

5）绩效考核肯定以结果为导向，不能以加班多少论英雄，但要有其他措施安慰最辛苦的人

推荐策略：加班是一种奉献精神，我们要小心使用，认真对待。不能简单的当做管理者的权力，轻言肆用，否则久之必招其离心

4、开放沟通的团队氛围

人都希望自己能够有发言权，能够对关心的事情产生影响。上至国家领导人的选举，下至日常的工作生活。如果发言权被长期压制，就会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后，项目经理总是能在一些讨论中，得到很多比预期更好的解决问题的方案。一个强权的管理者，容易获得一定程度上的执行力，但是容易被自己的盲点击败。而一个开明的管理者，往往能使用集体智慧，获得跟随者，更容易产生威望。

推荐策略：

1）项目沙盘等关键策略制定时，要全体项目参与讨论

2）项目经理鼓励大家发现问题，提问问题，对于好的措施，能够采纳执行

5、责任到户 VS 大锅饭

从头到尾的责任到户制应该是最理想的工作分配方式了，在这种分配方式下，团队成员有一块自己土地，通常愿意花更多的时间与精力去耕耘（例如：某个全新的模块），如果这个模块又是他一直想尝试的方面，那将会更加完美，我们有理由相信他将会在这里充满了激情。

然而世界上总没有十全十美的事情及百分百通用的方案，尽管责任到户制如此之好，但是在某些项目上我们达成不了这样的期望。

我所亲身经历过的两个版本就遇到了这样的状况。两个版本的共性是：在一个很大的系统上做覆盖面很大的，很多小点的修改（例如：更换所有UI系统），但是基于老系统的复杂性及历史问题，项目在中会遇到很多bug，各种各样，在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任，这种情况下责任到户制会出现失效。在面对系统这么多的bug时，项目经理很容易想到一种方法：“那就是给大家分配bug数，下指标，每天每人要解决3-4bug等”。两次项目经历中，项目经理确实都想到了这种方法，区别是前者实施了，后者被我阻止了。原因如下：

1）团队组员容易产生不被尊重感，被当成解决问题的机器

2）团队之间的协作会发生困难，而且过度强调这项指标，例如谁每天不修改完这个bug数，就要加班到10:00之类的，会导致部分组员开始取巧，每天争抢容易处理的bug

3）没法发挥人的主动性，将团队目标和个人目标相背离

这种情况下大锅饭的机制似乎更合适一些，如果团队没有达成目标则需要一起想办法或加班解决，而不是将这人归咎个某个人。

推荐策略：在正常项目中尽量使用责任到户制，而对于一些特殊项目，则选用大锅饭制，没有一成不变的方案，具体情况具体变通。

项目实战笔记之五：里程碑管理

一、背景

由于公司及部门的发展，项目经理已经开始面对人数众多，时间跨度较长的版本管理挑战。

如张湘辉（1994年加盟微软，现任微软大中华区CTO）所说：

以Windows 7为例，包含七八千万条甚至上亿条代码，五六千人同时开发，还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言，不能一眼盯到结果，不能像跑百米一样，始终盯着终点。我们的经验是盯终点肯定乱，因为要经历非常漫长的过程。

从心理上说，当发现离终点还很遥远时，人就会泄气，不能以那么快的速度玩命跑下去。最好的方式，是将事情分成很多步骤来做。Windows7从开始到完成可能要耗时两年，以两年时间为一个周期，那么前六个月团队就会被弄垮，所以你必须以也许每两个月为一个终点。就像跑一千五百米，我们要考虑第一圈跑多快，第二圈跑多快。

这就需要把每个终点区分得很好，设定有效的里程碑，在逻辑上要很精准，是不是到了这个里程碑，同样要非常清楚。这样每个里程碑达到时，大家可以庆祝一下，重又奔向下个目标。如同爬珠穆朗玛峰，没有说不断爬上去，而是先到大本营，再到第几个营地，最后才能登顶。

从过去的3.0，BM2.0等较长时间的版本管理中，能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分，例如：转测试，转联调等，项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准，满足则进入。总体来说项目还是以最终发布时间点为目标，这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法，产出里程碑管理的概念。

二、目的

里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果：

1、 使团队将长期目标划分为不同的短期目标，就像跑长跑一样，不是以5W米为目标，而是把目标分解到每一圈

2、 在里程碑处，团队进行有效的休整。就像队伍打仗时，一定要有休整，才能持续保证旺盛的战斗力

3、 促使组员进行上个阶段的总结，找出自己的不足，并吸取其他人的优点，从而让组员进行成长

4、 整理下个阶段的工作思路，促进大家进行整体思考，并对模块进行全面分析。

三、具体内容

1、给予项目组时间，进行全员总结，包括上个阶段的总结，下个阶段的工作思路，做成PPT

2、由每个人在会议上将自己的总结PPT进行分享 （做成ppt并在项目会议上进行分析，会引起大家的重视，自然效果会好）

3、进行表彰，表彰做得好的人员，由主管亲自颁发奖品（结合奖励措施）

4、用本小组经费进行欢庆，吃饭+KTV之类

四、计划支持

1、项目计划中安排好总结时间

2、制定里程碑奖励措施，并且在上个里程碑点处进行宣传，过程中进行相关数据统计

3、向公司提前申请所需的时间和金钱资源

项目实战笔记之六：团队建设的三种境界

经过自己总结和项目经理们探讨，认为项目或部门团队建设可分为三个等级：

一、乌合之众，强权政治（新手）

很多新手都会经历这样的过程，新组建的团队冲突不断，大家对当各种制度措施，报以反感。为保证执行力和项目成功，项目经理会选择强权压制，尤其是技术比较好的项目经理。大抵的逻辑是“我是老大并且我资深，要听我的”。最终的结果是大家对项目目标已经完全不感兴趣，一些冲突升级到个人情感冲突，项目经理左右突击，上蹿下跳，甚是辛苦，忙碌，确得不到大家的认可。

此时的项目经理至少需要做到两点，才有可能进入下个阶段，用杰克韦尔奇的两句话概况：

1、“在你成为领导以前，成功只同自己的成长有关。当你成为领导以后，成功都同别人的成长有关。”

2、“世界上的每一个人都想得到发言权和尊严，而且也应当得到”

所谓“发言权”，是指人们希望有机会说出他们的思想，拥有自己的观点、看法、获得被倾听的感受，无论他们的国籍、性别、年龄或者文化背景如何。

所谓“尊严”，是指人们本能地和自发地希望由于自己的工作、努力和个性而得到尊重。

这个阶段之所以命名为乌合之众，是因为大家对团队根本没有归属感，甚至厌弃团队，期望团队得到解散，或者团队目标达成时，并没有取得成就的感觉，而是有终于熬过来的感触。

二、尊重，民主社会 （老手）

在经历过挫折或是老前辈们的谆谆教导后，新手往往都能进入这个阶段。当然有些厉害的人有时也会自己跳到这个阶段。但是这个阶段里的人，也有高下之分。在这个阶段的人，往往可以带团队时，往往可以做到：

1、尊重，言路开明

不把人当做机器。制定计划，措施时，都可以征求的大家意见，当然计划定下来后，执行时是不能含糊的。

2、善用人才，培养人才

团队里有人才时，会使用授权等方式调用这些人的积极性，而不是幼稚的打压，并且在团队里没有人才时，能够积极选拔备选人员，并给予锻炼机会

3、分享荣誉

这个阶段的项目经理，在交流中，会摈弃掉“我怎么样，怎么样”，多使用“我们，我们团队怎么样”，尤其是在面对表扬和荣誉时。在项目组内也想方设法树立榜样，并且非常愿意这些人被自己的上级所获知，愿意为这些人谋个好前程。

4、坦诚

坦诚是相处的长远之计，而忽悠，画大饼这些手段只能短期效应，并在长期上让自己的人格受损。关于这点项目经理大多做得程度不一，有时说出一些不开心的事，是需要勇气的，例如在绩效沟通时。但是这个阶段的项目经理都了解它重要性。

5、团队信息透明

只有信息足够透明，大家才能够为项目出谋划策，才能有坦诚沟通的基础，大家才能对项目归属。“垄断信息，以显示自己领导的地位”是愚蠢的人才会干的事情

这个阶段之所以命名为民主社会，这个阶段的价值观是：民主计划，严格执行，有付出有回报，集体荣誉。第一个阶段到第二个阶段可能需要时间的积累，而第二个阶段到第三个阶段，有时却可望而不可达。

三、激情，燃烧军团 （高手）

激情团队的充分必要前提是，团队负责人是非常有激情的。这点很关键，一个打工者心态，没有把工作当成自己事业经营的人是不会带出有长久激情的团队。检视的原理：“看一下大家是不是为了同一个梦想而走到一起的”

要达成团队激情，至少具备以下几点：

1、老板风格，老板要有分享成功的决心，例如：股票，期权激励

2、企业文化，企业要有文化宣扬集体奋斗的精神，企业的使命价值观能够深入人心，得到强烈响应，此时企业的创新精神，将是从内而外的，从下而上的，大家集体思考，集体进步，集体创新。

3、有激情的中层，公司中层是企业的中流砥柱，如果每个中层是有激情的，扩散开来的影响力是很大的，反之，则激情容易变成口号。

这里典型的案例是sony的没落，从井深大的激情军团的消失，井深大倡导”工作保证本身就是一种强有力的激励“，把这种理念能够深植公司是多么可怕，激情可以创造出很多奇迹。

约翰·科特说过“如果你想建造一艘船，首先要做的不是去采集木材、加工木板和分派工作，而应该去唤起人们对广阔无垠大海的向往。“ 管理者的本质是获得追随的人，一个企业，一个团队如果能够拥有一批愿意追随公司成长的人，所产生的正向能量是无比巨大的。

这种境界的达到需要多方因素的促合，颇似于武侠里的天人合一，激情团队的管理将十分简单，保护这种激情，员工会很自主的进行自我管理。

当然实际工作中，以上每个阶段不孤立存在，可能会存在一些阶段的中间体。