热爱测试生活

发布新日志

  • 【转】软件项目管理杂谈

    2009-02-03 11:17:16

    在一次由软件项目管理者组成的交流会上,看到过我所写的《软件项目管理原则谈》的朋友向我发问,如何在所学的项目管理理论和实际项目实践中找到一条连接的纽带;软件项目管理的度如何把握;为什么项目协调中更多的是貌合神离;为什么自己觉得自己所管理的项目老是失败等等。这一连串的问题引起了与会的项目管理者的同感,笔者本人也曾经在项目管理中屡遭挫折,目前的项目管理中依然麻烦不断。但是,作为一名软件项目管理者来说,在实施项目管理的过程中,笔者觉得在项目管理中,我们的大多数人常常在管理思维中留下一些空白,而这些空白正是我们公正、客观地评判和成功执行软件项目管理的必要途径。

      空白1: 为效益而实施项目管理

      为什么我们要实施项目管理,是为了提高项目的效益。这里所指的项目的效益是一个综合性的指标,包括低风险、高产出等。为此我们不难得出我们在实施项目管理应该掌握的度。即:引入项目管理后所产生的效益减去项目管理的成本后必须大于未引入项目管理时的效益。由于引入项目管理后所产生的效益与项目管理的复杂度(项目管理的成本)并非线性相关的,因此项目管理的复杂度必然存在一个最优值,这就是我们应该把握的度。也许上面的说法比较抽象。一个实际行之可效的判断项目管理的度规则就是:大家认可并且能够准确地理解和实施。拿美国项目管理专家James P Lewis的话说就是 KISS原则(Keep it simple and stupid),拿物理学家爱因斯坦的话说就是:Keep it simple but not too simple.

      空白2: 考虑所处环境

      任何系统都是建立在一个具体的系统环境中的,一般情况下受上一级系统影响最为显著,这是系统论的观点。项目管理是企业管理的下属层次,因此在很大程度上项目管理的成功与否常常受企业管理的制度制约(比如说设备采购的批复等待会延误工期),这就是为什么常常会出现计划不如变化来的快的原因。因为我们在制定计划时根本就没有考虑自身和客户双方的企业管理的环境,所以我们的计划在实施过程中会受到企业管理环境因素的影响。我敢跟你打赌:在没有人事激励机制常常拖欠或故意克扣员工工资但获得CMM5认证的公司开发效率不会比一个没有实施项目管理的开发团队的效率高多少。因为恶劣的公司人事制度扼杀了开发人员的天才和积极性。因此,作为一个项目管理者,审视自身的项目所处的企业环境并做出准确的判断是非常有必要的。缺少良好的项目环境,项目管理者的心血常常白费。这往往是我们中的一些项目经理在不同的公司里项目管理表现大相径庭的原因。

      此外,正是基于企业环境这样一个观点,目前美国PMI,日本ENAA等提出了项目管理成熟度模型(OPM3和P2M),改变了传统PMBOK的缺陷(忽略外部因素和自身的灵活性)。有兴趣的项目管理者可以参看有关项目管理成熟度和企业管理方面(建议参看职业经理人方面)的资料。

      空白3: 合理评判软件项目管理

      我们总是把过多的项目失败归罪到项目经理的名头上。他们的角色常常是替罪羊而不是领导者,他们拥有的更多的是责任而绝非职权。实际上项目失败并非完全决定于项目管理,比如说信息系统过低的报价。一个项目按时在预算范围内完成了而另外一个则没有按时完成,这不意味着第一个项目管理得比较好。因为前者可能是项目时间和成本宽松的项目而后者根本就是不可能完成的项目。前者项目管理的意义在于获得较高的项目效益而后者的意义在于避免更大的项目损失。很可惜,充满了浮躁的软件企业没有诸如此类的意识,一些项目在未开始前注定就是失败的,项目经理们一上手便被扣以一责任人的镣铐。因此,项目管理有无具体效果,需要合理地进行评判,单纯以出效益为上的观点未必有失偏颇。

      空白4: 心理学的必要性

      没有一个领域像软件项目管理中人的因素更为重要,在软件领域没有实现自动化之前,一切试图取代人的主要作用的机制都是收效甚微的。人的行为是心智活动的表现。开发人员的心理活动决定了其在开发的表现。合适的压力能够勾起开发人员的成功欲望但是过大的压力却直接影响着项目参与者的身心健康。特别是后者一直以来都未能引起软件开发界的重视。很多人曾经有过不明不白的辞职经历,在没有学习《管理心理学》之前,笔者对这些人的"过激"行为有时想想都觉得奇怪。作为一个软件项目管理者,不了解和掌握管理心理学,很难针对复杂多变的人的因素采取合理的应对措施,同时自身的心理健康也未必能够得到保证。为此笔者建议有条件的软件企业,可以通过聘用心理顾问来处理员工的心理问题,以此缓和由于工作压力而导致的员工之间矛盾冲突和项目坍塌。

      空白5: 尊重常识,系统性考虑问题

      这个观点笔者在《软件项目管理原则谈》已经重申过。就像不要指望人一秒钟跑二十米一样指望项目中有过多的奇迹出现。可惜我们中的大多项目管理者在进行项目管理时依然实施"大跃进"。我们的管理者都知道自然规律不可违抗性,但是却很少有人意识到一些社会规律的不可违抗性。他们总以为唯物的主观能动性能够替代实际,产生奇迹。加班被认为是解决资源匮乏的唯一途径,通过开发人员"无上"的生产力来达成项目的成功。很少有人会意识到加班造成的疲劳会再次使工作效率降低这一事实。这是一种缺乏常识和系统性思考问题的表现。诸如此类的表现还有"唯工具论"和"唯方法论"。

      实际上,项目管理涉及各个方方面面,一味提高某一方面作用而忽略该方面对其它方面的影响,并不能提高项目管理的层次和最终产出,这是制止我们的项目管理者走偏激(极端)立场的一剂良药,希望项目管理者们能有所意识。

      空白6: 学会思考

      项目管理不是拿来主义,需要项目管理者进行认真的思考。这就是为什么我们项目管理者中不乏PMP和IPMP但是项目却未能如愿以偿的原因。理论和实践的差距极大地挫伤项目管理者的积极性。"证书无用论"所持的观点其依据也在于此。理论是一种完美的抽象,而现实是各种条件的集合。我们的项目管理者在实践上往往生搬硬套而忽略其依存条件,这就是招聘项目经理"唯经验论"的来源。一位项目管理者跟我交流的时候提到无法使用挣值(Earned Value)的概念,原因是公司人事部和财务部不愿意出示员工的收入清单。我建议他将挣值换为挣时(Earned Time),以时间替代成本。从项目进度的意义上来看这两者其实是一致的,问题马上得到了解决。可惜的是我们的项目管理者往往未学会思考具体概念的真正含义之前并匆匆上驴,提着长枪去和风车做斗争去了(注:唐吉诃德)。

      空白7: 学会计划

      现实中我们往往用补救措施代替计划,其效果便如软件缺陷的放大效应。在项目经理的招聘中,你听到的只是几个项目管理白痴问你项目出了什么问题应该怎样解决的提问,这些项目管理白痴在不断地做各种问题假设,而你必须根据假设采取各种符合这些项目管理白痴口味的回答。但是,作为项目管理的来说,项目管理的真正意义在于事先预防各种偏离项目目标的问题出现而不是在于解决问题。古话说得好"磨刀不误砍柴工"。你不能期望癌症有100%的治愈率,但是你可以通过合理的生活习惯和锻炼来防止癌症的出现。我们在进行项目管理时,首先应该考虑如何防止问题的出现,虽然它不能保证所有的问题(风险)都可以避免,但是通过计划,你将拥有更多问题(风险)应对储备,能够在问题出现时有备无患。一个只会在问题出现时考虑应对措施的项目经理只是一个失败的项目经理。其项目结果无异是把健康交给医生而不是自己。作为项目管理的定位来说,项目管理应该是"管理会计"的角色而不是"成本会计"的角色。

      最后,以某电影的台词来结束本文,人为什么犯病?简单的东西想复杂了,复杂的东西想简单了,人就会犯病"。拿这句台词来形容我们目前的项目管理状况一点也不为过。软件项目管理是一个从"自发"走向"自觉"的过程,也是一个从经验主义走向理性主义的过程。软件项目管理是一个主动的管理,而这一切,需要广大项目管理者的项目管理思维和积极实践。
  • 【转】软件项目管理原则谈

    2009-02-03 11:16:28

    软件开发的残酷的现实告诉我们:没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到:“拥有多年的丰富的项目管理经验”,但在实际开发中,“丰富的”管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工,她所谓的项目管理经验只不过是再一次的游戏于“无间”(十八层地狱)。一次,在与不少项目管理者的交流中,大家纷纷提到的软件变更带来的可怕影响。但是正如完整的法律体制不能制止犯罪,但没有完整的法律体制犯罪会更加猖獗一样,频繁的软件变更固然可怕,但是没有一个完整的项目管理对应机制,我们无法相像项目最终会是一个什么样子。此外还有一次,笔者在求职时,招聘公司的技术主管(40-50岁左右),向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。殊不知,我一问下面开发人员,她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计书,这让我大吃一惊。如此这样形式主义的公司,不呆也罢。
       记得一个格言曾经说过“人类最愚蠢的行为在于忘记常识”。另外一句较为相仿的格言则是“不知道历史的人必然会重蹈覆辙”。作为项目管理来说亦为同样的道理。很可惜,我们中的大多数管理者口口声声“软件工程”,工作时“用程序代替用户需求”,极具政客的嘴脸。其结果必然如目前媒体“程序员生存状况”所言,以开发人员在时间的牺牲为代价来换取项目的结束,这是再为普遍不过的现象,在此不再妄加评论。
       如何改善我们的软件开发管理,一条便捷之道便是“尊重常识,尊重历史经验教训”。在软件项目管理中,有许多的原则和经验可以供我们借鉴。
      一、 计划原则
        没有计划,你无从知道什么时候控制和变更。制定一个详尽的计划,以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划,你无从知道自己需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去,丝毫没有一个相关任务(活动)之间的说明。由于没有计划或是计划太粗糙、不切实际,很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务,项目就有可能宣告失败。试想一下,制定一个周密合理的计划需要耗费这么多的时间吗?需要付出项目失败的代价吗?还有很多项目管理人员常常错误认为“变化比计划快”,但实际的情况是,由于没有计划,你无法预测和估量变化给你的项目所带来影响,你所面临的将会是比面条还难以理清的“混沌”状态。此外,对于开发人员来说,“目标导向(Objective Oriented)”是充分调动其工作积极性的最佳方法,每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。因为近期目标总是比远期目标来说更容易看到和达到。为此,制定一个计划吧,让它符合目标导向(通过各个具体任务计划促使项目总计划的达成)。
      二、 Brooks原则
       向一个已经滞后的项目添加人员,可能会使项目更加滞后。因为作为新加入的员工来说,相关培训、环境熟悉和人员之间的沟通通路的增加,迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补,但加班造成的疲劳会再次使工作效率降低。同时工作成本却不断的向上攀升。不过就目前来说,项目管理人员丝毫不会理会这一点,“人多力量大”也许更能引人入胜。不少项目管理人员抱怨到时间的急迫性,须知很多项目内时间的急迫性来自于项目管理人员不假思索和不基于常理的邀功表现,没有充分考虑的开发人员能力的多样性所致。为此,正规的企业不得不耗费大量的加班费用于加班人员的津贴,同时亦要承担违反《劳动法》的潜在法律危险。现在一种万不得已的做法是,假设项目开发人员之间的任务的关联性不是太大的情况下,采取两班倒或是三班倒的方法来保证时间的延续性和相关开发人员的工作高效性。
      三、 验收标准原则
       我们在进行某项任务,往往会为以何种结果为宜而感到困惑。不求质量的开发人员往往凭据经验草草了事,追求完美的开发人员则在该项任务上耗费太多的精力,但此番耗费未必针对该项任务,因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有验收标准,你无法知道你要进行的任务需要一个什么样的结果,需要达到什么样的质量标准。在很多情况下,你的活动会与期望结果背道而驰,而此时的你还在沉醉于自己的辛勤耕耘之中。作为项目经理来说,只有制定好每个任务的验收标准,才能够严格把好每一个质量关、同时了解项目的进度情况。
      四、 默认无效原则
       你的项目成员理解和赞成项目的范围、目标和你所制定的项目策略吗?不少项目管理人员认为“沉默意味着同意”。实际上我们或多或少都会陷入这样的一个思维误区。试想一下,你作为职员或项目开发人员时的沉默完全代表你赞成你的领导的意见吗?不见得,这就是答案。这一点在项目沟通中极为重要,项目管理者切不可为沉默认为是同意,沉默在很大的程度上说明项目开发人员还尚未弄清楚项目的范围、任务和目标。为此项目管理者还需要同开发人员进行充分沟通,了解开发人员的想法。在对项目没有一个共同的一致的理解的前提下,一个团队是不可能成功的。
      五、 80-20原则
        80-20原则在软件开发和项目管理方面有许多“实例”。其一便是我们在20%的项目要求上耗费了80%的时间。仔细分析一下,这些项目要求分为必须的非必须的,因此我们建议是压缩非必须的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们,开发人员在非必须的项目要求上耗费了太多的精力,用户的需求变更的大部分出现在“最好有”这一部分,实际上用户并不看重这些需求(即使去除这些需求),而我们所做的,往往是舍本求末。
        80-20原则的另外一个实例是我们项目中的20%的人员担当了80%的项目任务(这样讲在实际实施中一点都不过分)。考虑到开发人员能力的多样性,聪明的项目管理人员决不会采取任务均分的愚蠢做法,因为就系统论的观点来看,互补结构比对等结构要更稳定一些。此外作为项目管理人员来说,了解属下员工的能力特点,将其放在合适的位置上,会更有利于项目的顺利进行。很多管理人员常常抱怨属下能力问题,究其实质,往往是这些项目管理人员未能发现开发人员潜能所在之处。她们看待问题往往以“经验”这样的思维定势来做决定。导致的结果如系统论所言:由于“抱怨”的作用和反作用循环,结果是大家都不欢而散。
      六、 帕金森原则
       帕金森原则原是用于反映政府部门机构臃肿,效率低下的代名词。不过它在软件开发中一样适用。没有时限限制的话,工作可能无限延期。在软件开发中,如果没有严格的时间限制,开发人员往往比较懈怠。这是人的天性所决定的。千万不要指望奇迹的发生――“所有员工的思想觉悟异常崇高”。作为项目管理者而言,此时应充分考虑到员工的工作效率和项目变更带来的负面影响,制定合理的项目工期并鼓动开发人员尽快完成。
      七、时间分配原则
        在项目计划编制过程中,我们常常将资源可用率(人、设备)等设置为100%,殊不知你曾想过,由于开发人员需要休息、吃饭、开会等,根本不可能把所有的时间放在项目开发工作上,而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓一天8小时工时制实际上是徒有虚名。由于项目管理人员的“无知”,不少开发人员被迫拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中,开发员工的时间利用率能够达到80%就已经时很不错的了,我个人比较倾向于60%左右(黄金分割点)。一个常用的经验是如果项目人员不懂技术的话,项目时间可能是原计划(该计划没有考虑到资源可用率)的4/3-5/3。如果项目人员不懂技术、管理人员不懂管理的话,这个数字可能是2倍到3倍。现实就是这么严酷。这很大范围内“归功于项目管理人员。是的,我们的确没有必要责备开发人员,因为我们对资源可用率的判断完全违反常识。
      八、变化原则
        也许有人问过你,在项目管理中唯一不变的东西是什么?我可以告诉你,项目中唯一不变的就是“变化”。在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时,我们的项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为项目管理人员来说,应该及早预测可能出现的风险,做好风险储备。虽然风险储备不能解决所有的问题,但是“预防胜于治疗”。可惜的是我们绝大多数人没有这方面的意识,否则医院的生意未必如此红火,项目开发之途未必如此坎坷。
      九、作业标准原则
           一个团队要完成项目的开发需要有一定的章法。很可惜,在国内目前仍然以“作坊式”为主,高举“我们符合国际CMM X规范(ISO某某规范)”的环境下,未必有多少项目团队注意到这一点。我们曾经惊叹印度的高中生都能编程序,而国内却非本科、硕士不收眼帘。究其原因,在于没有开发章法或是章法粗糙,犹如牛皮圣旨一般。一个好的代码模板和代码规范能够解决大多数人编写程序随心所欲的问题,很可惜,没有多少项目管理人员有此意识,也没有多少人愿意去做这项基础任务。业务软件开发需要高超的开发技巧吗?不需要,那是故弄玄虚的开发人员的伎俩。软件开发的美在于其简洁性和规范性,不在于奇技淫巧。因为缺乏作业标准,我们付出的代价是客户的抱怨和无休止的返工。此外,对于那些以形式主意蒙人的项目团队来说,如果你实质如同你口头所说那样,也许你就不会是今天的这副狼狈相。
      十、 复用和组织变革原则-解决项目问题的未来之路
       如何解决日益突出的项目工期、成本、质量等问题,这是大多数项目管理者最为关心的问题。从实践来看加强复用的力度,建立项目复用体系和实施组织变革是效果较好的途径之一。复用能够提高项目的生产率,降低项目风险。通过复用,项目管理者能够快速的进入项目问题定义之中,减少项目开发人员的工作量,从而尽可能的解决项目在时间、资源方面的过载问题。另外一条途径是实施项目团队的组织变革(Moc),精简项目管理机构、重新定义工作职责,制定柔性的项目工作流程,改善项目开发人员的沟通状况,提高项目人员的开发效率,努力营造一个良好的项目开发环境。这样才能从根本上解决项目开发的种种棘手问题。 
      
       结论:作为一个项目管理者来说,了解和运用上述原则是不够的,若要深入的掌握项目管理知识和技巧,还必须深入学习项目管理(建议参看PMI《PMBOK》)、管理心理学、质量管理学、组织变革、系统论等方面的知识,并在工作中不断的总结和实践。唯有如此,我们的项目管理人员看自己个人简历时方不会觉得脸红,才能在公司中树立自己的管理权威性,同样也才会有一个良好的职业经理生涯的开端。 
  • 【转】多项目管理

    2009-02-03 11:15:28

     多项目管理是站在企业层面对现行组织中所有的项目进行筛选、评估、计划、执行与控制的项目管理方式。与单个项目管理不同的是,单项目管理是在假定项目的资源得到保障的前提下进行的项目管理,思考角度采取"由因索果"的综合法方式。多项目管理则是在假定存在多个项目的前提下,如何协调和分配现有项目资源、获取最佳项目实施组合的管理过程,其思考角度一般采取"由果索因"的分析方式。

      作为一个软件企业来说,实施多项目管理具有非常重要的意义。首先作为一个软件企业来说,同时可能有多个软件项目在实施,这些项目之间在资金、时间、人力资源方面往往存在争夺关系,项目之间的这种关系往往导致公司资源的调配方面出现激烈地争执,恶化企业的政治环境,造成员工大量流失,所造成的间接损失更加突出。其次多项目管理的实施成功与否,直接影响企业的经济利益。企业的最终目的在于盈利,良好的多项目管理可以降低项目成本,

      优化企业资源配置,从而提高的企业的利润率。

      在实施多项目管理之前,我们有必要在众多项目中进行筛选,根据项目的成本、范围大小、项目利润率并结合公司自身的技术能力、专长筛选项目,切忌贪多求全,出现"一颗老鼠屎搅怀一锅汤"的情形。有关这方面的决策知识,可以参看管理会计方面的书籍。

      软件复用与管理组织变革(MOC)是达成多项目管理的一个有利途径,能够缓解多项目管理对资源的争夺,解决多项目在时间、资源方面的过载问题,同时亦能解决多项目沟通的效率。不过对于没有技术积累的软件公司来说,很难做到这一点。

      其次是利用时间差,在进行多项目管理中,尽量错开项目间在同一时间对资源和开发人员的争夺。让关键资源(多项目资源集合的交集)保持非过载状态。如果无法解决时间差问题时我们一般采取增加资源或确定项目资源优先使用级(短平快的项目具有较高优先使用权,但不能一直在整个项目阶段中独占资源)的途径来解决。不过对于大多数软件公司来说,前者一般不太可能,因为它增加了项目成本。后者作为下策虽然保证了成本,但不可避免地影响到项目的工期。实际场合中应在成本和时间中进行权衡。

      企业的多个软件项目间根据其相关程度,常常分为两种类型(更为详细的分类需要用到聚类分析):多个项目均与实施某一目标直接相关,这样的项目集合我们称之为"计划"(Program),其对应的管理方式成为计划管理(Program Management),计划管理的任务在于通过实现一些相互关联的目标来促成某一战略的达成。如果多个项目之间互不关联,这样的项目集合管理我们称为分组项目管理(Grouping Project For Management),分组项目不针对某一战略(目的)。

      对于计划型项目,我们可以采取类似单项目的管理方式,建立计划与项目的映射,计划中的各个子项目对应于单项目管理中的任务。通过映射方式来促成计划型项目的解决。

      分组项目管理的解决并无定法可言,一般我们通过遵循一些原则和管理决策来达成分组管理目标的实现。

      针对分组项目管理来说,在对项目进行分组时应遵循"相似性"原则,以减少和优化资源配置,这体现在:
    同组的项目所需的软件技术相似。技术相似有利于减少同组开发人员的培训成本,提高相关技术复用率,对多项目管理的效率具有很大的提高。例如,将.Net项目与Java项目分开管理。

      项目业务领域相似。仿上,相似的业务领域有利于经验的复用和管理效率的提高,比如将ERP、MRPII项目分在一组,而OA项目分在另外一组。

      优先级相同,同组的项目应该具有相同的重要度(重视程度),否则会导致重要度较低的项目无法得到必要资源得以完成(这与利用时间差中的确定项目资源优先使用级并不矛盾)。

      在实际的多项目管理活动中,更多的情况是项目经理(部门经理)根据项目的实际情况进行相应的项目资源占用取舍,这往往需要项目经理(部门经理)综合各种因素,确定这些因素的重要度来作出相应的决断。但是需要指出的是,解决资源(人、材、时间)问题才是解决多项目管理问题的关键。
  • 【转】代码走查表

    2009-02-03 11:14:27

    走查前准备
    1    得到一份解释代码的最新的设计文档       
    2    代码解释时使用了严格的警告和错误检查参数并被解释通过       
    3    代码使用带ISO标准的xxxx编译器进行解释   
    程序结构   
    4    所有代码的结构清晰,具有良好的结构外观和整齐
    5    所有的模块(函数和外部接口)定义清晰,模块分解清楚       
    6    所有的功能需求都明显的覆盖        
    7    高层设计独立于OS/环境        
    8    结构设计能够满足机能变更        
    9    代码体系结构描述了如何把代码重用到其他体系结构中        
    10    整个代码体系结构组合合理        
    11    所有主要的数据构造描述清楚,合理       
    12    模块中所有的数据结构都定义为局部的,并且通过定义好的函数进行访问        
    13    为外部定义了良好的函数接口        
    14    所有的接口模块化,因此修改时不影响其他代码模块        
    15    内存使用方法和内存管理策略描述清楚和正确        
    16    代码体系构架对空间和速度都已经进行考虑        
    17    提供了处理数据的策略        
    18    具有同一的错误处理策略        
    19    通过一套清晰的函数接口提供错误信息
    目录文件组织       
    20    所有的文件名符合文件命名规范,见名知意        
    21    文件和模块分组清晰        
    22    每个文件有文件头和标准的习惯一致(描述文件的用途,作者,对外提供的函数)23    每个文件都组织的有序 - 文件头,类型定义,原型,函数        
    24    所有的代码行在80字符以内        
    25    每个程序文件都小于2000行        
    26    每个文件只包含一个完整功能模块的代码
    函数组织       
    27    每个函数都有一个标准的函数头声明        
    28    函数组织:头,函数名,参数,函数体        
    29    函数定义符合ANSI或者用标准PERL的编译开关        
    30    每个函数都能够在最多2页纸可以打印       
    31    所有的变量声明每行只声明一个        
    32    所有的函数名都小于64个字符        
    33    每个函数之间都用2空行进行分开
    代码组织       
    34    每行代码都小于80字符        
    35    所有的变量名都小于32字符        
    36    所有的行每行最多只有一句代码或一个表达式        
    37    复杂的表达式具备可读性        
    38    续行缩进        
    39    括号在合适的位置        
    40    每个顺序的小块用空行隔开        
    41    注解和代码对齐或接续在代码之后    
    移植性   
    42    代码与操作系统无关,不需要任何假设条件
    函数       
    43    函数头清楚地描述函数和它的功能        
    44    代码中有相关注解        
    45    函数的名字清晰的定义了它的目标以及函数所做的事情       
    46    函数的功能清晰定义       
    47    函数中所有的部分都合理的组成函数,相关独立的语句组组成函数        
    48    函数高内聚 只做一件事情,并做好        
    49    函数和其他代码松耦合       
    50    参数遵循一个明显的顺序;        
    51    所有的参数都被使用       
    52    函数的参数接口关系清晰        
    53    如果一个函数有返回值,在所有的出口都有返回值        
    54    函数使用了最少数目的return语句        
    55    函数的参数个数小于7个       
    56    所有的假设和接口清楚        
    57    使用的算法说明清楚       
    58    函数检查了输入数据的合法性        
    59    函数异常处理清楚       
    60    函数设计已经考虑了将来的变化        
    61    调试信息存在于代码中并容易激活        
    62    代码检查调用函数的返回值,参数和调用匹配       
    63    函数确保了没有影响函数外代码       
    64    递归定义了出口        
    65    递归局限于一个函数        
    66    堆栈大小支持递归调用的深度
    数据类型与变量       
    67    数据类型存在数据类型解释        
    68    代码为每种可能改变数据类型的数据使用一个不同的类型        
    69    代码避免了重新定义预先定义的数据类型        
    70    数据结构简单以便降低复杂性       
    71    每一种变量分配了正确的长度、类型和存储空间        
    72    静态变量明确区分        
    73    所有的声明与编译器或具体的机器长度无关        
    74    每一个变量都初始化了        
    75    每一个变量都在接近使用它的地方才初始化        
    76    每一个变量都在将要使用它的时候才初始化       
    77    变量的命名完全、明确的描述了该变量代表什么        
    78    命名和现实生活中的事务接近而不仅仅是一个程序类型        
    79    同一种类型或指针命名的前缀指出类型或指针        
    80    命名不与标准库中的命名相冲突        
    81    程序没有使用特别的、易误解的、发音相似的命名        
    82    所有的变量都有最小的活动范围        
    83    所有的全局变量都描述清楚        
    84    使用函数访问取代全局数据的访问        
    85    所有的变量都用到了       
    86    存取数据的程序与全局数据的用法是兼容的        
    87    变量按照它的命名用途进行使用    
    特殊   
    88    所有的数组访问在它们的边界内        
    89    代码已经处理了-1错误        
    90    代码处理了指针异常        
    91    所有常量定义和使用替代代码中的数字        
    92    类型转换明确指明
    其他注意项       
    93    代码与比较,计算变量的大小无关        
    94    代码与操作符的优先级无关        
    95    所有的表达式使用了正确的操作符   
    条件判断   
    96    条件检查和结果在代码中清晰        
    97    If/else 使用正确       
    98    普通的情况在if下处理而不是else        
    99    判断的次数降到最小        
    100    判断的次数不大于6次,无嵌套的if链        
    101    数字,字符,指针和0/NULL/FLSE 判断明确        
    102    boolen表达式表示清楚       
    103    最常用的情况最先判断        
    104    所有的情况都考虑       
    105    判断体足够短,以使得一次可以看清楚        
    106    嵌套层次小于3次
    循环       
    107    循环体不为空        
    108    循环之前做好初始化代码        
    109    循环体能够一次看清楚        
    110    当有明确的多次循环操作,使用For循环       
    111    当有不明确的多次循环操作,while循环被使用        
    112    代码中不存在无穷次循环        
    113    循环的头部进行循环控制        
    114    循环索引具有有意义的命名        
    115    循环设计得很好它,只干一件事情        
    116    循环终止的条件清晰        
    117    循环体内的循环变量起到指示作用        
    118    循环嵌套的次数小于3次    
    输入输出   
    119    所有文件的属性描述清楚        
    120    所有OPEN/CREATE调用描述清楚        
    121    文件结束的条件进行检查        
    122    显示的文本无拼写和语法错误
    注释       
    123    有一个简单的说明,用于描述代码的结构        
    124    每个文件和模块均以给予解释        
    125    源代码能够自我解释        
    126    每个人看到代码就能很快理解        
    127    解释说明代码功能,准确描述代码意义       
    128    解释不过于简单        
    129    注解清楚正确        
    130    注解为用户服务        
    131    所有的假设和限制进行注解        
    132    长的控制体结束,进行注解
    总括       
    133    代码直观        
    134    代码中的用语符合广告用语,而不是技术化的描述        
    135    代码和设计文档对应        
    136    无用的代码已经删除       
    137    无用的注解已经删除 
  • 【转】数据库设计走查表

    2009-02-03 11:13:28

    前期准备
        1    概念层次的ER图和数据库定义书准备齐全           
        2    ER图关联简洁           
        3    ER图结构清晰           
        4    ER图实体个数适中           
        5    ER图无重复冗余           
        6    存在原有系统的情况下,对旧系统的数据库进行了整理,本次设计中保留原有数据库的设计优点           
        7    存在原有系统的情况下,注意原有数据库系统中一些忽略的问题           
        8    存在原有系统的情况下,进行了数据库方面的设计对比           
        9    设计采用了CASE工具           
        10    数据字典完备           
        11    设计时考虑了将来哪些数据字段可能会发生变更           
        12    设计时考虑了不同国家,地区可能存在的字段和字段格式           
        13    设计时考虑了数据库的版本标识           
        14    设计时考虑了将来的数据挖掘和分析需求           
        15    使用英文而不是其它语言,编码来作为设计语言           
        16    存在一数据库标识机制来反映数据库的当前版本和相关配置信息           
        17    数据库设计时考虑到了备份的安全机制           
        18    数据库设计时尽量不考虑取值CHECK,有关CHECK的东西通过页面输入检查来解决   
    表设计   
        19    实体有主键或有外键,或二者兼备           
        20    多对多关系被映射为三张基本表           
        21    基本表的字段不能再分解           
        22    基本表的数据均来自于用户人工输入或系统设定           
        23    基本表结构稳定,短期之内不再变化           
        24    基本表尽量满足3范式,符合2范式           
        25    根据用户统计,时间统计等统计需求建立中间表           
        26    临时表是临时的           
        27    表个数足够精简(多字段分表情况例外)           
        28    对于多值字段采用了创建子表的做法或预留了足够的字段来存储不同的值           
        29    表中存在合理的派生性冗余字段或无冗余字段           
        30    表中字段足够精简,不存在重复性冗余字段           
        31    有多种权限设计的时候采用用户-权限设计方式           
        32    表设计包括了管理员(用户)的账号管理设计   
    数据库   
        33    数据库命名使用小写英语字母, 数字和下划线,无其他字符       
        34    数据库命名长度小于20位       
        35    数据库命名采用项目名或产品名称命名       
        36    数据库中的所有表字符集统一       
        37    数据库中对象命名见名知意       
        38    数据库对象的命名不使用保留关键字       
        39    数据库设计考虑到了事务机制       
        40    数据库设计考虑到将来可能存在的异种数据库迁移       
        41    数据库设计时考虑到了审计追踪机制(警告等)
    表   
            42    组合主键的字段数量不超过3个   
        43    采用了系统自增字段作为主键   
        44    不同表的同一意义的字段名称和类型一致(特别是外键场合)   
        45    为关联字段创建外键   
        46    所有键取值唯一   
        47    外键是关联唯一的字段   
        48    使用商务规则约束数据完整性   
        49    表的id字段和name字段命名时采用表名_id(name)的形式   
        50    不存在只有写入没有读取的表   
        51    不用可能被更新或经常更新的字段作为主键   
        52    表设计不存在级联性删除   
    字段   
        53    字段与画面项目能够一一对应(部分标识符字段和系统设定字段除外)           
        54    索引是多值字段           
        55    索引是单一字段           
        56    字段取值符合域定义           
        57    字段名称见名知意           
        58    多个表中出现同一类型字段用表前缀来标识           
        59    字段的类型和长度能够满足字段的值的最大限量           
        60    文本字段有充足的余量对应可能的长度变更           
        61    数字字段考虑了充足的余量和精度对应可能的长度或精度变更           
        62    不给MEMO(Mysql TEXT类型)之类的大字段建索引           
        63    为每种查询都建立索引           
        64    加一个标识更新时间的Datetime字段update_time,不使用mySQL 的timestamp类型。           
        65    加入一个表示记录插入时间的时间字段create_time, datetime           
        66    布尔值一律为INTERGER类型           
        67    有小数的字段使用Integer, 而不用float 等字段           
        68     普通时间字段使用Integer 或者Datetime           
        69     如果报表中可能分别按年,月,日进行排序和分组。则把时间字段分成不同的年月日字段           
        70    支持多国, 则数据库中必须存格林威治时间           
        71    不需要区别NULL和空字符串的地方,数据表设计时标上NOT NUL           
        72    用程序逻辑控制Default值, 而不是让数据库控制默认值           
        73    表中采用了DEL_FLAG字段标明删除           
        74    表中采用了IS_VALID(CANCEL_FLAG)标明有效性           
        75    采用了存放路径而不是存放图片(文件)本身的方式来保存图片数据或文件数据           
        76    Password只存单向加密过的密码, 而不是密码本身
    "存储过程-视图-触发器"
            77    针对客户的特定应用采用了视图机制           
        78    采用了常规的存储过程来替代和简化客户程序代码的开发           
        79    少用触发器,多用存储过程           
        80    缺乏约束的数据库系统中,采用了触发器用来加强参照和数据完整性
    优化   
        81    计算复杂时,以文件形式处理后才追加至数据库中而不是在数据库中直接计算           
        82    表记录字段太多时,采用垂直分割(超过80个以上)           
        83    表记录太多时,采用水平分割(分表)           
        84    SQL语句符合“先投影后连接再更新”的优化规则           
        85    所有SQL语句都充分地得到优化           
        86    数据库管理系统参数均得以优化           
        87    支持数据库的硬件指标符合项目需求           
        88    优化设计过程中考虑了“程序优化”,“数据库优化”和“系统优化”三个层次的优化           
        89    分布式数据库设计时充分考虑了80-20规则           
        90    XXXX数据库时使用XXXXX作为数据库引擎       
  • 【转】软件过程改进的人文途径(SEPG 2007 China 演讲稿)

    2009-02-03 11:11:51

    诸位朋友,嘉宾:

        在开始演讲前给大家讲一个寓言,也算是一个笑话。寓言是这样的,

        在一架飞机上,乌鸦对乘务员小姐说:“小妞,给爷来杯水!坐在旁边的猪听后也学道:“小妞,给爷也来杯水!”,乘务员小姐把猪和乌鸦领子一提,扔到机舱外。乌鸦拍拍翅膀,笑着对猪说:“你还真是猪头啊,傻了吧?爷会飞!”。

        这个寓言告诉我们,外界因素是一种约束条件,自身能力也是一种约束条件。所以,别人能成功的事,未必自己就能成功。

        对于CMM/CMMI和过程改进来说,我们有些企业扮演的是乌鸦的角色,也有不少的企业扮演的是猪的角色。今天我们的主题就是关于从猪的角色转变为乌鸦的角色的一些人文方面的途径。

    首先,让我们来看看目前很多企业在实施CMM/CMMI方面的问题。

        (1)实施成本高,不少公司在实施后走向玩命生涯。大家去查查国内第一家过CMM和第一家过双五的企业,看看他们现在的一个境况如何。我想你们比我更清楚。我的意思不是说实施CMM/CMMI企业就会败落,有不少企业,包括这次来的很多嘉宾所在的企业,他们的企业在实施CMM/CMMI后业务反而做得很好,为什么,有一点是值得注意的,成本问题。试想一个二三十个人的小公司去实施CMM/CMMI,你们算算多少费用,这样的小公司有多少资金可用。没等实施完,早弹尽粮绝了。所以,没半斤的肚子,就不要吃八两馒头,免得气胀和消化不良。

        (2)形式主义加教条主义,我称之为“双症教育”,国内通过CMM/CMMI的企业,实施时靠个“GOLDEN PROJECT”的模板项目骗CMM/CMMI认证的公司多的是,我的先前曾经呆过的一家公司在过CMM 4认证的时候,评估师居然在验收时,面对测试团队,居然没有提一个问题。难道真得没有问题了么。做事讲究的是一个态度,做人讲究的是一个“德”字,很多认证在国内被做烂掉的一个原因就是个“形式主义”。形式主义缺什么,甲方缺做事的态度,乙方缺德。相比形式主义来讲,教条主义也好不到哪里去,一个公司的制度太过于教条,整个公司就会死气沉沉,缺乏活力。关于教条主义的来源,我将在后面给大家讲述。

        (3)第三条,我们称之为偏见,这是技术人员出身的人常常犯的错误。我也常常犯这种类型的错误。记住“软件行业无一包治百病,立竿见影,药到病除的狗皮膏药体系和方法。”我是学中药出身的,中药里基本上没有只用一味药的,只有调和各个药的作用,才能发挥最大的药效。一个企业的质量问题同样地,不是仅仅关注于过程就能达到的,过程是人做的,有缺德的人和高尚的人,有先进的技术手段和落后的人工手段的,自然会有过程改进的效果不同。不然的话,为什么不去找个文盲来做过程改进。所以,我们在实施CMM/CMMI的时候,不要以偏概全。只重分析,不重综合。过程、人、技术,软件过程三要素,缺一不可。

        (4)目前的很多咨询师在CMM/CMMI方面,仍然轻视人在软件开发中的核心作用,以为有了机制,对人的要求反而不是太重要。机制在一定基础上可以降低对人员素质的要求,但不是没有要求。在座的嘉宾们有很多是名企,一样过CMM/CMMI认证,你看看他们的人材招聘要求,不但不低,而且很高。为什么,人是软件行业赖以生存之本。所以不要把人当机器,机器是没有思想和创造力的,人有思想,有创造力。这就是各位为什么生气勃勃的在这里参加大会的原因,因为我们都是有思想,有创造力的新人类。

        我们接下来谈谈过程改进咨询和实践中遇到的最为常见的问题。这些问题目前是目前的过程改进流程中做不到的一些方面。

         (1)执行力不足

        过程改进强调给管理者、实施人员足够的权限,讲求“授权”二字。很不幸的是,尽管有了授权,相关的过程改进实施执行方面仍旧是拖拖拉拉,大家都在磨时间。这个结症往往出在项目组长和项目经理方面,有法不依。我先前的一家公司的老板,为了这个问题,解雇了所有的中层管理人员,其结果大家可向而知,公司去年倒闭了。可以说,执行力低下这个现象不单是实施过程改进的企业,基本上所有行业都会有这个问题。殡仪行业也许是个例外,所以我们要高歌一曲“学习殡葬好榜样,高效快速执行力强”。至于执行力不足的原因,我在后面的激励机制中将有所阐述。

         (2)软件质量仍然达不到要求

        我们都知道,软件质量的源头是需求,软件质量的关键是过程。但是,就目前来说,过程改进的一大不足就在于没有真正深入到质量的源头,没有参与到客户价值过程中去。我见过很多公司SEPG成员参与到软件开发的洪流中,热火朝天。但是很少看到SEPG的人员陪同开发人员、市场人员和客户进行业务沟通。或是审查过业务销售的报告和需求单据。往往就是这不经意的一步,对后续的需求质量乃至业务的获取影响至远。

         (3)流程过于形式化,重数据而不重本质

    我看到这次一个嘉宾的文章,有关标杆数据的,写得非常好,非常有借鉴性。但是在实施过程中,我讲了,人的态度决定一切。最主要的在于数据采集的主观意志太强。这是因为,就软件质量属性来说,有的东西只能定性,比如代码风格好坏,精炼程度,文档正确性和书写的优美性,很多都是模糊的,比较难以数量化,这些模糊的东西不是不可以量化,而是量化所需的成本太高或是算法太复杂。这好比“多少根头发的人算秃头一样,多一根少一根会影响评定结果吗”一样,我们只要给个定性的结论就可以了,但是在标杆数据里,定性的东西却没法处理,我们的SEPG组织总是吹毛求疵的追求最终的数据结果,最后才发觉自己没事瞎白活。此外,很多公司的过程改进中,强调文档的数量而忽略质量,重文档形式而忽略其实质内容。结果是过程改进好像没有给软件质量带来提升。这不是过程改进的错,如木桶理论所言,要达到质量的提升,过程改进有必要在木桶的短板上做足十分的功夫。

     引起上述情况的根本根源,我们认为这在于东西方的文化冲突,主要体现在“人治”和“法制”的均衡上。

        (1) CMM/CMMI的核心思想

        CMM/CMMI的核心思想为三权分立,我们的CMM/CMMI创始人可是标准的孟德斯鸠的门徒。

        我们现阶段的司法体系也如此,可以说,我们可以把CMM/CMMI模型当作公司项目开发的小的司法系统,联想一下中国社会上的司法种种现象,你就不难想像我们的小司法系统也会出现哪些同样问题。

        过程改进体现的是“三权分立”的思想,强调的是职责明确和授权,但是中国企业现实中更多的是要如何解决“秃头人问题”。这是因为西方人求真,东方人务实。 胡适先生讲过,“多解决些问题,少谈些主义”,在这里也是同样适用的,过程改进不能只是空谈,而是要反应到企业具体的实际问题中去。


        此外,从CMM和CMMI的“三权分离”(制度化)理念和持续改进(完美主义)来看,往往忽略了人在软件质量中的核心作用和企业环境对CMM/CMMI的支持作用。这是西方人和东方人不太的地方,西方人考虑问题时,往往将主题对象从环境中剥离,而东方人的思维里,常常考虑的是主题对象和环境的交互作用。既然思维方式不同,所以行为方式自然也不同。

         (2)CMM/CMMI的初衷

        CMM/CMMI的初衷是为了提高软件开发的质量和效率。但是大企业的效率和小企业的效率问题的本源不是一样的。

        大企业的效率问题来至于制度的盘根错节,是制度与制度间冲突的效率问题。

        小企业的效率问题来自于毫无章法带来的效率低下,与大企业有本质差别。

        一个需要“化零为整”,另外一个需要“从无到有”。

        制度设计的理念体现为“公平、高效”四个字,对于大企业来说,更兼顾于“公平”、而小企业来说,更兼顾于“效率’。所以我们在实施过程改进时,首先应该考虑到企业的一个规模因素。

     

        在实施过程改进的人文途径方面,首先我们要树立以下一些思想,对我们理解过程改进的人文途径至关重要。

       1.不要一来就叫嚣改变企业文化,过程改进只有适应企业文化环境才能有发展。

        一个企业文化是企业经过长期的进化、演变而积累的东西,是一个企业精神价值的所在。不是靠开开会,给公司领导洗洗脑就能够改变的。过程改进不能违背企业的基本价值观。过程改进只有审时度势,在公司大环境允许的条件下进行适当的改良,以适应公司的基本环境,然后才能谈改变。因为没有人喜欢变,因为变化很多情况下意味着原有积累的丧失和风险,除非新产生的价值能够弥补已有的沉淀成本。反过来,过程改进只有发展了才能改变企业文化,以一种循序渐进的方式,不断的对企业文化进行改良,但企业的基本价值观是不能动摇的。在很多方面,客户利益是放在第一位,因此在项目开发中会出现不按过程改进原有措施做的实例。一个紧急的单子或是问题,可能是先做后补单。如果什么都按既定步骤,医院死人人数不知要翻几番。企业就会流单子,流单子老板要骂人,最后就是将“制度奴隶”扫地出门。

        2.过程改进与客户利益的关系

        企业是目标是生存和盈利,而不是过程和制度。但制度和过程可以影响企业的生存和盈利。先进的理念如果不能给公司带来真正的效益,那么说明理念本身的适应性有问题。对于过程改进来说也是同样的道理,过程改进如果不能给公司带来真正的效益,那么说明过程改进这个理念本身适应性有问题。因此,除开发过程中需要导入过程改进机制外,客户价值过程中也应该导入过程改进。通过客户价值过程改进、赢取合格的客户需求,比事后进行过程控制要好的多。需要提醒的是,过程改进在客户价值流程方面要力求务实,而不是新的教条主义。

        3.过程改进要协调好利益干系人的利益关系

        为什么过程改进在具体的实施中会有太多的阻力?下面给出一些项目经理和开发人员给出的推卸之辞:

            1.过程改进没有按项目大小和紧张程度进行剪裁

            2.过程改进总是太过于公平,忽略效率

            3.我从过程改进中没有获得任何好处,工作量倒是增加不少

            4.给我一个式样模板对于我来说更为急需,过程这种看不到的东西就算了

            等等

        与其大谈过程改进要改变人的思想,不如事先分析一下相关干系人的利益情况,这样你就会知道,谁在过程改进中支持你,谁在过程改进中反对你,以及如何有的放矢的应对。项目管理中的一个核心不也是项目干系人分析,过程改进适合同样的情况。

        为什么?因为人的本性都是趋利的。毫不利己,专门利人,你们当中有多少人能做到。每个过程改进所影响到人员在企业内都有自己的利益和自己团队的利益,如果你的过程改进损害到这些人的利益或给他们造成麻烦,谁来支持你。这里面就涉及到一个利益均衡的问题,这点在中国企业制度的建设中非常重要。其实在国外企业,也是同样的重要。不过外国人不会告诉你,他们也有“面子文化”。

     过程改进有哪些人文途径,我简单的讲述一下自己的一些体会:

        (1)在过程改进中将授权机制变为激励机制

        没有激励,仅仅只有“授权”是完全不够的。传统的过程改进总是强调授权而忽略激励,根据制度经济学的论断,制度的接纳的最优途径是激励,而不是授权。激励可以激发过程改进人员、项目管理者、底层开发员工的积极性。权益,权益,为什么项目管理层在授权后老是拖拖拉拉或者是阳奉阴违,因为他们只有权,没有益。换个角度思考,你会不会去做一件跟你完全毫无利益的事情。最简单的例子,就是包产到户,包干到户。一个没有激励只有授权的团队意味着团队的人员只有责任,没有权利。而从人的本性的黑暗面来说,人是风险规避的,也就是责任逃避的。

        激励机制可以有很多做法,最简单的就是绩效公示,不过这种做法会太过于打击新手,因此可以采取一些隐性的激励手段,比如项目提成和团队补贴或是精神激励等。如我前面所说,没有一种方法能够单一取得最优效果,因此在实施过程中要结合使用。对于惩罚,没必要公示,中国的技术人员最爱面子,以教育为主。如果实在是“朽木不可雕”,就扫地出门,扔掉把。


        (2)取消无限、持续的过程改进说法,讲究适可而止,阶段性提升

        无限、持续过程改进体现了我们这些技术出身人员最大的一个人性缺点,同时也是人性的优点之一,追求完美,没有最好,只有更好。但是从企业成本和过程改进成本来说,未必就值得。为什么?我举考试的例子,大家考60分需要复习一个小时,从60分到70分肯定不止一个小时,70到80分呢,80到90分呢,100分就更不要说,投入的精力和时间太大,而且稍微闪失就不能达到。过程改进也是一样的。如同经济学边际递减规律所提到的,如果过程改进的投入要素连续地等量增加,增加到一定值后,所提供的过程效果的增量就会下降。追求完美是没错,但是要考虑过程改进的成本,企业的预算是有限度的。这是其一,此外,项目的过程改进也得有个适应期,每个项目都要在前面一个项目上持续地改进,项目开发人员只能愈来愈抵制。因为他们在还没完全适应的基础上又得匆匆忙忙去适应下一个项目的新过程。一个字“累”。

         (3)尊重80-20规律,精英意识与平民意识并举 
        我跟一个CMM/CMMI的咨询师曾争论过这个问题,他跟我讲,你一味强调人,你还没领略CMM/CMM的思想。什么思想,我称之为“民工思想”,在他看来,通过先进的制度和理念可以去除人带来的影响。没错,任何先进的管理制度都在解决这个问题,但是很不幸,人的能力是有差异的。制度要解决的是人的劣根性,激发人的善性,我们的软件开发不是体力劳动,而是有创造性的劳动。我们的管理层都是团队精英,在很多公司,我收到他们对过程改进的一些反馈:

        为什么管理层人员和技术强人大多抵制过程改进?

            1.  增加工作量

            2.  太过于教条,不考虑特殊情况和紧急情况

            3.  职责变多,无法“踢皮球”

            4.  个人作用不再受重视

            5.  管理成本增加

        你们可以看到,大家都是“唯利主义者”。大家之所以在你们现在的岗位上,是因为你们相对与其他岗位的人员有着相对的“性价比”优势,如果一个制度能抵消掉这方面的优势,那这个岗位没你做也没关系,既然有没有你都无所谓了,你的生存价值何在,你不抵制这个制度才怪。所以,有时候制度需要一点人性化的东西在里面。我前面说过,有很多是名企,一样过CMM/CMMI认证,你看看他们的人材招聘要求,不但不低,而且很高。高素质的人材是潜力股,潜力股要看未来,就个人行为来说,短视者居多,对于企业来说,不能吃了上顿没下顿,潜力股是企业未来保证。

             (3)将客户价值的商业流程纳入到过程改进中来

        为什么过程改进在企业内部不受重视,不被人理解。没有把客户价值创造的流程包括在过程改进中是一个主要的原因。我们进行过程改进时,不要只考虑公司内部的过程改进,尽可能的把价值链上所牵涉的业务对象也加入流程。软件质量低下跟没有将客户价值的商业流程纳入到过程改进中也有关系。客户的需求是软件质量的本源,单靠我们自身能力不足以 完美无缺,需要客户参与到过程改进中来。否则,你无法预知需求获取之前的东西和需求的质量。实际上很多企业的销售工程师和系统分析师都需要过程人员的协助,包括客户。我们的客户经常会问,你们那边的商务流程是怎么样的,需求流程是怎么样的。过程改进在此时就体现了了它的重要性和必要性。换个角度来说,将客户价值的商业流程纳入到过程改进中来,还可以改变过程改进的“成本中心”形象,由于过程改进参与到企业利润源头的工作中来,往往会获得更多公司内支持。

     

    (4)过程制度建立和完善要依据分工规模

        如何剪裁和划分过程制度的颗粒度,这是最为企业过程人员头痛的事情之一。我们从经济学的分工理论上来看,过程制度建立和完善要依据分工规模。

        制度划分理论是这样的:

        制度划分的力度取决于组织的容量。

        同样过程改进的剪裁和力度划分需要按照团队和项目大小来进行调整。分析与项目目标相关的领域的相关性。比如较为低层次的对日外包项目,过程改进活动一般着眼于代码审查和测试复核。而对于产品开发来讲,过程改进关注的中心往往是首尾,一个市场需求的式样化,一个是市场反馈系统完善过程。

        还有一点要提醒的是,交易费用理论对我们也有十足的借鉴性:

        随着组织规模增加,交易成本将越来越大。

        因此对于大项目来说,如何对沟通方面的改进会变得攸关重要。过程改进的实施的效果将取决于沟通的流畅性。

        我们可以总结为:

        大企业、大团队、大项目,过程改进的重点在于沟通的流畅性。

        小企业、小团队、小项目,过程改进的重点在于过程颗粒度的划分。


        (4)构建成熟的人力资源成熟度模型

        为什么我们要引入人力资源成熟度?1.

            1.我们确保合适的人在合适的职责岗位上,才能获得最大的工作效果。

            2.过程是要靠人来抓住,人来管理,不是制度摆在那里就算完成了。

            3.进行诸如软件开发这样的脑力劳动需要高素质人员

        过程改进实践往往忽略环境和上下文,有的过程改进甚至需要由顶级专家构成的团队才能施行。没有合格的员工开发不出合格的软件,没有合理的制度,创造不出高绩效。因此,过程改进中,不可缺少人力资源的支持。这跟CMM/CMMI的开展过程教育的宗旨有一定的重合空间,是不违背的CMM/CMMI的“洗脑战术”理念的。


    (5)构建合理、公平的劳资、福利体系,并与过程改进相挂钩

        过程改进要能顺利实施,离不开公司的福利制度。任何一个企业里,没有人会跟钱过不去,但会跟过程改进过不去。将过程改进和员工的福利劳资挂钩,会从很大方面加速过程改进的力度和提高过程改进的效果。当然人是IT企业的立身之本,过程改进需要优秀的人材参与,有些CMM/CMMI企业,自身福利薪资太差,就算你现在过了CMM/CMMI,你又能好到哪里去。近期的钱你是赚足了,但是远期呢。大家有空可以去看看IT红黑榜,看看我们的CMM/CMMI企业有多少在黑榜上,然后预测一下企业存活期。实际上,你们不用预测,你看看这些公司的效益值,就不难发现,口碑差的企业大部分还真是举步维艰。

     (6)以经济效益为考核杠杆,通过过程改进提升企业效益

        经济效益是企业生存的指标,任何企业的制度,理念,无一不是以合法合理的经济效益为最终目的。要获取企业高层领导及管理层(我这里指的是有心搞好CMM/CMMI,过程改进的企业领导,不是为了骗国家资助,玩形式主义的领导)的大力支持, 首先要灌输过程改进的 “节钱”观念。其次,过程改进的最终目的还是通过提高软件质量从而提升企业的经济效益。如果一个过程改进对企业效益没有任何作用,这样的过程改进不可能长久,也没有存在的必要。我的经验是,分析过程改进中流程与效益的相关性,扶正去负。经过一段时间的过程改进适应后,会做相关的效益评估报告。这样的做法可以去除公司员工对SEPG的成本中心看法,获得公司整个上下文环境的支持。从另外一个侧面讲,让SEPG人员和QA人员知道自己所做的贡献值,增强对过程改进的信心,做出更为出色的成果。

         过程改进的人文途径总结:用生态学观点看过程改进,创造和谐的人文环境

        我们把企业当作是一个生态系统,过程改进犹如人之进化。进化的本意是先适应后改变,现在到处都在提倡和谐,过程改进也一样,我们考虑过程改进的时候不单单只从过程改进本身出发,更重要的是,联系上下文环境,尊重员工。只有为过程改进创造一个和谐的人文环境,才能够做好过程改进。

        我的演讲到此为止,谢谢大家。

Open Toolbar