技术开发 频道

Morning对Leo的采访

    [M] 你在前面提到的项目管理部是一个什么样的机构?  
 
    [L] 项目管理部就是公司的一个专门讨债的部门,整天追着项目经理要文档:)。其实怎么说呢,他们就是负责监控项目的整个流程,特别是现在要做CMM,更是需要项目管理部。因为SQA,SCM等都是贯穿整个项目始终的,而且还起着比较重要的作用(有关SQA,SCM的问题请见后)。因此项目管理部的工作显得比以前更为重要。而且我们以前项目的源码、文档等都在项目管理部有备份,自己如果不小心丢了,还可以找项目管理部要,如果他们也丢了,责任就大了。总之项目管理部就是监督项目的流程,控制项目的质量,而且像需求变更等都需要项目管理部的参与。
 
    [M] 是否可以认为,项目管理部是在项目队伍不够成熟的前提下才产生的,它既起主导作用,也有辅佐作用,并且该部,对公司的所有项目组统一负责?
 
    [L] 项目管理部的主要的工作就是跟踪,管理所有项目的整个流程。特别在CMM中,我觉得它存在的必要性就更大了。其实它不应该说成在项目队伍不够成熟的前提下产生的,或许应该说成随着项目队伍的成熟,随着公司的规范,它可能要发挥越来越重要的作用了。

    [M] 为什么你认为项目管理部随着项目队伍的成熟,随着公司的规范,可能会发挥越来越重要的作用呢?
 
    [L] 我感觉随着公司的规范操作,项目过程中的各种问题、流程、以及解决方案,都会得到很好的积累。积累的结果不可能局限于某个项目组,某个项目成员。也就是说不可能是某个人具有这种积累,而应该是公司具有这种积累。公司就需要把这种经验总结下来,保存下来,项目管理部正好可以起到这种作用。既总结项目经验,又监督项目的执行,还提供一些经验促使项目少走弯路。在CMM中,项目的各种操作有严格的定义,项目经理可能不是很成熟,或者没有足够的时间来应付各种各样的工作。此时如果派其他的项目经理来监督可能效果不是很好,因此项目管理部就可以派人员进入到项目组,在项目的特定阶段监督项目的执行。
 
    [M] 对review程序员的代码和工作,你一般是如何做的?
 
    [L] 迄今为止,我还没有真正的单独带领一个团队工作过。在我们刚刚结束的项目中,我名义上是项目经理,但是因为还有一个owner,因此我大部分的精力就是coding,然后就是帮助项目组成员解决技术问题,当然某些项目经理的工作我还是稍微接触了一下。因此对于项目模块功能的review,对于代码的review,我都没有做,因为我自己的coding任务太艰巨了。不过如果真的是我,我想首先项目经理应该按照项目计划每天检查项目成员对于功能模块的完成情况,这是项目经理最基本的工作。你必须检查项目成员的进度,适当的调整项目计划。然后在项目时间不是很紧的情况下要review程序员的coding,因为虽然程序员把功能实现了,但是代码可能隐藏着很大的隐患。适当的培养程序员的编码规范意识,这样对于程序员个人,还是公司都是一个很好的积累。
   
    在我们公司曾经有一个项目经理每天要两次调整项目计划,他带项目真的是很认真,很有一套经验的。我们公司还有一个team,当项目经理review某个程序员的代码时发现一个页面中竟然使用了10个以上的recordset(记录集),这种代码的质量太让人难以接受,虽然功能实现了,但是隐患呢?很危险。因此项目经理很生气的把该程序员训斥了一通。
 
    [M] 你是否认为,对需求的正确理解将直接影响项目开发的后续工作。实际情况,往往是用户自身对需求的认识也并非总是清楚的和一尘不变的,对此,你怎么看呢?
 
    [L] 对需求的理解肯定会影响项目开发的后续工作。因此在市场前期对销售人员,以及对参与需求调研的人员的能力,就有比较高的要求。他们要准确把握用户的需求而且要挖掘用户的隐含需求,特别是对于用户自身对需求也认识不清的情况,更需要前期的人员有很高的能力。用户需求不确定是一个不可避免的问题。在任何项目中,这种问题都会出现,所以我们公司对于需求变更,一定比例之内是无条件更改的,对于超过比例的就需要收费了。在需求调研阶段,我们往往是做demo,要求用户确认。通过demo,用户的要求和我们的理解就能比较好的达成一致。
 
    [M] 需求变更超过比例的需要收费,则公司无形中承诺了这种变更将不会使项目出现问题,这一点团队成员上下都需要保证的,那么,如何保证呢?有没有反例呢?
 
    [L] 其实任何公司都不会允许客户无休止的更改需求,因此需要采取某种手段来制约客户的需求更改,我想收费的目的也就在于此吧。至于目的是否能够达到,效果如何,最终是否把需求变更的钱收回来是具体另一回事了。
 
    [M] 我想知道在你所在的公司,在项目开发过程中,是否存在由于需求变更的程度很大,而导致项目形势很糟糕这样的现象,或者由于采取适当措施而“化险为夷”的事例?
 
    [L] 由于需求的变更导致项目的问题我倒是不太敢确定,不过我曾经接触的项目中由于客户的不成熟,或者说双方对需求的理解不够导致项目验收拖延的事情确实存在。
 
    [CMM]
 
    [M] 你在项目中采用CMM管理有多长时间了?对CMM的印象如何?从开始接触到目前为止对其认识是否有变化呢?
 
    [L] 对于CMM整套体系我还不是很熟悉,而且我们公司在做CMM的规范时我的项目正紧,因此也没有时间参与其中。总的来说,我们公司是在最近刚刚启动的几个项目中采用CMM管理的,我手头的这个项目还没有正式开始,我估计正式开始后也会采用CMM管理。所以我从未使用CMM管理过项目。对CMM总的印象就是项目过程文档化,一个项目结束可能需要产生40、50个文档,而且这种管理模式对于比较大的项目应该是很有用的,但是对于小项目好像用不上,但是我想或许应该从小项目来实践吧。
 
    [M] 在前面的谈话中,你曾提到“CMM中强调大家的整体参与”,从实际角度出发,你是如何理解这一点的?在公司规模不同的情况下,这种“强调”又是如何具体体现的?
 
    [L] 或许在CMM中没有涉及到“CMM中强调大家的整体参与”这句话,这只是我个人的一点意见而已。因为在CMM中追求项目结果文档化,因此项目文档是一个比较大的工作量。我们公司一个项目结束后可能要产生50多个文件,如此大的文档工作量,如果让一人完成可能不太现实,而且文档的维护也是很大的工作量。因此需要把概要设计,详细设计等工作的一部分交给各程序员做,因此也就做到了大家参与。而且对于系统采用的技术,某个模块的具体流程等每个人肯定有每个人的想法,因此需要集思广益,大家参与讨论。无论公司规模的大小,比如微软,可能整体的大架构程序员不能参与,但是具体到小模块时,程序员就会参与其中。对这一点我的体会就在于概要设计和详细设计上,前提是大家都深入了解了需求,然后每人负责一部分模块的设计以及coding、文档的工作。
 
    [M] 是否可以这样认为,在小规模的team中,程序员该主动参与框架结构的设计等整体设计工作。而对于大型的软件开发公司(比如微软)而言,这种方式是否不适合呢?在CMM中是否对此有所提及。
 
    [L] 我的一点想法,在CMM或者公司中都没有具体谈到这个问题。确实象我们公司做的一般都是针对性很强的项目,所以在项目过程中大家都有自己的看法、自己的设想,而且项目经理或者所谓的系统分析员也未必就是考虑得十全十美。所以我的想法就是大家一起开会讨论研究整体的系统框架等问题,这样就能够集思广益。对于项目中的难点,关键的地方,大家都有个比较清醒的认识,也利于大家团结一心。我觉得即使在微软,他们也会或多或少地参与,他们也会提出他们的建议。好,这个问题留待讨论,实践。
 
    [M] 为什么CMM管理模式对小项目可能不适合呢?CMM在国内的实施过程中,有人提到了裁减问题。对此你是怎么看的。
 
    [L] 其实这个问题怎么回答呢!因为我对CMM不是很了解,我觉得企业在实施CMM的过程中不能全部照搬,如果全部照搬肯定不会适合自己的企业而且也会造成浪费的。我觉得我们公司的CMM执行就是,大家在一起学习一些CMM的思想,一起根据CMM的规则、流程制定一些适合公司自己的CMM的规则,公司按照制定的规则做事情。然后让CMM的评估机构来验证,看公司的事情是否是按照CMM的规则做的。这是我个人的感觉,因为我也没有参加CMM的培训、公司流程的制定,所以我也不是很清楚,只能按照个人的一些想法来回答你的问题了。
 
    [M] 那你从一个公司普通职员的角度来看,这种“localize”的CMM制度,在公司内部的实施效果如何呢?
 
    [L] 应该说localize的制度是符合公司的实际情况的,是根据公司的实际需要来做的。在实施的效果上应该是比照抄照搬的效果好一些的。但是CMM毕竟是一个很费精力和时间的东西,况且公司现在刚刚实施,因此大家难免会有做得不好的地方,或者抵触的情绪。不过相信随着时间的推移,随着大家意识的提高,应该会做得越来越好的。
 
    [M] 对于一项制度,在其真正实施的过程中,总会有走样的可能。比如,你所在的公司在项目管理方面所推出的一些制度。对此,你有何看法。
 
    [L] 我觉得制度是死的,人是活的。我们可能不需要完全按照制度执行,但是关键点应该保证。对于特定的项目可能制定的制度并不完全适合,所以我们要摘取恰当的部分,要灵活运用。比如一个很复杂的系统按照公司制定的流程可能从管理、资源、质量等都能够得到控制。但是如果系统本身很小,比如我刚刚接触的一个项目,功能很简单,如果完全按照公司的整套流程走的话,我估计效果不会很好,而且可能劳民伤财,还得不到预期的效果。所以对制度的执行要灵活,某些时候关键的内容作出来了,其他的边边角角我觉得可以不用深究,而且公司有时确实也是这么做的。有些项目就不完全按照CMM做,因为太浪费资源了。
 
    [M] 能对前面提到的 SQA,SCM做一下解释吗?
 
    [L] SQA是CMM中的软件质量保证的意思,SCM是CMM中的软件配置管理的意思。软件配置管理,是指在CMM中,软件开发过程存在3个库:基线库、生产库、产品库。基线库是在软件开发的初期建立起来的,比如需求、项目进度、计划等等,以后的软件开发以它为基础。并不是说不允许更改,但是更改的话需要走变更流程,需要先申请,后审核,审核通过了才允许补充进入基线库。生产库就是项目开发过程中存在的库,产品库就是项目开发完毕后的了,库中存放的大概就是一些文档、代码等等。当然你可以使用clear case来作为媒介,也可以使用source safe,这要视公司的具体情况而定。 

0
相关文章