高效会议的组织方法：

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

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

　　第一，确认会议类型及目的。我认为在我们公司的研发体系里以会议目的划分，会议大体可以分为以下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周能给出

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