谈谈软件项目管理的重要性(2)_软件工程

作者:马云冬(xacn)
版权所有：马云冬(xacn)

二、软件项目治理问题：

1、现代的软件开发，技术不是要害：

　　随着日益增长的软件需求和软件系统功能的增强，过去一个人开发的历史以不复存在。现在单枪匹马写程序也只是一种娱乐。我们一般开发的系统都是一个小组才能完成的。所以治理才是开发出好的软件的前提条件，没有治理一定出不来好的软件，当然有治理也不一定出软件的。一个成功的软件不一定是最好的技术，但在它背后一定有一个好的治理。所以现在的软件开发已不像从前把技术放在第一，而是该把治理放在第一位。我在网上看到一篇关于中国软件和印度软件的比较。我现在记的不是太多，但对我影响最深的是他们会去权衡技术和开发效率问题。如现在开发一个软件，用户要求去在三个月内完成，你在做系统分析时也认为在三个月能完成。但你没有考虑到一些细节，你写完系统的总体设计，在进行具体设计时碰到要建一张不是太大的路由表。这时大多数国内的设计人员就会想用什么算法，去花很多时间去设计研究新的算法和技术，而人家首先考虑的是系统的运行环境，而这个软件设计了是在（CPU：1.1G，内存：512M）中运行，用户也没特意提出其运行效率要求。所以人家就在内存中开一个大数组来对这个路由表进行操作。从这点看，人家注重的是软件的整体，而不像国内大多数据设计员那样，把个体放在首位。其实这方面我觉得我们的开发员应当多向共产党学习（本人不是共产党员，团员也因没交团费被Cancel掉了）。把软件设计的整体放在首位，而不去花太多的时间在不一定成功的技术上。假如花太多的时间在技术上去，这将对系统的按时完成带来影响。我也不是说不该研究技术，我只是说开发中应当以全局为重。假如要加入新的技术，必须在分析时就预算其所需要的时间，并设置技术风险治理。假如风险太大就应当取消用这项技术，改用其它的已成功的技术代替。风险治理这是近来才提出的软件治理方法。它对我们的软件项目有着很好的控制作用。对于一些中、大型系统，它是一把走进成功之门的钥匙。这里就不谈了，我将在下面进行说明。
2、好的治理才能开发出好的软件（小系统除外）：

　　大家都知道，软件开发中有太多的不可预知性。但这种不可预知是对总体来说的，当软件进行到一点程度时，不可预知的东西就会变成可预知的东西。以住的做法是不去治理它，这样所带来的就是项目的失败。要是有好的治理方法就可以控制这些不可预知的东西，软件项目就会一步步随着你的设计思路起向成功。现在就和大家一起讨论一些常用的软件治理方法。

2.1、错误治理：

　　小时候当我做错事的时候，我父亲总是把我叫到他身边，对我说：“没事，只要下次不做相同的错事就行了。”这话也许很多家长都对自己的小孩这么讲过。小时还不觉得，慢慢长大后，会发觉其中深刻的道理。这就是说从错误中吸取经验教训。软件项目开发中的错误也是一样。软件开发是一项复杂的活动。一个典型的软件开发项目可能会给我们提供很多的机会去从错误中吸取经验教训。一般的软件项目也会提供少量的错误给我们学习。学过开车的人都知道，教练老是会这么讲：“我希望你们从我身上学习我和前人的的经验，这些经验你们就不要再去试了。假如要试你也许会赔上钱甚至于生命。”虽然软件项目开发不会赔上生命，但是失败的软件项目是一定会赔钱的。所是在软件开发中少不了要对错误进行治理。在项目的错误治理中我一般是这么做的，现在和大家讨论一下：

a、列出典型错误：

典型错误中有人员方面的。如：对有问题的员工失控、挫伤积极性、人员素质低、英雄主义、项目后期加入人员、开发人员与客户之间发生摩擦、不现实的预期、缺乏有效的项目支持、缺乏各种角色的齐心协力、政治高于物质、布满想像等…

典型错误中有过程方面的。如：过于乐观的计划、缺乏足够的风险治理、缺乏计划、在压力下放弃计划、在模糊的项目前期浪费时间、前期活动不合要求、缺少治理控制、缺少质量保证措施、鲁莽编码等…

典型错误中有技术方面的。如：过高估计了新技术或方法带来的节省量、项目中间切换工具、缺乏自动的源代码控制手段等…
.
b、列出自己的最差实践：

注重典型错误，建立自己的最差实践列表，可以避免在以后的项目中犯同样的错误。

c、列出项目中的最差实践：

组织机构和其他项目组总结经验，学习他们的错误中得到的经验。和其他组同事交流项目开发中的磨难，学习他们的经验。列出潜在的错误，看到它我们就会尽量避免今后犯同样的错误。

打个适当的比喻，典型错误好比我们学车时教练讲的经验，自己的最差实践就像我们在实际开车当中出的问题，而项目中的最差实践就是我们学车前的笔试的书。

公司在发展的同时，也会积蓄一些各方面经验。列出所有的经验，按其分类。系统分析中的经验提供给系统分析，设计人员中的经验提供给治理人员，技术中的经验提供给开发员。这样我们就会有更多的时间花在新的错误的防范上面。开发出来的系统就会一个比一个好。
2.2、风险治理：

