目标、风险与计划.doc

目标、风险与计划不以善小而不为，不以恶小而为之引子传统的项目实施过程中我们经常会遇到一些困惑。我们所做的工作为了什么？我们每天做的工作依据又是什么？明天会怎样？。有一次我听客户说了一句值得人深思的话，“我天天在做噩梦，噩梦我不害怕，我害怕的是不知道这场梦什么时候才能醒”。项目的核心有人曾经问过一位业内的大师级人物，如果项目的整个生命周期过程中所有的文档都要丢弃，只留下一个，您会选择什么。大师毫不由于的说是项目的愿景文档。这也是我们所说的目标。目标所要表达的是一个聚向性的概念，他是整个项目的核心。从某个角度说项目可能是目标所衍生出来的；风险来源与目标，如果没有一个定性的目标我们也无从谈及风险了；为了达成目标我们衍生出来了计划。我大胆的用一句话概况一下，我们在通过计划一步步的解决所要面临的风险，而最终完成所要达到的目标。目标其实是约束着项目至始至终的唯一准则，任何违背目标的工作都无需考虑。用我们常说的就是“不达目的誓不罢休”。项目的驱动我们仅在传统的瀑布式开发和RUP迭代式开发的语境里来分析一下我们所遇到的问题。下图是我们经常引用的一个迭代和瀑布的对比图。两种方式区别最大的就是曲线和坐标轴所围成的面积，面积其实就是风险。换而言之，为什么用迭代方式而不用瀑布的原因就是降低风险。风险的治理也成为了项目管理的驱动力。在讲以下内容前我们引入一个概念就是“问题”，通俗的讲我们预测未来将要发生的称之为风险，然而发生的就是问题。想想看我们是不是每天都在预测风险伴随着解决问题呢？我们再从风险的管理角度去看待瀑布和迭代。在风险管理中有一个容易被人忽略的概念就是风险成本。其实避免风险发生所花费的成本在某些时候不一定比解决风险所带来的问题花费的成本要少。这也就是为什么有时候让我们感觉迭代开发所要承受的成本和瀑布式开发所要承受的成本没有很大的差异。但是通过对风险的分析，然后制定出风险解决的优先级，按顺序的在每个迭代周期内有目的性的解决风险（这和后续要说明的计划有着直接的联系）。可以减少项目的成本。瀑布的情况下有些风险必然会发生，迭代的情况下有些风险偶然发生。迭代最大限度的避免了“交付即意味着失败”。我们把风险的内容展开。风险管理可以简单的看成三个阶段，风险的分析、风险的控制和风险的监管。风险的分析这个阶段主要围绕对风险的定性上，它主要的目的其实是将风险在客观环境里进行度量，而后排列处理的优先级。这里我们主要描述一些相对重要的指标，风险值、风险等级、发生的可能性以及转移指标。风险等级：根据经验风险的等级不用划分得过分细，5-7级即可。因为等级其实只是一个相对的概念。不同的项目背景描述的相同等级，实际造成的后果可能相差甚远。并且过于细节化的分析风险的等级可能加大其分析的工作量。发生的可能性：建议用百分比的形式，精确的程度依据具体的项目背景而定。由于有些风险发生的几率是十分的小但并不代表着不会发生，甚至有些风险可能明天就会发生。依据最大和最小的相对程度进行对精确程度的制定。风险的值：风险值=风险等级可能性。这样我们可以根据风险值来判断处理风险的顺序。我们能够让有些比较隐晦的风险暴露出来，使得我们能够及时的进行处理和跟踪。这样可使我们避免将有些自认为小事而疏于管理（善小而不为）。转移指标：预示着风险即将发生变化的信息。在很多人眼中这一项是最难分析也是最容易忽视的一个指标项。正常的情况下这项内容来源于两个方面，以往的个人经验；拥有健全的风险管理系统，通过风险管理系统我们可以在以往的其它项目所处理风险的过程中进行挖掘和整理，让此内容拥有更科学的依据。记得我们上文说到的风险成本，由于成本带来的巨大压力，致使我们不希望每个风险都进行处理，只有进入到转移指标的范围内我们才开始处理风险，从而使我们能够避免不必要的成本流失。例如，一个风险称之为“由于部门人员不足致使项目主要人员的更换”它的转移指标可以是“新项目的成立；主要人员生活出现异常”，在项目初始阶段我们可能认为这根本不能发生，但带来的灾难却可能是致命的，通过风险值的计算，它可被列入的关注之中。但不是开始阶段就在筹备处理此事的方案。通过转移指标的提示我们可以准确的把握处理此风险的节奏。风险的控制此阶段主要描述的是风险的处理措施，描述的内容可以是事前、事中以及事后三部分。理想的情况下应该描述风险的成本。以往的经验大家经常喜欢描述事后的内容，但这样无法和事前进行处理所花费的成本进行对比，很难有效的判断项目的完成质量。风险的监管此阶段主要描述风险措施的验证工作以及风险状态的追踪。根据以往的经验我们往往忽略了风险的跟踪，但跟踪却是整个风险管理的目的。此部分还有两个个指标称之为编号和关联值。编号方便我们能有效的进行跟踪管理，关联值代表风险间的关系，某些风险是在特定的风险发生后连锁发生的，这些信息也可在转移指标中被记录。风险的监管其实就是我们对整个计划的驱动。以上的几个阶段只是我们风险管理的灵魂，但只有灵魂还不够，我们需要实时的对风险进行维护。项目的轨迹在RUP中所描述的四个阶段，仅仅是项目计划的一个大体的轮廓。很多人对迭代周期的划分都很困惑，之所以很难划分是因为没有可依据且可度量的值。可度量的值就是任务（任务通俗的可以理解成风险+问题）。任务的内容依据也可以说就是风险，任务执行顺序依据可以说就是可发生风险处理的优先级。处理任务的资源就是风险追踪在计划中的反应。计划不应制定的过于长远，越长远的计划越缺少可信度。如同敏捷所倡导的短期计划一样。例如Scrum中描述的“燃尽图”横坐标是一个指定的时间周期，纵坐标表现的是一个团队的极限工作能力。斜线代表着最佳的处理事情的能力，曲线代表实际的工作内容。计划其实就是平衡图中的曲线。RUP中在指定迭代周期工作计划前，描述了本次迭代所要完成的任务数量，在周期结束后需要对任务的达成进行评估。此评估工作是迭代开发的重要环节。个人认为项目整个过程中最不能形式化的就是计划。务虚的计划就是项目最大的风险。对于计划所描述的内容，必须是在项目的目标指引下，并且是可执行的任务，反映的是具体工作的真实情况。心语习惯性的在阐述完自己的想法后，都喜欢从另一个角度再去审视一下所描述的内容（俗称“跑题”）。现在让我思考的是面对风险的心态，和管理的艺术。面对风险有时就像我们面对人生中所遭遇的困境，有人选择利用种种理由去逃避，有人坚强的选择去面对。极限编程里的拥抱变化，和风险管理的与熊共舞（熊代表着风险）。教会我们如何乐观的看待，每天在项目中所遇到的不快乐的事情。管理的艺术，有效的沟通是管理的法宝，在计划的制定中，项目的管理者不应该是