下面先看一下来自一段网上的文章吧！

“一般认为赌博是在冒险。拉斯维加斯老机的设计者将老虎机的最大赔付率定为97%，即你花一天时间，往老虎机里塞进100元，最多只能赢回970元。

但是，假如比起软件开发所冒险，拉斯维加斯的赌博简直就可以称为“安全的冒险”了。软件项目所面临的不断变换的用户需求、糟糕的计划与估算、不可信赖的承包人、欠缺的治理经验、人员问题、伤筋动骨的技术失败、性能欠佳…..等等不胜枚举的风险，使大型项目按时完成的概率几乎为0，大型项目被取消的概率和赌博一样成败参半（Jones 1991）。”

所以项目开发中对风险进行控制治理就大大提高了软件开发的成功性。软件风险治理工作就是在风险成为影响软件项目成功的威胁之前，识别、着手处理并消除风险的源头。一般我们可以在几个层次上定位、治理风险。

危机治理---救火模式，就是在风险已经造成麻烦后才着手处理它们。
失败处理---察觉到了风险并迅速做出反应，但只是在风险发生之后。
风险缓解---事先制定好风险发生后的补救措施，但不做任何防范措施。
着力预防---将风险识别与风险防范作为软件项目的一部分加以规划和执行。
消灭根源---识别和消除可能产生风险的根源。

1、2、3项都是被动进行的，亡羊补牢，为时以完。所以我们应当着力于预防风险，更好的是消除风险根源。

风险治理由风险评估和风险控制。而风险评估由风险识别、风险分析和风险优先级组成：
风险识别：就是提出一个潜在破坏项目进度的风险列表，就像生成错误列表一样。
风险分析：评估每一个风险出现的可能性及其影响，判定风险的级别。
风险优先级：按风险影响大小排出一个风险优先级，这个风险列表将作为风险控制的基础。

风险控制由风险治理计划，风险化解和风险监控组成。
风险治理计划：制定一个应对每个重要风险的方案，同时就确保每一个单独的风险治理计划之间以及与整体项目计划之间相一致。
风险化解：每个重要风险所对应计划的执行。
风险监控：就是对解决风险的过程进行监控，风险监控还可以包括识别新的风险并将其反馈到正在进行的风险治理进程中等方面的工作。

　　现在以我以前做的项目来说明一下我是怎样进行风险治理的。

　　接到项目对项目进行调研工作，在调研中就要注重到刻服错误列表中的错误。调研完成后，写需求说明书初稿（一般根据情况至少给出二个以上的方案），为客户进行讲解，结合客户意见再次进行修。把修改后的说明书和同士进行讨论，再次进行修改。在此期间写出总体设计的初稿（大的框架）。最后再为客户讲解，再次修改少量的功能。客户确定需求满足后就可进行总体设计了。在生成需求分析的同时，注重列出需求中存在的风险。如：需求改变问题、需求定义欠佳等风险。在进行总体设计时，多和客户交流。因为在总体设计中修改需求比在具体设计中修改要轻易比在编码阶段修改就更加轻易了。之后生成总体设计说明书。同时在总体设计中也要对一些不定的因素进行风险监控。列出风险列表。根据总体设计说明书就可以开始具体设计了。在具体设计中除了要考虑系统设计外还要考虑一些技术风险问题。把很难预见的问题列到风险列表中。注重，从需求分析到具体设计，随着系统开发的进行度。以前不明的因素将会慢慢显露。同时也会出现新的不明因素。这样就让我们必须在整个设计开发过程中进行风险监控、风险识别、风险分析和风险化解工作。同理，在编码中也同样处理。在开发过程中根据分析不同，把风险按阶段分为需求分析阶段风险、总体设计阶段风险、具体设计阶段风险和编码阶段风险。并交由此阶段的人员进行监控和化解。同时，假如在化解安全区（规定解决问题的时间段中）内无法完成解决，则提交专家组（包括到外请的专家顾问）解决( 我们一般是在周五下午的讨论会上进行)。当然软件开发中所碰到的风险是很多的。但不可能完全同时进行风险监控的。通常是把风险列表中认为最会发生的风险乘损失的大小后的最大数进行严格的监控起来。随着开发进度，风险是在变化的，所以风险列表可能会增加也可能会减少。只要风险治理好了。系统就成功了一大半。
2.3、人员治理：

　　不同人员之间经验的不同导致绩效差别是有目共睹的，大家可能对不同开发人员之间生产效率差距达10：1的观点较为熟悉，大家也知道一些明确激励措施所带来的正面影响。所以人员治理在软件项目中也有较重的分量。

很清楚，人力因素极大地影响着生产效率，同时任何关注提高生产效率的组织首先必须有一套良好的人员激励、团队合作、员工选择及培训的机制。这样才能充分发挥人员的自身能动性。为公司创造更多的价值。

　　　除了以上几个面的治理外还有其它方面的治理也决定软件项目的成功与否。如：团队合作、团队结构、生产率工具等等。这里就不多说。大家还是抽空多看看书。因为只要你选择了从事计算机工作，你就选择了永不能停止的学习、学习，再学习。否则你就将被淘汰。这是多么残酷但又多么现实的事呀！