精华内容
下载资源
问答
  • 组织级项目管理推广经验

    千次阅读 2007-08-02 08:30:00
    浅谈组织级项目管理推广经验*How to implement organizational project management system *Abstract: How to implement organizational project management system? And how to do it effectively? This paper
      
    
    浅谈组织级项目管理推广经验 *
    How to implement organizational project management system *
    Abstract:     How to implement organizational project management system? And how to do it effectively? This paper give nine problems and the solution or method for each problem.
     
    Key words:       Project management; Organizational project management; CMM; ISO9001; SPI software process improvement; Metrics; software process management.
    摘  要:                  本文结合笔者实际经验,向读者阐述了组织级的项目管理体系的推广过程中的问题和解决方法。如何实施和推广组织级的项目管理体系,如何有效实施和推广?文章给出九个关于组织级项目管理实施推广的问题并给出对每个问题在实际中的解决建议和方法。
     
    关键词:     项目管理、组织级项目管理、CMM、ISO9000、过程改进、度量、过程管理。
    中图法分类号:    文献标识码: ②
           目前国内IT公司的企业管理越来越以项目为核心,而且项目不仅仅是单一的软件项目或者系统集成项目,往往各种类型的项目并存,或者同一个客户、同一个合同要分解为若干个不同类型的项目来执行和实施,甚至要根据客户的要求来组织和管理这些项目。这样就产生了一个问题,就是如何在组织层次管理这些不同类型、不同规模、不同领域的项目,因此在组织层次建立一个组织级项目管理体系来适应这种变化就显得极为迫切。但是如何将已建立的组织级项目管理体系在组织内部各个项目中宣贯、推行呢?
    本文结合我们在建立和推广基于 CMM(其中了借鉴了众多的理论框架和模型方法,比如CMMI、XP、ISO9001、PMBOK、ITIL等。)的组织级的项目管理体系过程中,遇到的问题和困难做浅显的论述,希望就组织级项目管理体系的推广、实施与读者一起分享经验,共同交流和研讨。
    对于很多企业来讲,基于以下模型 (如CMMI、XP、ISO9001、PMBOK、ITIL等)、结合企业内部的业务和组织的实际情况建立一套组织级的项目管理体系不是一件很难的事情,当然也需要花费很大的精力来完成。但是最重要的是企业如何有效推广和实施这个体系,这是关系到这个体系最终实际效果的非常关键的环节和步骤。很多企业往往花费了很大的人力和财力,通过了ISO9000或者CMM等的认证和评估,但是却没有为企业提高生产效率、提高产品和服务的质量起到明显的效果,充其量是拿到一纸证书。因此如何在组织中有效推广和实施组织级的项目管理体系,逐步改善和提高组织的项目管理能力,逐步通过体系建立和完善企业的核心竞争力方面就显得尤为重要。
    本文是笔者在公司内部从建立、实施和推广到持续改善组织级项目管理体系的过程中遇到的种种问题,以问题和解答的形式向大家阐述,算作经验的积累。有些解决方法也是跟同业的同行专家学习到的经验,一并总结出来,可以作为企业实施和推行组织级的项目管理体系的相关人员和希望改善组织级的项目管理能力的技术和管理人员参考,更希望大家一起共同交流和学习。
           对于在一个大型的组织内部推广和实施一个组织级的项目管理体系,对在其中可能遇到的问题和阻力进行预测和分析,将会对于你的推广和实施工作带来方便和好的影响。这些问题有些可能没有标准正确的答案,但是我们可以通过分析这些问题的原因和它带来的影响来确定如何处理和面对,但是无论如何,我们都不可以忽略和轻视这些问题。
           以下将针对我们在推广组织级项目管理体系过程中遇到的九个典型的阻力和问题,以及相对应的解决方案和管理措施逐一列举介绍。
           PMO(Project Management Office)一般称为项目管理办公室、项目管理中心或者项目管理部。PMO是提高组织管理成熟度的核心部门,它根据业界最佳实践和公认的项目管理知识体系,并结合企业自身的业务和行业特点,结合企业的商业目标,负责为本组织量身定制项目管理流程、培养项目管理人力资源、建立项目管理信息系统、对具体项目提供管理指导、帮助组织开展多项目管理等,以此确保项目成功率的提高和组织战略的有效贯彻执行。如何分配给PMO的职责和权利,也是我们在实施组织级项目管理过程中不得不面对问题。
           首先,既然要执行组织级的项目管理制度,那必须在组织层面有人来负责该工作,因此PMO就担当此任。任何工作,无论它的重要性如何,如果最后不能落实到有效的资源来执行,不能保证适合的人来做的话,那这就很可能无果而终。因此有一个专门的机构(这个机构可以是实际存在的也可以是虚拟的,可以是兼职的也可以是专职的,视组织的规模和情况而定)来负责是必要的。
           其次,让我们来看看PMO的职责:
    u       开发和维护项目管理标准、方法和程序;
    u       为企业提供项目管理和咨询和指导;
    u       为企业提供合格的项目经理、质量经理;
    u       为企业提供质量保证的手段和能力;
    u       为企业提供项目管理体系的培训;
    u       为企业提供项目管理的其他支持;
    u       负责组织级的过程建设、组织级的财富积累、知识传递等。
           第三,组织内部必须有一个专家组织,PMO人员的素质和能力往往决定组织级项目管理能力的高低,决定组织级体系能否发挥作用的前提条件。试想如果不是一个在该领域具有专家能力的人,他们制定的体系和制度能否得到执行者的认可?因此对于PMO来说,具备相应的能力是必须的。
           第四,PMO组织机构及组成人员:
                  PMO的组织机构一般分为以下几条线:
    l         一是项目管理:包括项目总监、助理项目总监、高级项目经理、项目经理等;
    l         二是质量管理:包括质量总监(组织级)、 SQA(项目级)、审计专家、配置管理经理、配置管理工程师;
    l         三是组织过程组:包括 SEPG(软件工程过程组)、ISO9000内审组、度量数据分析组;
    l         四是知识工具:包括知识管理人员、培训协调人、工具开发组。
           这个问题似乎很多人都对此有疑问,既然项目经理是项目的直接责任人,他负责整个项目的TQC。那么为什么还需要专职的SQA来保证项目的质量呢?回答这个问题,先让我们看一下东西方的制度和文化的不同。西方的文化强调分权、量化,这与西方的制度也有很大的关系。在他们的管理哲学中强调,不是不相信当事人,而是必须是制度来保证独立的第三方来对工作进行检查,验证。不论CMM还是ISO9001,都是我们引进的西方的管理模型和标准,因此我们就不得不考虑这些模型和标准背后的管理文化的差异。对待SQA这个角色来说就是最典型例子。
           在软件项目中,SQA正是这样的角色,他是规范过程的引导者、过程执行的监督者。是独立于项目的第三只眼睛,从不同的视角来审视项目的问题,并将此通过单独的渠道汇报给高层经理或者项目的最终负责人。
           在组织过程中,尤其对于实施CMM体系的企业,对于SQA这个角色的认识更为清楚和深刻。
           下面是PM、PMO、SQA的职责的比较:
    角色
    职责
    PMO
    更关注组织级的体系的建立、维护和改善;
    关心整个组织的所有项目的成功,不是一个项目的成功;
    对组织所有的项目进行监督和监控;
    为项目中的 PM和SQA提供技术、工具等支持;
    关心组织项目管理能力的成熟度。
    PM
    更侧重于关心进度、成本、开发以及技术等方面;
    PM对SQA的工作提供支持;
    PM更关心当前项目的成功,PM是直接责任者;
    直接领导项目组成员。
    SQA
    侧重于过程管理,对过程进行审核,确保过程正确实现;
    协助 PM积累项目的过程财富;
    SQA帮助PM发现并解决项目中的问题,对于不能解决的问题要及时上报;
    SQA不仅仅关心当前项目的成功,还关心整个组织的过程能力;
    不直接领导项目组成员。
           建立和实施项目管理体系,对企业带来哪些利益?这也是个典型的问题,任何企业的经营管理层都会对自己企业的投入能得到什么回报最为关心。因为对于企业来说,赚取最大利润是最重要的。如果企业的管理者反对或者不愿意进行某件事情,那么他就会问做这件事情会给企业带来什么经济上的效益。如果作为PMO的成员,当在遇到这样的问题时,必须小心回答,因为这将成为你工作上很大的阻力和压力。关于组织级项目管理会给企业带来什么回报我们可以从以下几个方面来解释:
           第一,从整个行业来看,或者举出其他企业的成功案例,或者找出竞争对手这样做取得了良好的效果。公司的高层经理往往会关注竞争对手的进步;
           第二,从企业内部来看,做经济效益的分析,参见下图:
    组织级体系的涉众利益分析:
    利益
     
    涉利者
    企业利润
    过程可视化
    过程财富积累
    项目的跟踪和控制
    制度与文化
    人员流失的损失
    沟通
    个人技能培训
    产品质量
    客户满意
    高层管理者代表企业
     
     
     
     
     
    SEPG
     
     
     
     
    SQA
     
     
     
    产品经理
     
    PM
     
    技术人员
     
     
     
     
     
     
     
     
    市场销售
     
     
     
     
     
    客户服务
     
     
     
     
     
     
    HR
     
     
     
     
     
     
    后勤职能
     
     
     
     
     
     
     
     
     
     
    客户
     
     
     
     
     
    组织级体系的经济利益的分析:
    回报
     
     
     
     
    投资
    增强过程可视化
    积累组织的过程财富
    提高项目的可控性
    建立完善的制度与文化
    减少人员流失的损失
    提高开发效率
    减少测试成本
    减少沟通成本
    提高个人技能
    提高产品质量
    减少维护成本
    提高客户满意度
    员工培训
     
     
     
     
     
     
     
     
    专职过程人员
     
     
     
     
     
     
     
    专职质量人员
     
     
     
     
     
     
    PM计划
     
     
     
     
     
    编写文档
     
     
     
     
     
     
     
    购买工具
     
     
     
     
     
     
     
    评审成本
     
     
     
     
     
     
     
     
    度量成本
     
     
     
     
     
     
     
    第三,下面这个方法也许是能更加量化,向决策人更好地解释的途径:
       当你面对上面的问题时,应该按照如下的步骤来分析答案。
                  1.       列出目前影响组织中软件项目赢利的几个问题点,因为项目管理体系不可能直接创造价值,我们从相反的角度来思考这个问题;
                  2.     分析一下这些点有哪些是通过过程改进和管理可以解决的;
                  3.     对比实施过程改进解决这些问题所花费的成本和由此而得到的成本的节约;
                  4.     考虑进去实施过程改进的其他间接获益。
                  比如,下图是我们某个部门的分析,使用了石岛川的鱼骨图方法,把影响项目亏损的原因找出来。因为发现了问题才能去解决问题,只有针对问题才能对症下药。

           " />1

     
           一个新的方法和模型,总是会有人提出负面的问题,就如NAH症结(Not Applicable Here),对于一个新的方法体系,大家都觉得有道理,但是具体到一个组织、一个项目实施过程中,总是能找出消极的理由来说明这个方法在这儿是不合适的、是不适用的。大家坚信这个方法或理论对于其他的组织和单位是适用的,但是到了自己头上,往往想到的是它有哪些缺陷和不适用,对它们的优点视而不见,总是用过于批判的眼光来审视它们,这也是造成推广效果不理想的重要原因之一。
    对于这种阻力,我们要从两方面来分析:
    l         第一:是否是真的不合适,如果是这样,那就要从如何客户化和实例化入手,让它更适合该组织的特殊环境;
    l         第二:如果仅仅是因为一些习惯或者没要说服力的理由,那就不能动摇实施推广的信心和念头,因为任何新的东西都会改变以前的某些习惯和做法,甚至会触及部分人的既得利益。
           这个问题的解决方法有两种:
    l         一是强硬的策略,先僵化,再固化,然后再灵活化。通过僵化、固化,更深地了解和学习这些新的方法和理论,更深地了解到底不适用是人的问题还是方法本身的问题。然后再来定制和灵活处理。
    l         第二就是针对不适合的地方进行裁剪,当然这必须基于对方法本身和自己的需求十分清楚才可以,否则容易画牛不成反类马的南辕北辙的情况。要达到目标,正确的方向和努力是两个必要的条件,但是如果方向是错误的,那努力会让目标越来越远。裁剪的策略和如何进行裁剪在整个工作过程中是最困难的,正确的策略和正确地裁剪是非常重要的。为此我们需要制订和编写详细的过程裁剪的指南和项目的生命周期的裁剪指南。
    在如何更好地适合自己组织的要求方面,也有很多好的方法可以借鉴,比如:
    l         对过程进行裁剪;
    l         定义不同的项目的生命周期模型,比如软件研发类、集成类、服务类等;
    l         针对不同的项目进行生命周期的裁剪。
           实践证明,在企业实施和推广一个组织级的项目管理体系的阻力来自公司内部、公司外部。(公司外部的因素涉及到整个行业的发展、市场因素和客户因素,在此不做描述,本文重点对企业内部的因素做分析。)因为体系的实施,需要的是组织内部的人员的工作方式和管理的改变,这种改变影响最大的就是技术和管理人员。有人说:如果人没要改变,那么一切都不会改变。因此要想获得组织级体系的实施的成功,改变体系的主体人是最直接、最重要的一项工作。
           所以在组织级体系推广时最终必须实现人人参与,项目管理本身就是一项团队活动,如果不是每个人都参与,就不会获得整个项目的成功。而且不参与的人员将会成为阻碍的力量。正如组织管理心理学中的“归因理论”,参与的重要性在于让参与的人意识到项目的成功有自己的努力在里面,从而他会更希望成功。参与的目的是通过参与改变对项目管理本身的认识和理解,了解并熟悉体系本身,学习如何在项目的实际过程中如何按照组织的要求和规范进行。进而主动遵循规范和流程,降低推广的成本。
    相反,如果不是人人参与,每个人的想法不同,以前的经验不同,甚至不同的员工以前就职的公司不同,采用不同的体系和方法,这种文化和思想上的融合是比较困难的。因此如果人没有改变,那么整个的管理就不会改变,所以体系的推广必须跟人的改变结合一起,相辅相成,互相促进。
    但是人的改变不是一件容易的事情,通常应该注意的有以下几点:
    l         人的改变不是去改变个人的性格、个人的思想和个人的价值观,如果这样理解就非常危险,通常会导致紧张的人际关系;
    l         人的改变是大家达成共识的过程,是统一组织的价值观;
    l         人的改变不是一蹴而就的,需要坚持和耐心;
    l         人的改变要与公司的制度建设和组织文化建设相结合,不可单枪匹马,孤军奋战。
           这往往会成为项目组乐于接受并主动欢迎的唯一的形式。因为大部分企业把培训作为一种福利或激励手段。而工具的推广一方面使得项目经理和技术人员学习到最新的工具和方法,另一方面也可以提高项目组的成员的工作效率,为他们的日常工作提供方便,减轻日常的繁杂的工作,比如:工作量的填报、收集、问题单的填报、跟踪、各种报告等重复性劳动等。
           因此在推广组织级的项目管理体系的时候考虑相关的工具的推广是一个很好的主意。当然工具的选择、引入和推广是PMO必须考虑的,什么时候引进,引进哪些工具?都是要慎重考虑的,因为工具的引入可能会改变已有的体系的流程和操作,包括是采购还是自行开发等都需要慎重考虑。下图是选择和引入工具的流程,供大家参考。
           目前在软件组织常用的工具有:
    l         配置管理工具: VSS、CVS、CC等;
    l         缺陷跟踪工具;
    l         工作量测量工具:用于工作量测量和报工、派工使用;
    l         KPI考核系统;
    l         分析建模工具: Rose、PowerDisigner、ERWin等;
    l         测试过程管理工具;
    l         需求管理工具;
    l         过程管理和度量工具等。
           项目组人员抱怨文档太多是一个普遍的现象,甚至有些人把进度的延误归结为写了太多的文档。抱怨文档太多的原因有以下几个:
    1.       确实是比较多:除了技术方面必须的文档之外,用于管理的、控制的、跟踪记录的、作为报告的、度量分析等文档,文档的工作量增加了管理的成本,同时也增加了项目组的负担;
    2.       重复劳动比较多:为了针对不同的读者(上级领导、客户等)对同样的内容要按照不同的模板写多次。这种情况发生在项目经理身上比较多,经常为了汇报项目情况要把相同的内容拷贝、粘贴到不同的模板交给不同的人。或者在做量化管理的时候,收集和测量一些过程数据,也存在类似的情况。有人说项目经理只要会在 Word文档里Copy、Paste就可以,虽然这不是现实,但反映了项目经理的重复性劳动确实是实际存在的;
    3.       习惯以前的做法:以前可能习惯不规范的开发,管理相对比较粗放,突然接受到新的规范,感觉文档太多。这种情况尤其在体系刚发布,开始推广的时候大家反应比较激烈。
    解决方法:
    1.     对于第 1点,PMO首要的任务就是砍掉无用的文档,合并可以合并的文档,暂时管理上不需要的文档作为可选文档,不是必填的;
    2.     2条实际是一个常见的问题,项目经理疲于应付来自各个管理层的汇报请求,复制、修改成了项目经理的家常便饭。对于这种情况,有两个解决方法,一是规范汇报机制,规范沟通方式。二是使用工具,使用工具可以让项目经理从中提取数据,充分共享原始数据。比如度量工具、报工系统等;
    3.     对于第三条是最让 PMO头痛的,因为这种情况很容易演变为大家对体系的阻力。解决的办法主要是宣贯、培训,正如3.5的介绍。
    度量的目的主要是实现精细化的管理、有效地对项目进行控制,对度量数据的分析用于辅助决策、经验积累、有效评估等。但是度量本身就是双刃剑,一方面度量对于精细化管理是必要的前提,另一方面度量体系、度量的执行需要花费大量的人力成本,而且如果没有明确的目标和有效的方法来分析和利用这些数据,度量就又陷于无谓的劳民伤财,成为组织过程的累赘。
    很多企业的度量陷于盲目,导致了很多负面的影响,进而影响整个组织对项目管理体系的理解和信任。有如下问题和误区存在:
    1.       不清楚组织的需求(到底需要度量什么);
    2.       不清楚度量的用途,认为度量总是有用的;
    3.       度量是不需要花费的或者投入是很小的;
    4.       直接用于考核,忽视了度量的导向作用的两面性(最常见的就是代码行作为程序员的成绩,导致了代码的重用性差,无效代码增多等负面影响);
    5.       在数据分析时孤立分析数据结果,没有考虑相关的度量指标的结果;
    6.       不相信数据,认为数据是没有用的。
    在这里不想介绍什么样的度量体系和方法、度量的技术和流程。仅仅结合度量在实际实施过程中的好的实践列举给大家。对于上述误区有以下实践和经验可以借鉴:
    1.       需要什么才度量什么,从组织的需要、项目的需要、产品的需要、过程的需要以及管理的需要等分析,根据目标来选择测量指标;
    2.       度量必须用于决策并支持决策才有意义,度量必须结合组织的商业目标并为实现这个目标而努力;
    3.       度量是耗时耗力的,因此测量不要花费过多的额外工作量,测量结合在工作过程中,而不是需要额外的工作,可以考虑使用工具,减少度量的成本;
    4.       不要直接用于考核,从积极和正向激励的角度出发来设置度量考核,如果用于考核要结合多个指标,并将数据处理后使用,不能直接使用;
    5.       数据分析要考虑影响因素和相关 Metrics;
    6.       保证数据的完整正确,并相信数据,如果你不相信它,那它就没有任何意义。
           规范化的文化说到底是建立一种共识,有了这种共识,规范化的制度、流程才得以顺利执行,缺少这种共识,在我们推行一个体系和制度时就会困难重重,阻力和压力会导致冲突和失败。文化相对于制度,正如道德相对于法律,对于执行来说可以大大降低成本。因此从一开始就以建立共同的共识、最终建立一个规范化的文化为目标,会使得我们的推广行动事半而功倍。想一想,当规范和制度成为一种习惯的时候,我们的“推”行的工作还需要“推”才“行”吗?当然这个时候我们的工作重点就是过程的改善和维护了。
           如何才能建立起规范化的文化呢?我想不同的组织和不同的人的答案肯定是不同的。我们的经验就是:加强宣贯,不断强化,建立共识,形成习惯。
    总结我们在实施和推广组织级的项目管理体系的过程中,决定实施推广成功的因素有以下几点:
    ²        有人去做 - 设立 PMO或相关机构负责;
    ²        高层支持,下层买账 - 获得高层理解,取得下层的信任和认可;
    ²        人人参与 - 建立广泛的共识,消除潜在的阻力;改变人才能改变组织;
    ²        建立文化 - 文化的建立标记着体系的制度化和实施推广的成功。
    致谢 在此,我们向对本文的工作给予支持和建议的同行、同事表示感谢。
    References :
    [1] 《软件过程管理》,瓦茨 .S. 汉弗莱。北京。清华大学出版社, 2003
    [2] CMMI3 级软件过程改进方法与规范》,林锐。北京。电子工业出版社, 2003
    [3] 《组织管理心理学》,北京大学出版社, 2004
    [4]  张家浩。软件项目管理。北京。机械工业出版社。 2005
    [5] Software Assessments, Benchmarks and Best Practices 》, Capers Jones Pearson Education 2003
    [6] CMM in Practice Processes for Executing Software Projects at Infosys 》, Pankaj Jalote India Publishing House of Electronics Industry 2002
     
    作者 简介: 李华领 ,男 (汉族),神州数码(中国)有限公司政府和公共事业本部项目管理部经理、高级项目经理,曾多年从事软件开发和项目管理工作,参加过三峡工程管理系统项目以及全国性的大型信息化项目的开发和管理,主要兴趣方向:项目管理、软件质量管理、CMM/CMMI等。
     


     
     
    展开全文
  • 本视频教程以新的信息系统项目管理师教程(第三版)为蓝本,结合小任老师多年高校教学经验和软考培训经验录制。参加工作后,我们没有太多的时间投入到信息系统项目管理师的备考中,教程太厚、真题太难,怎样花少的...
  • 建软建筑工程项目管理软件是建软软件根据分包商、个人承包商工程管理特点及公司多年的工程管理经验而研发的国内首款纯B/S架构的工地管理系统。系统基于建软软件先进的JavaEE云技
  • 首先可以从经验谈起,没有充足的项目管理经验可以从项目助理开始做起,往往项目助理这个岗位是辅助项目经理管理的,从中你可以学习前辈的项目管理方法,尝试着做一些小项目,积累项目管理经验。 一般刚从事管理岗位...

    一年左右的工作经验不足以让你保证能面试上,况且是转行,这个时候你就得思考,怎么才能让HR在一群有经验、专业对口的求职者之中选择我呢?我如何脱颖而出?

    首先可以从经验谈起,没有充足的项目管理经验可以从项目助理开始做起,往往项目助理这个岗位是辅助项目经理管理的,从中你可以学习前辈的项目管理方法,尝试着做一些小项目,积累项目管理经验。

    一般刚从事管理岗位的员工更受公司的重视,因为每个公司都有自己的运营管理方法,一些混迹在管理职场的“元老”,工作了很多年已经形成了一套自己的项目管理方法、项目管理风格,企业再想去让他按照自己公司的方法风格进行管理还是有点儿难度的。刚从事没多久的项目小白就犹如一张白纸,还没有形成自己的方法风格,企业在按照自己需要的管理者要求进行培养,那么,多年后有多出了个“元老”哈哈。

    PMP认证

    再之就是可以考取PMP项目管理专业人士资格认证,PMP认证的过程是一个系统学习和巩固项目管理知识的过程,这个过程将帮助PMP认证参加者将以往的项目管理经验与系统的项目管理知识结合起来,互为印证,达到理论是实践的结合,从而深化自己对项目管理的认识。

    PMP考试内容:

    PMP考试内容理论主要来源官方教材PMBOK指南中的五大过程组和十大知识领域。
    五大过程组:启动、规划、执行、监控、收尾。
    十大知识领域:整合管理、范围管理、时间管理、成本管理、质量管理、项目资源管理、沟通管理、风险管理、采购管理、项目相关方管理。

    得到了PMP认证就等于:

    a.你已经具备了全面的科学的项目管理知识;
    b.你已经至少拥有三年以上的项目管理经验。
    c.你的上述知识与实践,已经得到PMI的检验认可

    不管做什么,人生处处皆项目,但学习PMP能收获到:

    1)升职加薪
    2)求职的敲门砖
    3)进大公司的机会
    4)更好的从事项目管理工作
    5)个人竞争力变强
    6)培养学习的习惯和态度
    7)知识体系受益终身
    8)更好的转行
    9)从技术岗转到管理岗的捷径

    展开全文
  • 项目管理流程.vsd

    2020-05-26 11:38:46
    软件项目管理的通用流程,是自己多年工作经验总结出来的,适用于一般的软件开发模型,下载后可以根据自己实际项目进行修改,也可以直接使用
  •  介于许多人对项目经理这个职位的陌生和含糊,将自己的切身经历和阅读、交流得到的一些经典案例整理出来,有朋友问我,这篇文章出处在哪里?这些经历很多不是一个人的经历,这些总结很多也不是出自一个人之手,如同...

     前言:

                介于许多人对项目经理这个职位的陌生和含糊,将自己的切身经历和阅读、交流得到的一些经典案例整理出来,有朋友问我,这篇文章出处在哪里?这些经历很多不是一个人的经历,这些总结很多也不是出自一个人之手,如同我们觉得一段代码写的很好,必定会收藏整理成为自己的一部分加以完善共享,接着不断的有人完善共享下去,我们谁都不敢说自己是最聪明的人,但只要不断的学习总结别人已经有的经验,就有可能在最短的时间赶超别人!

               要做好一个项目经理,是很有点难的?他首先必须要是技术和管理的化身,其次要具备较好的形象和极佳的口才,同时拥有一定的人格魅力,另外他还要具备一定的设计头脑和审美观,还有很多,不再赘述....在大多数boss的眼里,是没有体系分工的概念或者基于各种原因分工比较简单,所以很多书里讲的东西拿到现实里都会有点靠不住,在没有产品经理,没有需求分析师,没有架构师,没有系统分析师,更有甚至没有实施和运维,也要能毫无怨言的把事情做好!它是一个攻守兼备的全能型职业,很多boss都把它放在了至关重要的位置去看待,舍不吃舍不得花也要把你留住,也是你的舞台!而这在老美“山姆大叔”的眼里是绝对不能容忍的,就像福特汽车流水线,肯德基,麦当劳一样,他们更希望所有员工都能这样被取代,当中国的所有企业进步到那种境地以后,我们能做的事情就不多了,你想走到更高端的塔尖会更难!投刘备还是投曹操都没有错只要你能更快的走到塔尖,只要你是舞台的主角那就是正确的选择!

               不管你是正在转型做项目经理,还是有打算转型,那一定要转变以前种种思想的包袱了,由内而外的改变自己,很多路子只是苦于我们没有发现,没有人指引。我们不希望每字每句的总结和讨论都能去符合每个人的行走线路,因为那是不可能,只希望当我们遇到困难缺乏指引时它能成为我们的坚强后盾和理论依据,因为沟通才是通往成功最好的桥梁!

             

        正文 :

            做项目经理工作多年,感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导,只有最合适的,没有什么叫对的,什么叫错的,项目经理最忌讳的就是完美主义倾向,尤其是做技术人员出身的,喜欢寻找标准答案,耽误了工作进度,也迷茫了自己。以下是本人一些做项目的个人体会,写出来供大家指点,在讨论过程中共同提高水平。软件工程跟其它建筑工程之间的区别之一是,总有人会拿各种各样的事来讽刺软件的设计和开发过程中的不确定性,但从没有听说过有什么大桥建成之后和图纸上设计的不一样的。下面有一个漫画《 客户真正的需求是这样的 》已经足够一针见血的了,

     

           还有这幅漫画同样一点情面的不留,虽是漫画,但现实生活中不乏实例

      

     

    项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候,首先要尽可能地多从各个方面了解项目的情况,如:

      1. 这个项目是什么项目,具体大概做什么事情,是谁提出来的,目的是解决什么问题。在国内很多客户都很不成熟的情况下,千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统。前期了解情况的工作越详细,后面的惊讶就越少,项目的风险就越小。

      2. 这个项目里牵涉哪些方面的人,如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等,很多项目里除了业主单位的结构很复杂以外,还有一些其他单位也会牵涉进来,如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望,可以让你在做项目碰到问题的时候,就每件事情分析哪些人会在什么方面支持你,哪些人会出于什么目的反对你,从而提前准备联合朋友去对抗敌人,让事情向你所希望的方向发展。没有永远的朋友,也没有永远的敌人,只有一致的利益,这句话作为项目经理是一定要记住的。

      3. 基本了解了客户的情况后,下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视,这个决定了你在需要资源的时候,公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的,你需要做的是了解公司对这个项目的实际期望,是想把项目越做越大还是想赚钱?是想做样板工程还是干脆想敷衍了事,公司领导对项目的态度决定了你做这个项目的战略,而这个战略方针将对你做项目计划产生直接的影响。

      4. 在做整体项目计划前,还要大致计算一下你手上的资源。首先是时间,现在市场竞争激烈,往往很多项目要求在几乎不可能的时间范围里完成。对于这一点,你在做项目的风险控制计划的时候要充分考虑。其次是人员,根据项目预算和已往经验,大致计算一下未来的项目小组有多少种角色,每个角色目前公司是否有人,是否能完全归这个项目使用,是否需要另外招聘一些人员,招聘的准备工作要尽早启动。最后就是一些设备的准备,项目所需大件关键设备要尽早预定,以后不管发生设备等人还是人等设备的情况,浪费的都是你的时间。

      5. 现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚(主要是讲做什么,而不是说怎么做),而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情,也让客户的业务人员(一般不懂技术)知道项目做成什么样就算完成了。简单地说,项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。

      6. 是到做总体计划的时间了吗?不,你现在已经知道了客户的目标和你手上的资源,那么做计划以前,你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的,你需要写一份报告,详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话,将发生什么样的后果。如果资源不够,就要高层改变策略,增加对这个项目的投入。甚至在条件许可的情况下,有些公司会放弃这个项目。总之,没有人能完成一个不可能完成的任务,如果项目经理不能尽早发现风险,那么就只能去当烈士了。

      7. 明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略,现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利,那么,就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同,相差较大,很难有什么具体要求,但是,一定要有精通客户业务的人,很多小项目里,这个人就是项目经理本人,大项目里会配备行业专家(Industry expert),这样和客户沟通起来才不会鸡同鸭讲,双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语,结果搞得客户一头雾水,反过来,他还指责客户不懂技术。其实,明白自己想做什么的客户已经是很好的客户了,不知道自己要做什么,更不懂怎么做还要指手画脚的客户到处存在,但是要明白,是客户选择了你,而不是你选择了客户,有了客户你才有工资拿,心平气和一点吧。

      对于这种需求天天变的客户,你就一定要事先做好规矩:

      一、统一联系人,客户指定一个人和项目组进行沟通,不能张领导、王领导都来说几句,如果他们意见不一致,那你只有得罪领导的选择了。所以,项目的最初就要定好规矩,我项目组只认一个的意见,有什么要求你们内部先统一再和我谈,我不想卷入你们内部业务部门之间的矛盾之中。

      二、所有需求变更全部要有书面文字,这点切记!这样做好处多多:

    • 有书面证据,以后他还想改,你有了他以前要求的证据,告诉他:你以前可是这么说的。
    • 便于需求变更管理,需求如何慢慢演变的历史可以看清楚,从而更深切地体会客户的目。
    • 对于客户来说,嘴巴一动最方便,反正是你们做,不花他的资源,所以要求是否合理,是否和项目的目的一致,他是不负责任的。但是如果要他写书面要求,还要签字盖章,他就要谨慎多了,而且一写东西,思想就会更加深入,很多无理要求也就这样胎死腹中了。

      8. 现在你要面对三群人:你的领导、你的组员和你的客户,和这些人沟通,让他们知道你打算怎么做,什么时候要他们做什么准备,这些事情将是你的主要工作。既然沟通这么重要,那事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则,如果你在一个部门时间做长了,对这些规则的运用觉得是一件理所应当的事情。但是,你现在面对的是多个部门甚至多个单位,不把沟通规则说清楚,你以后就会吃亏。下面的东西看起来无聊,其实还是很管用的:第一个是规定信息的流动方式和介质,是推还是拉。推的意思就是项目经理将主动发布信息,不管通过电话、邮件还是书面方式,保证将信息传达到每个人。这种情况适合小项目,人少。拉的意思就是项目经理就是一个类似web服务器,你自己需要什么信息就去问他。当然,没有项目经理把自己搞得那么累,他会用发布信息到公共介质的方式公布信息,简单的是白板,复杂一点的是项目的公共信息交互区,潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊,其实里面牵涉信息传达不完全的责任问题。当然,这些都是指一般的方式,而且不要绝对化,一般情况下,主动沟通和被动访问是同时存在的,尤其是对领导,项目经理更加应该主动去和领导沟通。第二个问题就是文档问题,很多人怕写文档,但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢?就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的,比如项目经理的项目日志,每个星期至少让客户签字,另外所有达成共识的东西,比如会议纪要,甚至领导的讲话记录,都要写成文档,双方签字,这样以后扯皮的时候,就能做到有据可查。记住:说了的就和没说一样,只有写下来大家签字后才算真正发生了的。还有一些问题,比如你提交的报告,给领导(包括本方领导和客户领导)做一个选择题,结果领导压住不批,让你无所适从,结果拖延了进度。这时候,你可以等,但是注意要留记录,标明是谁的责任;另外,如果你在开始阶段就和领导商定:如果批示提交三天后没有得到领导答复就算对方同意,这样你就会主动很多。再比如不同事件的审批流程问题:什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到,以后的工作就越主动

      9. 好了,做了很多前期工作,定义了一些游戏规则,现在是坐下来做计划的时候了。这一节,任意找一本项目管理的书都会说得比我好,所以我就少写一点,说一些自己的体会就是了。首先是找几个关键组员,比如客户业务专家、系统分析员等等,做一下项目模块划分工作。项目分成几块去做,每一块完成什么,模块之间的信息如何交换等等。需求定义的是做什么的问题,而这里说的是怎么做的问题。这里要强调一点:完成一个目标有很多种方式,你要选一种你最熟悉的,而不是看上去最完美的,这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动,坚持要你采用那种新技术,你就应该告诉他:你选我做这个项目,就应该容许我采用自己最喜欢的方式做事情,新技术之所以有诱惑力,就是因为吃亏的人还不多,我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确,比如用微软的Project软件,你填写完表格以后,就可以知道这个项目有多少件事情要做,每件事情需要什么资源,他们之间的前后关系如何,消耗的时间有多长,完成后有什么标志等。所有的结果最后用一个叫做甘特图的形式表现出来。你做完这个表以后会惊奇地发现,甘特图上项目的结束时间会远远落后于你的计划结束时间(签合同的人永远不会先征求你的意见的)。当然,学过项目管理的人会大谈什么WBS、优化路径之类的东西,但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题,在我恭喜你挑了一个轻松活之前,请你再去确认你是否罗列了所有要做的事情和正确评估了它们所需要的时间。这时候,你就要考虑牺牲一些任务的时间(也意味着质量)了。按照什么标准牺牲?这个项目的战略!我们在第三节提到过的战略。我的经验是如果你什么都赶进度,其结果可能就是十件事情你一件也没做好,想想多么失败啊。所以,把资源投到你熟悉和有把握的事情上,最后的结果是十件事情,你有三件做成了精品,三件完成,还有四件因为某些原因延误,成绩单是否靓丽了很多呢?战略决定优先级,而正确排列事情的优先级是一个项目经理能力的主要体现。

      10. 好,现在项目已经完成了前期工作,了解了项目的目标、搞清楚了手上的资源,制定了项目的策略,然后编制了项目的整体计划,项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候,不像前期的时候项目经理要象记者一样到处和不同的人接触,搞清楚他们在说什么,努力猜测他们在想什么和他们的真正目的,那才是最累人的事情。当然,小项目的项目经理往往自己也是一个资源,要做很多事情,这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意,除非你需要对方给你支持,那么你才需要讲得具体一点,否则,告诉他一切正常就可以了,而且态度要积极一些,千万不要说一些领导不懂的细节,比如:“王局长,最近项目进度还算正常,就是JVM经常发生一些内存泄漏的情况…”王局长:“(*&$@@”。和自己的领导汇报也要注意这个问题,除非他是一个技术高手,你需要他的技术经验,否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了,有些需要他支持的地方,比如资源调用需要说详细一点。和组员开会,除了一些项目进度跟踪会议以外,还有很多讨论会,需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员,他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强(如果总结得不对,欢迎大家拍砖),所以,你作为会议的主持人,只要负责提出问题和记录下他们的观点,千万不要做评判者的角色。一个问题,有很多方面,从不同的角度看,现象是完全不同的,想想盲人摸象的故事吧。这些技术人员,他们往往精通一个方面,就自己的角度发表见解,除非一些很特别的情况,你都应该认为,他们提出的方案,从他们的角度来看是最合理的。你的长处是掌握事情的优先级,评估各个方面的轻重缓急,从而根据他们的意见得出一个合适的(而不是正确的)方案。所以,在会议上,你要充分尊重每一个人和他的意见,夸奖那些意见提得比较好的人,千万不要把会议带入无休止的争论(你要让大家知道事情不是非黑即白的,而是多元的,唉,我们的教育惹的祸…)。会后,你自己写文档,做决定。会议上大家的面子都被照顾了,自己实施起来的阻力就小,如果还有意见的,你就私下找他聊,如果还不能说服他,你就要让他明白,因为你负责这个项目、你担当风险,所以,这个优先级应该你来判断。组织中的高层,并不见得水平会比一般的成员高,但是,他要承担组织的风险,加之信息的不对称性,所以,对事情的优先级的判断肯定比下属强。

      终可交付成果一定要是可以被检查的,比如,【界面要求:美观大方、简洁明快】,这个要求我就不知道如何检查。所以,给开发小组布置任务的时候就要考虑如何检查结果,比如我见过一个计划,里面有一个任务【开发人员熟悉EJB编程】,这个任务,除了让这些人去参加一些专业认证考试,否则,结果很难被检查。所以,时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情,我听说有些老项目经理拿到项目是倒排计划的,即首先看如何验收和验收标准,然后决定工作计划。很多项目开始了很久,还不知道如何验收,那么这个项目出问题的可能性就很大了。做项目就是为了验收,我们的角色不是研究机构,我们的目的就是在付出那么多劳动后得到结果。

      另外我插一句:我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流,很容易引起冲突和矛盾(技术人员的本性决定的)。我的做法是项目经理和项目实施人员到现场,软件开发人员还是在公司做项目。项目实施人员就是初级项目经理,他们了解自己的产品,懂得一些客户的业务,关键是在于他们具有良好的沟通能力,俗称“皮厚”。他们是客户和研发人员的桥梁,其职业方向也是很机动灵活,以后可以有很多方向可以转,比开发人员的路要宽得多。

      11. 接着,我们再谈谈最让人头痛的需求变更问题。变更通常分为两种:一种是部分更改了原先的目标,即需求变更;另一种是没改变目标,但是客户不满意目前的实现方式,大到流程的实现,小到界面的布局,都是属于这类。碰到这种情况是难以避免的,主要是事先沟通的不够充分和客户随着项目的进展,慢慢想清楚了问题,改变了以前的思路。这时候,如果需要改并且你的战略是容许这种情况的,那么注意下面几点:

    1. 确保以前的文档,就是记载着以前的结论的东西,客户是否签过字,如果没有,赶紧把你的工作停下来,赶快再和客户自己确认一下你的方案,然后让他签字,避免以后说话没有凭据;
    2. 和客户坐下来,探讨他修改的根本目的是什么,是不是有同样能达到相同目的、但是对你来说有代价更小的选择?
    3. (项目初期的工作)明确更改流程,一般是客户指定一人签字(否则客户每个领导都有权力来插一杠子,你就废了),以正式项目文件的方式提交给你,然后,你做评估分析,分析对成本、进度的影响,在你的领导同意后,出相应意见书,主要是要说明更改设计的原因和指出由此带来的不确定后果(这个东西先写出来,后面如果真的发生了,至少不是你的错)。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗?对,就学习那个,让大家都意识到任何的更改都有成本和代价。

      12. 系统开发告一段落后,就进入客户培训、系统验收阶段,这个阶段,我一般会注意以下几个问题:

      一、给客户做培训前,多注意一些表面功夫。很多程序员认为,系统的逻辑核心是否正确是关键,至于界面如何,界面上的用词是否准确,那是无关紧要的问题,而且培训的时候也是信手拈来,想到哪里说到哪里,下面听讲的人不知所云,云山雾罩,培训效果自然可以想象。我的体会是,给客户做培训的版本,如果你在做多次测试以后仍然不能确定逻辑是否合乎要求,那么,你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等,总之不要让客户看到一些他不该看到的东西。文档方面,准备至少两个文档:用户手册和培训手册。这两个文档的内容很多都是一致的,但是角度完全不同。用户手册往往是站在系统设计者的角度,按照自己的思路,分模块讲解系统的操作和功能;而培训手册,一定要站在客户业务人员的角度,根据每个角色面对不同业务的办理,如何通过使用本系统的一系列功能来实现目标。所以,第一次培训以前,系统界面是否完整正确、培训文档是否完备都是很关键的因素,第一炮打不响,以后就麻烦很多

      作为项目经理,其实脑子里就是几样东西:做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想,这四个方面都是相互矛盾的,属于典型的又要马儿跑,又要马儿不吃草的类型。考虑问题的轻重缓急方面,往往是把快放在第一位,各方领导都会给你最后期限,所以保进度是第一位的;省是第二位的,企业的根本目的是盈利,如果收入不能增加的话,至少费用要控制住;好是第三位的,没办法,谁都想精益求精,但是,没有强大的资源保障,质量只好先牺牲了;最后是多,客户的要求源源不断,如何降低客户的期望值,让他们从理想回到现实也是项目经理的分内工作。

      验收前,除了做好文档工作,即可交付成果以外,多花时间搞清楚客户的做事情流程是很重要的事情,这些在前面已经有所提及,这里就不再多说。

      我对验收最大的体会就是举证问题。即千万不要让客户这么想:你必须有证据证明你的系统是没问题的。这样你就没戏了,微软那么多天才,做了XP还天天打补丁,要你的程序没问题,既不可能,你也没办法拿出证据。你要让客户明白,所谓验收,就是我按照测试文档的测试用例跑一遍,结果和预期结果一致就应该算通过了,而且还容许有一些小错误留在验收后改正,他可以对测试用例提意见。所以,验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求,那么他应该举证,证明这个系统和最初设计相背离的。所以,参考法律概念,千万不要举证倒置。另外,认为系统完美了才能验收的想法也是错误的,软件开发合同里一定要注明验收以后维护期的费用问题,否则,客户担心一旦验收就得不到你们的支持,自然不配合验收,那么,你这个项目经理就很难交功课了。

             最后,我想谈谈如何评价项目经理的绩效的问题,我认为,项目经理有以下几个档次: 
      *最差的项目经理:项目过程中总是出现意外,然后自己又解决不了,结果成为烈士; 
      *二流的项目经理:项目也经常出现意外,但是他一马当先,奋勇向前,解决了一个又一个问题,最后,勉强算把项目结束了,获得了领导的一致好评;

      *一流的项目经理:平时很少见他做具体的事情,整天找人聊天,然后就是写报告、做计划,最后项目顺利结束,整个过程平淡无奇; 项目管理培训
      项目管理到底是一门科学还是一门艺术呢?所谓科学就是经过反复论证,输入和输出有必然规律的东西,种瓜得瓜;而艺术就是思想火花的闪耀,主要靠灵感。项目管理这个东西,据一个前辈说,在国外是科学,80%是有规律可循的;在国内是艺术,主要靠个人魅力、感染能力等东西。看明白了PMBOK,学会了一些做事情的方式,只是搞懂了那个20%的科学的东西,还有80%的空间,属于见仁见智的领域了。所以,加强很多方面的个人能力,如练就出色沟通能力、提升自己的个人魅力对于项目经理来说是多么重要啊,无论是对内还是对外。作为一个一流的专业人士,在顺利让客户签字的同时,如何让自己的领导知道你的价值,这也是体现自己能力的一种途径。


      转载出处 http://blog.csdn.net/shimiso 

    展开全文
  • 项目管理 1

    千次阅读 2017-06-15 21:51:36
    学习内容Ø 认识毕业项目Ø 软件企业项目常见的团队和角色Ø 软件工程相关知识Ø 各种软件项目文档Ø 项目计划的制定能力目标Ø 认识毕业项目的地位和重要性Ø 了解软件企业的团队构成Ø 了解和项目开发相关...

    学习内容

    Ø 认识毕业项目

    Ø 软件企业项目常见的团队和角色

    Ø 软件工程相关知识

    Ø 各种软件项目文档

    Ø 项目计划的制定

    能力目标

    Ø 认识毕业项目的地位和重要性

    Ø 了解软件企业的团队构成

    Ø 了解和项目开发相关的软件工程知识

    Ø 了解项目文档及构成

    Ø 掌握使用Project制定项目计划


    本章简介

    这是一次实战演习,但我们保证这次实战还原了企业开发的真实环境。想知道企业中是怎样开发一个项目的么?想知道真正的项目开发包括哪些阶段么?想知道项目开发的常见进程安排(软件模型)么?想知道在真正的项目开发中什么样的人才更有价值么?请随我们经历项目开发的全过程,亲自历练,亲身体验这一切的项目过程,获得企业开发需要的最宝贵的经验。

    本章是毕业设计项目的开始,其中我们将明确本次毕业设计的目标,明确本次毕业设计的日程安排,明确毕业设计中的小组分工和角色安排,同自己所在组的组员一起讨论和实践。我们还将学习制定软件开发计划的目的、原则和步骤,然后选择自己所在小组要完成的二年项目命题,最后一起来用Microsoft Project工具制定自己二年项目的项目计划。

     


    核心技能部分

    1.1 毕业设计安排

    1.1.1 毕业项目在就业中的重要性

    学习中的时间,总是行进的很快。转眼间学员们已经在AAA软件学院经过了一年多的辛苦努力。在这段艰苦而又充实的时光中,我们学习了各种知识,可能大家会认为自己的能力已经很强——毕竟比起刚来的那段日子,我们学到了十几门不同概念、不同方向的技术。现在的我们,能够熟练地打开IDE,在很短的时间内,飞快地敲写一两个我们认为能够证明自己技术的案例,很多学员就此认为,我们的能力已经很强。学员们是否忽略了什么呢?

    多年的教育经验表明,这个时期的学员,的确容易忽略某些东西,即是否能够将所学知识融会贯通,是否学会了解决实际问题的思维方法。于是,很多人到企业才发现自己还有很多不会的东西。尤其是知识的深度和熟练程度比不上那些有工作经验的人员。

    如何弥补这个差距,提升实力呢?

    与其在正式应聘时被公司婉拒,不如应聘前做好实力提升的工作。面试时如果达不到公司的要求,是不可能得到预期的职务的。想进入企业后再去提升能力,这样的机会已经越来越少。过去的口头禅:“给我一个机会,我将还你一个奇迹”,现在已经变成了一句空口号。因为随着软件业求职人员的逐渐增多,可供选择的软件人才也越来越多,每个公司现在都有足够的资本去这样认为:过去没有累积实力的人,将来也很难表现实力。所以,现在的软件公司对应聘开发岗位的人员要求,往往都增加了“一年或多年的工作经验”这一项。

    那么企业希望招聘有项目经验的开发人员,主要是基于哪些方面考虑的呢?

    (1) 来之能战,来了就能干活。一个人把做过的事情“再重复一遍”是很轻松的事情。一般企业会给新人一个适应期,这点倒不是最重要的。

    (2) 战之能胜,写出的代码很规范,能根据模版书写简单文档,不犯初级错误。如果你在以前的经验中,把常见的错误都犯一遍了,就能在实际工作中下意识地避免,不蹈覆辙,能够解决开发过程中的常见错误。只有真正地做过一个项目才有可能知道在项目中会遇到什么样的问题,人们可能会犯什么样的错误,什么地方是应该注意的,什么地方不需要花费太多精力。其实很多问题都不仅仅是技术层面的问题,这些问题只有经过亲自历练才能体会。

    (3) 主动沟通,勇于负责。不会就问,遇到问题不自己闷着。自己在做什么,是什么进度,要主动报告给项目团队的负责人。也要主动了解别人在做什么,不做重复性劳动。学习并锻炼与各种类型、各种性格的团队成员合作的能力。就事论事,不以自己的喜好妄自论断,不把个人情绪带到工作中。

    以上这三点,其实也就是我们所说的“项目经验”了。如果一个开发人员能够满足这三点要求,我们就认为他具有了“至少一年的项目经验”。

    项目经验不是通过简单的“教”和“学”就能学到的。不下水永远学不会游泳,项目经验只有亲自参与项目,从点滴历练中积累。知识、技术和技能是其中的一个侧面,更重要的是人与人之间在责任和义务这个主题上的交流。现在,我们的毕业项目给了我们这样一个机会,一个在全真实战环境下帮助你获得项目经验的机会。

    1.1.2 毕业设计的目标

    1. 什么是项目

    我们现在要开发一个软件项目。那么什么是项目呢?

    小周每天8:30上班,17:30下班是不是项目?神舟9号飞船探月是不是项目?2008年奥运会的举办是不是项目?

    项目,其实是一个MBA课程中管理学方面的概念。项目具有如下几个特征:

    (1) 项目的一次性。一次性是项目区别于其他任务(比如:组装汽车)的基本特征。这意味着每个项目都有它的特殊之处,不存在两个完全相同的项目。

    (2) 项目目标的明确性。项目作为一类特别设立的活动有其明确的目标,一般由成果性目标和约束性目标组成。其中,成果性目标是项目的来源(比如:给中国电信的一套计费系统);约束性目标又称为限制条件,是实现成果性目标的客观条件(比如,项目开发过程中要遵循国家法律法规)和人为约束目标(比如:项目组成员的去留和项目的最后期限)的统称。项目最主要的约束目标为时间和成本。

    (3) 项目的整体性。项目是为实现目标而开展任务的集合,它不是一项项孤立的活动,而是一系列活动的有机组合,从而形成的一个完整的过程。强调项目的整体性也就是强调项目的过程性和系统性。

    通过以上几点的定义,我们看,小周每日按时上下班这一事件,因为不具有项目的“一次性”特征,不属于项目的范畴;而神舟9号飞船探月则具有典型的项目特征;2008年的北京奥运会,虽然浩大,但是也可以从中辨识出项目的诸多特征。

    项目的特征属性是项目所固有的,是区别于其他活动的根本所在。学员们在毕业设计完成的过程中,要时刻注意项目这几个特征,在约定的时间内完成一个高质量的项目!

    2. 毕业设计的目标

    通过两个学期,一个学年课程的学习,我们已经学习并掌握了网页开发、数据库、Java软件开发等技能,这一切都是为现在的毕业项目所准备的。

    通过完成毕业设计项目,我们不仅可以积累项目经验、行业经验、团队开发的经验,还可以学到实用软件工程的知识。

    一般在公司,我们做什么项目只能“服从经理安排”,可现在每个小组可以从教员老师提供的项目选择中选择适合自己小组的项目或者自己小组感兴趣的项目来实践。 

    通过参与并完成毕业设计,你能够:

    (1) 积累到项目经验。

    (2) 积累到行业经验。

    (3) 积累到团队开发经验。

    (4) 学习到实用软件工程知识。

    1.1.3 毕业设计的日程安排

    本次毕业设计,我们将分为两个阶段来进行。

    在企业中开发一个项目的时候,肯定不是上来就开始编写代码的,一般在正式开发前有一个启动和准备的阶段。在这个阶段组建软件开发项目队伍,对项目组成员进行业务上(让开发人员了解将要开发的系统的功能)和技术上的培训,确保大家都能以最好的状态投入到正式的开发工作中。

    我们的毕业设计也这样组织。

    首先,在第一阶段让大家准备好,无论是从技术上,还是团队上都准备好。在第一阶段结束的时候,小组中的每一个人都要能够熟练地运用我们提供的技术框架实现简单的增删改查功能。在这个阶段大家要互相帮助,基础好的同学要主动帮助同组有困难的同学,基础一般的同学更要积极主动,好好利用这个阶段追上大家!

    然后,在第二个阶段中全力完成项目。

    1.2 分组和组内分工

    明确了毕业设计的目标和日程安排后,你一定迫不及待地想动手开始项目了吧?别着急,二年的项目,我们是通过团队组织,分工合作来完成的。下面,我们首先来认识什么是团队。

    1.2.1 什么团队

    有人说,团队就是一群人合作做一件事情。仅仅这样就行了么?答案是否定的。在我们这里,团队的定义应该是:团队是一个由少数成员组成的小组,小组成员有着共同的目标,具备相辅相成的技术或技能,有共同的评估和做事的方法,他们共同承担最终的结果和责任。

    大海航船,难免会遭到激流与逆风的袭击。在激烈的市场竞争中,软件公司运营同样会有不测风云,比如国家政策的变化,公司骨干力量的突然出走等,都会给企业重重的一击。所以,每个公司都在进行着各种各样的建设,以增强公司的实力,保持公司可持续发展。在这当中,公司团队精神的培养是至关重要的。什么是团队精神,可谓是众说纷纭,我们认为,团队精神就是公司上下目标一致、共同奋斗、共同进退的精神。就如航行于大海中的舰队,有智慧的舰长的统一指挥,有勇敢船员的群策群力,在这艘船上,每一个人都发挥着重要的作用,所有的人都不可或缺。因此,优秀的企业家都深深地懂得团队精神的重要,任何一个成功的企业都有一个与企业文化一脉相承的团队精神。所以说,团队精神是软件产业发展的必然要求。

    1.2.2 软件项目常见的团队和角色

    现在你在备受团队精神鼓舞的同时,也许在想这样的问题:在毕业设计项目中我应该属于什么样的团队呢?

    下面,我们先给出三种常见的软件开发团队组织结构。

    第一种:小型软件公司团队组织结构。如图1.1.1所示,在小型软件公司中,人员配置精简实用。由项目经理直接带领开发经理、质量保障工程师、开发工程师和测试工程师来完成项目。

     

    1.1.1 小型软件公司团队组织结构

    这种组织结构的好处在于分工灵活,但同时每个人也是一个“多面手”,例如,开发经理既要有很强的技术,也要有相应的管理经验;软件工程师除了进行程序开发,也要懂得数据库设计开发,并且要了解一些软件测试知识。而且通常,一个人会担负多个角色,团队中的每个人几乎都要担负软件工程师和测试工程师的职责。

    第二种:微软公司团队组织结构。如图1.1.2所示,微软公司的团队组织结构可以说是相当完善了,在这种组织结构中,各团队人员分工很细致,而且职责明确,人员之间的接口明确。不过,构建这种项目团队的成本是很高的。

     

    1.1.2 微软公司团队组织结构

    第三种:大型软件公司团队组织结构,如图1.1.3所示,在这种组织结构中,人员配置比较齐备,计划/需求/设计/开发/测试/验收各个阶段都有专人负责。但同时人员组织分成了四层,比起小型软件公司团队组织结构来,管理上增加了困难。

     

    1.1.3 大型软件公司团队组织结构

    1.2.3 毕业设计项目的团队组织形式

    在本次毕业设计中,鉴于我们面临的项目,比起大型的应用系统来规模还比较小,我们的团队组织形式将采用第一种,即小型公司团队组织结构。其中每个角色的职责定义如下:

    (1) 项目经理(Project ManagerPM):项目负责人。一般来讲,项目经理的职责包括:承担责任;需求管理;协调、组织、解决团队问题;控制进度、获取并调配资源(分配任务);召集会议;做出决定;风险控制,解决危机;考核团队成员。在我们的毕业设计中,项目经理(小组长)要协调组织大家完成项目,定期检查大家的进度等。

    (2) 开发经理(Team Technology LeaderTTL):团队技术负责人。一般开发经理的职责包括:负责架构设计(技术决策);参与需求管理;在技术上训练并指导团队;召集技术会议;组织团队培训;记录团队成员技能提升等。在我们的毕业设计项目中,开发经理要主动帮助技术上有困难的同学,但不能代替对方完成任务。

    (3) 质量保障工程师(Quality AssuranceQA):一般负责配置管理,有效地控制各种项目文档和代码当前版本的唯一性;按照发布计划获得并发布版本,提交测试等。负责过程控制和质量保证的相关工作。

    (4) 开发工程师(Software EngineerSE):按照需求规格说明书的描述和项目规范开发程序代码,实现功能,修正开发过程中产生的缺陷。

    (5) 测试工程师(Testing EngineerTE):按照需求规格说明书的描述和项目规范对发布的版本软件进行黑盒测试,发现并报告软件缺陷,督促开发工程师修正缺陷。

    在本次课程中,我们将对班级成员进行分组,分组规则即小组任务如下:

    (1) 每个小组4人(特殊情况下可以3人或5人)。

    (2) 每个小组所有成员都承担开发工程师(SE)和测试工程师(TE)的职责。

    (3) 每个小组都设置一个项目经理(PM,小组长)、开发经理(TTL,技术负责人)和一个质量保证工程师(QA,负责配置管理、SVN的使用)。

     

    1.3 软件工程相关概念

    知道了项目是什么,了解了软件开发中常见的团队组织结构,对于指导我们高质量地完成项目帮助不小,但是仅仅了解这些还有些欠缺,软件开发归根结底是工程学上的一种常见的生产活动,要认识清楚软件开发全过程,并更好地指导我们开发出高质量的软件产品,我们还需要认识软件开发过程中的各种规律和常识,这就需要我们初步掌握一些软件工程方面的概念和知识。

    下面,我们就软件项目开发周期、常见的软件项目开发模式、项目开发进度和风险管理,以及软件开发过程的文档等方面,系统地介绍一些基本的软件工程常识。

    1.3.1 软件项目开发的周期

    和工程学的概念对比,研究软件工作的特点进一步打开了我们的眼界。当我们全面分析软件各个“工序”的工作时,就应该认识到程序编写只是软件工作的一个部分。在这道工序的前后均有更重要的“工序”。正如任何其它事物一样,他们从发生、发展到成熟,以至衰亡,都有一个历史发展的过程。计算机软件的生存期(Life Cycle)则包括:计划、需求分析、设计、程序编写、测试和运行维护六个步骤。这些步骤的主要任务概括如下:

    (1) 计划(Planning):确定要开发软件的总目标,给出它的功能、性能、可靠性以及接口等方面的设想。研究完成该项软件任务的可行性,探讨解决问题的方案。并且对可供使用的资源(如计算机软、硬件、人力等)、成本、可取得的效益和开发的进度做出估计,指定完成开发任务的实施计划(Implementation Plan)。

    (2) 需求分析(Requirement Analysis):对开发的软件进行详细的定义。这包括软件人员和用户共同讨论决定,哪些需求是可以满足的,并加以确切地描述。写出软件需求说明书(Software Requirement Specifications)或功能说明书(System Function Specifications)以及初步的系统用户手册(System User’s Manual),提交管理机构评审。

    (3) 软件设计(Software Design):设计是软件工程的技术核心。在设计阶段中设计人员要把已确定了的各项需求转换成一个相应的体系结构,结构中每一组成部分是意义明确的模块,每个模块都和某些需求相对应,即所谓概要设计(Preliminary Design)。进而对每个模块要完成的工作进行具体的描述,以便为程序编写打下基础,即所谓详细设计(Detail Design)。所有设计中的考虑都应以设计说明书的形式加以详细描述,以供后继工作使用并提交审查。

    (4) 程序编写(CodingProgramming):把软件设计转换成计算机可以接受的程序,即写成以某一程序设计语言表示的“源程序”。这步骤的工作也称为编码。自然,写出的程序应该是结构良好,清晰易读的,且与设计相一致的。

    (5) 测试(Testing):测试是保证软件质量的重要手段,其主要方式是在设计测试用例的基础上检验软件的各个组成部分。首先进行单元测试(Unit Testing)以发现模块在功能和结构方面的问题,其次将已测试过的模块组装起来进行组装测试,最后按所规定的需求,逐项进行有效性测试,决定已开发的软件是否合格,能否交付给用户使用。

    (6) 运行和维护(Run and Maintenance):已交付的软件投入正式使用,便进入运行阶段。这个阶段可能持续若干年甚至几十年。软件在运行中可能由于多方面的原因,需要对它进行修改。其原因可能有:运行中发现了软件中的错误需要修正;为了适应变化了的软件工作环境,需做适当变更;为增强软件的功能需作变更等。

    下图1.1.4给出了软件生存期的瀑布模型。这个模型表明,在生存期中任何一个软件都要按顺序经历上述六个步骤,如同瀑布流水,逐级下落。然而,在工程实践中,为了确保软件产品的质量,每个步骤完成以后都需要进行复查,如果发现了问题就应停止前进,沿着所经历的步骤返工。这就构成了图中各步骤间的向上流线。下图还指明了六个步骤可以划分为三个阶段,即软件定义、软件开发和软件维护。

     

    1.1.4 软件生存期的瀑布模型

    1.1.4为我们展示了软件项目开发中软件生存周期的概念,在表示软件生存期的同时,该图还为我们引出了“瀑布模型”的概念。什么是瀑布模型呢?瀑布模型,其实是常见的软件项目开发模型中的一种。软件开发模型,指定了软件生存期的各个阶段的先后顺序和时间分配。下面,我们就来看看,除了瀑布模型以外,到底还有哪些常见的软件项目开发模型。

    1.3.2 常见的软件项目开发模型

    最早出现的软件开发模型是1970年提出的瀑布模型。该模型给出了固定的顺序,将生存期活动从上一个阶段向下一个阶段逐级过渡,如同流水下泻,最终得到所开发的软件产品,投入使用。瀑布模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。

    下面我们列出一些典型的开发模型及其使用条件:

    1. 边做边改模型Build-and-Fix Model

    遗憾的是,许多产品都是使用“边做边改”模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。

     

    1.1.5 边做边改模型

    在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。

    这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都不能令人满意

    2. 瀑布模型(Waterfall Model

    1970Winston Royce提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。

     

    1.1.6 瀑布模型

    瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

    在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。

    瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:

    (1) 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;

    (2) 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;

    (3) 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

    3. 快速原型模型Rapid Prototype Model

    快速原型模型第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。

     

     

    1.1.7 快速原型模型

    通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

    显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。

    快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。

    4. 增量模型Incremental Model

    增量模型又称演化模型。与建造大厦相同,软件也是一步一步建造起来的,在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

     

    1.1.8 增量模型

    增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:

    (1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。

    (2) 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。

    在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。

    5. 螺旋模型Spiral Model

    1988年,Barry Boehm正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。

     

    1.1.9 螺旋模型

    螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:

    (1) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;

    (2) 风险分析:分析评估所选方案,考虑如何识别和消除风险;

    (3) 实施工程:实施软件开发和验证;

    (4) 客户评估:评价开发工作,提出修正建议,制定下一步计划;

    螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:

    (1) 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。

    (2) 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。

    (3) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险。

    一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。

    6. 喷泉模型Fountain Model

    喷泉模型,又称为面向对象的生存期模型,OO模型。

     

    1.1.10 喷泉模型

    喷泉模型与传统的结构化生存期比较,具有更多的增量和迭代性质,生存期的各个阶段可以相互重叠和多次反复,而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来,可以落在中间,也可以落在最底部。

    7. 混合模型Hibred Model

    过程开发模型又叫混合模型(hybrid model),或元模型(meta-model把几种不同模型组合成一种混合模型,允许一个项目能沿着最有效的路径发展,这就是过程开发模型(或混合模型)。实际上,一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型

    8. 敏捷开发

    虽然我们在上面列出了众多的软件开发模型,但是其中产生历史最悠久,使用最普遍的还是瀑布模型及其简单的变型。随着软件工程理论的发展和新的软件开发思想的产生,以瀑布模型为代表的经典的软件开发模型,正在逐步的被以敏捷开发为首的新的软件开发思想和方法所代替。

    那么,什么是敏捷开发呢?瀑布模型中,如果需求变更比较频繁,初期付出众多工作量的需求、设计常常被不断返供,进而又引发编码返工,造成成本上升。敏捷开发解决这个问题的方法很简单:减少早期对需求、设计的投入,尽量早让产品“可运行”,以便让客户提出反馈意见。但要避免这种方法被用过头,比如放弃了必要的需求和设计就得不偿失了。正确的做法是:在渐进式开发、渐进式交付的同时,做渐进式需求和设计。我们避免的是需求和设计的返工,而不是需求和设计活动本身。

    下面列出敏捷开发过程中的一些重要思想:

    (1) 并行创建模型。由于每种模型都有其长处和短处,没有一个模型能够完全满足建模的需要。敏捷建模者会发现在任何时候,同时进行多个模型的开发工作,要比单纯集中于一个模型要有效率的多。

    (2) 创建简单的内容。应该尽可能的使模型(需求、分析、架构、设计)保持简单,但前提是能够满足项目组中相关的其他人员(project stakeholder)的开发需要。

    (3) 小增量建模。采用增量开发的方式,可以把大的工作量分成能够发布的小块,每次的增量控制在几个星期或一两个月的时间内,促使你更快的把软件交付给用户,增加了开发的敏捷性。

    (4) 和他人一起建模:结对编程。当有目的建模时我们会发现,建模可能是为了了解某事,可能是为了同他人交流想法,或是为了在项目中建立起共同的愿景。这是一个团体活动,一个需要大家有效的共同工作才能完成的活动。我们会发现开发团队必须共同协作,才能建立一组核心模型,这对我们的项目而言是至关重要的。例如,为了建立系统的映像和架构,需要和同组成员一起建立所有人都赞同的解决方案,同时还要尽可能的保持它的简单性。大多数时候,最好的方法是和另一些人讨论这个问题。

    (5) 使用最简单的工具。大多数的模型都可以画在白板上,纸上,甚至纸巾的背面。这样做是因为大多数的图表都是可以扔掉的,它们只有在你画出模型并思考一个问题的时候才有价值,一旦这个问题被解决了它们就不再有意义了。

    (6) 永远也别忘了用迭代的方法开发软件(这是大多数项目的标准做法),也别忘了建模只是众多任务中的一个。做一会儿建模、做一会儿编码、做一会儿测试(在其它的活动之中进行)。

     

    各种模型的比较:每个软件开发组织应该选择适合于本组织的软件开发模型,并且应该随着当前正在开发的特定产品特性而变化,以减小所选模型的缺点,充分利用其优点。

    1.3.3 项目开发的进度管理

    1. 为什么需要进度管理

    在软件项目的管理者眼中,软件项目有三个目标:质量、进度和成本。在1997年有研究机构曾对Dr. Frame美国项目管理协会成员的438位项目工作人员进行过一次调查,调查的结果如下:

    (1) 质量方面(符合需求和项目规范的程度)

    Ø 相差甚远者29%

    Ø 完全达到规范要求51%

    Ø 实际执行超出规范要求20%

    (2) 进度方面

    Ø 严重拖期35%

    Ø 一定程度拖期34%

    Ø 按时完成22%

    Ø 一定程度提前8%

    Ø 大量提前1%

    (3) 成本方面

    Ø 严重费用超支17%

    Ø 一定程度费用超支38%

    Ø 安全按预算执行27%

    Ø 一定程度费用结余12%

    Ø 大量费用结余6%

    从上面的数据我们可以看到,大多数的软件项目都不能在预定的成本范围内按时按量地完成,这是和软件项目自身的特点有关系的。

    首先,软件项目进度的“可视度”不如传统项目。比如一个项目,一个任务分配下去后,过了一段时间,我们去问开发人员,“完成多少了?”开发人员说,“还有一天就做完了。”过了一天又问,回答说,“下星期一提交”。到了下星期一再问,可能回答说,“再两三天吧,有两个Bug(系统缺陷)要改过来……”

    一个包含了几百个任务点的项目,你能一眼看出来进度是多少么?当前是进度超前了还是滞后了?

    其次,软件项目质量的“可视度”不如传统项目。请看这个场景:开发人员终于把这个模块完成并提交了。这是问开发人员,“做的是否符合需求?”开发人员回答说,“严格符合!”结果一测试,漏洞百出,又多花了一个星期修改。

    为什么会出现上面的差错?因为软件项目的真实进度保存在开发人员的大脑中。如果不采用专门的测试和追踪技术,我们很难直观地看到软件项目进行了多少,完成的质量如何。即使我们可以了解某个功能点,某个模块的进度,我们又如何获得整体进度的信息呢?

    我们怎样能知道系统是否可以如期交付呢?

    当项目可能延期时,我们可以采取哪些措施来挽救呢?

    要解决这些问题,我们就需要做软件项目进度管理。

    2. 什么是进度管理

    首先,对项目开发过程进行进度追踪有个前提,就是明确的软件计划。

    在制定软件开发计划的时候,要注意制定软件开发计划的“有效追踪原则”,要求每个计划中的任务点都要确定几日内完成。这样我们就能及时地发现哪个任务点延期提交了,从而做出调整。

    其次,我们要明确一个概念:怎样才算一个任务点“完成”了。

    如果单凭开发人员一句话:“开发完成了”,就是真的完成了么?

    事实不是这样的。一般地,一个任务点,当开发工程师完成编码后首先要自己运行程序,检查程序实现的功能点是否符合需求,代码是否符合规范。如果不符合就修改程序,直到自己满意了,再将工作成果提交到版本控制服务器上(如SVN)。这时候,我们只认为这个任务的进度是50%

    项目组按照发布计划定期将项目程序发布到测试服务器上,供测试工程师测试。如果测试出Bug(正确的说法应该是软件“缺陷”),将创建“缺陷报告”,要求开发工程师修改,这时我们认为这个任务点的进度是80%。最后等业务负责人(可能是项目经理、需求工程师、业务咨询或客户经理)确认验收,这时候才算这个任务点真正完成了。

    进度管理不仅要对软件项目的进度负责,而且要对产品质量和成本负责。做出来的东西没用,或者入不敷出,软件产品的意义就失去了。

    最后,当发现进度异常时,我们可以通过采取一些措施,把进度拉回正常的轨道上。

    对软件项目的进度进行检查和监控,从而发现可能的或已经发生的进度滞后问题并采取措施调控,以保证软件项目的进度、成本和软件产品的质量,减少损失的管理活动,称为软件项目的进度管理。

    3. 如何进行进度管理

    软件项目进度管理的管理技术和有效实践包括以下几点:

    (1) 在获得开发工程师的承诺的基础上指定合理可行的软件开发计划。这是前提。

    (2) 随时获得每个任务点以及整体项目的进度数据。

    对每个任务点的完成情况进行追踪,随时了解每个任务点的进度数据。然后再根据各个任务点的权重,就可以计算出整体项目的进度。比如,某项目包含ABCD四个任务点。权重各为25%AB开发工程师已经提交,正在测试,进度为50%C已经经过了项目经理的确认,进度为100%D还在开发规程中,进度为0%。那么项目的整体进度就是:

    50% × 25% + 50% × 25% + 100% × 25% + 0 × 25% = 50%

    就是说,开发工作只完成了一半!虽然4个任务点已经“完成”了3个,但有两个未通过测试,所以进度并不像表面看上去那么乐观。使用Microsoft Project工具可以轻松地得到这方面的信息。在规模不大的项目中,我们使用Microsoft Excel表格中的公式功能也可以做到自动计算项目的整体进度。

    (3) 优先保证“关键路径”上任务点的完成。

    由于在不同任务点之间存在着前后制约的关系,在某些任务点完成之前,特定的任务点是无法开始开发的。比如:在分层开发的过程中,在DAO类没有开发完成前,业务逻辑类的开发是无法开始的。这样系统中存在先后关系的任务点就能串成一条条线,单条线上的任务点一定要“依次”完成,而且每个任务点都有工时的要求(在几天之内完成)。这些线中最长的一条就决定了项目开发至少所需要的时间,这条线称为项目的“关键路径”。

    如果关键路径上的某个任务点延期,会造成其后一系列任务的延期,因此要优先保证完成关键路径上的任务点。

    (4) 当进度异常时,我们可以采取的措施包括“快速跟进”和“赶工”。

    当两项(或多项)任务可以同时进行的时候,那就增加人手,让两项(或多项)任务同时进行,从而加快项目进度,这称为“快速跟进”。由于多项任务同时进行,增加了沟通和控制管理的难度,也容易带来风险。

    如果任务处在关键路径上,或由专人负责的,别人无法插手,那采取快速跟进的方法就不适合。这时候也只好让任务负责人加班了,这种方式称为“赶工”。赶工会带来成本的增加(总要付加班费、吃加班餐或提供配套的福利吧)。

    人的精力毕竟是有限的,“快速跟进”的方式看上去更容易做到一些。因此在做项目计划的时候就要考虑这方面的需要。不要将某个任务点分配给“专人”来完成,在兼顾效率的基础上尽可能地让开发人员互相了解其他人的工作内容,以便需要的时候可以互相顶换。

    (5) 项目进度再紧张,也要“以人为本”。

    如果软件项目进度太紧,参与的人都很疲惫,纷纷离开项目组,那就得不偿失了。

    因为当项目结束的时候,一个默契合作、士气高涨的团队将是项目的重要收获之一。有的时候,甚至比项目的成败还要重要。是把人拼光了赢得战斗的胜利,还是保全实力,以利再战,这本来就是很难抉择的事情。当然,追求胜利在软件开发过程中使我们生存的根本,但也千万不要眼中只有胜利而无其他。

    (6) 身处项目组中的“我”,要怎样做?

    如下Excel表格表达了我们项目进度的一种管理方式。图中的表格是用来进行进度管理的。每个任务点有三个状态:未开始、延期和已完成。通过修改功能点的状态信息,就可以自动计算出每个人的总体进度和整个项目的总体进度。

     

    1.1.11 进度管理表格

    我们在项目中要发挥自己最大的主观能动性。让自己从项目中有所收获,而且乐在其中。人都有被认同的渴望,都有提升自身价值的需要,我们要调整自己的心态,从每各项目中都得到提升和自我价值的彰显。

    即使在最险恶、最无助的环境中,也不要放弃对战友的责任。在这个世界上,没有不需要流血牺牲便能获得的胜利,没有不需要熬煎等待便获得的成功,没有不需要誓死奋争便获得的自由。“扎实做事便成功,努力专心便胜利,持之以恒便卓越”,是永恒的主题。

    1.3.4 项目开发的风险管理

    1. 为什么需要风险管理

    风险总是伴随着利益,风险越大利益也就越大。我们不鼓励铤而走险,但我们也不会见了风险就挥动白旗。如果一个企业只做有把握的事,也就意味着它绕开了所有利益,其结局只能是:颗粒无收。在软件项目中,风险是回避不了的。

    风险不会因为我们没有看到或者装作没有看到就不存在了。我们不应该惧怕风险,但也不要无知到忽视它。和故事中的旧船航海一样,软件项目中同样存在各种各样的风险。

    Ø 进度落后:合同上签订今年9月项目验收,现在都8月底了,测试人员刚刚把厚厚的一打Bug清单交给项目经理。整个项目组在剩下的时间里通宵达旦的修改都未必能完工。

    Ø 需求膨胀:客户已经在需求规格说明书上签字了,项目稳扎稳打地进行着,项目组已经完成了概要设计,正准备开始详细设计。这时,客户突然发来了一封邮件,要求将系统的一些主要功能大改。

    Ø 人员流失:小王前两天情绪低落,大家都没有在意,今天早晨上班的时候小王突然向项目经理提交了辞职信。小王可是项目组的主力,他走了之后,项目组中无人能接手他的工作。

    上述这些风险中,有的可以让项目组一时手忙脚乱,有的可以使整个项目全盘皆输。所以我们要学会识别风险,管理风险。这,也是从事我们这个行业必修的基本功之一。

    2. 什么是风险管理

    首先,我们先明确一下风险和风险管理的概念。

    Ø “确定”,是指所有信息都是可用的,对结果的预言比较有把握。

    Ø “不确定”,即没有信息,对可能的结果一无所知。

    Ø “风险”,一种不确定的事件或条件,一旦发生会对项目产生正面或负面的影响,它既包括对项目目标的威胁,也包括对这些目标进行提高的机会。即“确定”中可能出现的“不确定”。软件项目最常见的风险是:需求膨胀或变更,还有就是人员变动。人员变动包括人走,也包括人来。新人加入团队在一定时间内肯定会造成效率的损失。

    Ø “风险管理”,就是对风险进行识别、分析和应对的过程。

    所以,软件项目风险管理工作的主要内容就是:对项目中的不确定因素进行识别、分析、指定应对措施,并进行跟踪控制,以提高软件项目的成功几率。

    3. 如何进行风险管理

    软件项目的风险管理是一个相对专业的管理领域,有着一整套的理论和方法。

    这些风险管理技术包括风险识别技术、风险定性分析技术、风险定量分析技术、常见的应对策略和记录、跟踪的方法。

    (1) 风险识别技术:显然,对风险进行管理的前提是识别风险。对于已经识别的风险,我们可以制定计划进行管理;对于未知风险,那无法管理。我们可以借助文件审核、按照清单逐项检查、尽量收集信息(以头脑风暴、访谈、SWOT等方式)、做假设分析,以及采用专门的图解技术(如因果图、系统流程图、影响图)等方法来发现风险。

    (2) 风险定性分析技术:对已经发现的风险,还要进行分析,从发生的概率和如果发生造成的严重后果来分类、排序。

    (3) 风险定量分析技术:对每项风险的发生概率和影响,以及整个项目的整体风险程度进行数值分析。常采用的方法包括访谈、敏感性分析、蒙特卡罗分析和决策树等。

    (4) 应对策略:常见的应对策略有4种。

    Ø 回避(Avoidance):比如缩小范围,某些不重要的功能先不实现了,保证核心业务的稳定运行;比如增加资源(一般情况下指增加人手);比如用熟悉的方法,如果大家都更熟悉MS SQLServer,那就先别用Oracle

    Ø 转嫁(Transference):比如本公司(或部门)擅长做金融行业的项目,新签到的项目包含“人力资源管理”的内容,本公司(或部门)不擅长,那就签订分包合同,包给擅长的公司(或部门)做。

    Ø 减轻(Mitigation):当大方向难以扭转的时候,多一份努力就离正轨近一些。比如项目很难按期交付,逾期1天需要向客户赔付2万元。那就一方面尽可能加快项目开发,尽可能提早完成;同时积极同客户进行商务谈判,求得谅解,请求客户同意降低赔付金额。

    Ø 接受(Acceptance):对于“不可抗拒”的情况,只能“尽人事,安天命”。如果客户方数据非常宝贵,作为维护合同的重要内容,我们有保护客户方数据的义务。这时候火山、地震、洪水、飓风、战争等情况就是我们可能面对的风险。当然,几率太小的不需要纳入管理。我们对无法抗拒的威胁还是有事情可做的,那就是制定应急计划,规划好当事情真正发生了,我们有哪些可以做。比如上面的情况,我们可以设定数据库每天自动备份到另外一块磁盘,每周进行一次异地备份。这样,我们虽然不能阻止火山的喷发,但即使火山喷发了,我们也有避免(或降低)损失的办法。我们“接受”我们改变不了恶劣天气的事实,但是如果我们准备好了恶劣天气来临时的应对措施,就能尽可能地降低损失。

    (5) 记录、跟踪:对于每个可能发生的危险,我们都要予以记录,并随时对风险的状况进行追踪。下面就是一个用于风险记录和追踪的表格的示例,如图1.1.12所示。

     

    1.1.12 风险记录和追踪

    这样,我们就可以把风险管理落到实处,使之真正地发挥作用。

    1.4 软件开发过程中的文档

    1.4.1 什么是文档

    软件文档(document)也称文件,通常指的是一些记录的数据和数据媒体,它具有固定不变的形式,可被人和计算机阅读。它和计算机程序共同构成了能完成特定功能的计算机软件(有人把源程序也当作文档的一部分)。我们知道,硬件产品和产品资料在整个生产过程中都是有形可见的,软件生产则有很大不同,文档本身就是软件产品。没有文档的软件,不能称为软件,更谈不上是软件产品。软件文档的编制(documentation)在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量的开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用软件,对于充分发挥软件产品的效益有着重要意义。

    1.4.2 文档的分类

    文档在软件开发人员、软件管理人员、维护人员、用户以及计算机之间的多种桥梁作用可以从下图1.1.13中看出。

     

    1.1.13 软件开发文档的桥梁作用

    软件开发人员在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据,这个作用是显而易见的。软件开发过程中软件开发人员需制定一些工作计划或者工作报告。管理人员则可以通过这些文档了解软件开发项目安排、进度、资源使用和成果等。软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料,我们称此为用户文档。以上三种文档构成了软件文档的主要部分。我们把这三种文档所包括的内容都列在下图1.1.14中。其中列举了十三种不同的文档,下面是这些文档的简要说明。

     

    1.1.14 软件文档的三种分类

    (1) 可行性研究报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施的方案,说明并论证所选定实施方案的理由。

    (2) 项目开发计划:为软件项目实施方案制定出具体计划,应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。项目开发计划应提供给管理部门,并作为开发阶段评审的参考。

    (3) 软件需求说明书:也称软件规格说明书,其中对所开发软件的功能、性能、用户界面及运行环境等做出详细的说明。她是用户与开发人员双方对软件需求取得共同理解的基础上达成的协议,也是实施开发工作的基础。

    (4) 数据要求说明书:该说明书应给出数据逻辑描述和数据采集的各项要求,为生成和维护系统数据文卷做好准备。

    (5) 概要设计说明书:该说明书是概要设计阶段的工作成果,它应该说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计奠定基础。

    (6) 详细设计说明书:着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。

    (7) 用户手册:本手册详细描述软件的功能、性能和用户界面,使用户了解如何使用该软件。

    (8) 操作手册:本手册为操作人员提供该软件各种运行情况的有关知识,特别是操作方法的具体细节。

    (9) 测试计划:为做好组装测试和确认测试,需为如何组织测试指定实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则,测试结果允许的偏差范围等。

    (10) 测试分析报告:测试工作完成以后,应提交测试计划执行情况的说明。对测试结果加以分析,并提出测试的结论意见。

    (11) 开发进度月报:该月报系软件人员按月向管理部门提交的项目进展情况报告。报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。

    (12) 项目开发总结报告:软件项目开发完成以后,应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力。此外还需要对开发工作做出评价,总结出经验教训。

    (13) 维护修改建议:软件产品投入运行以后,发现了需对其进行修正、更改等问题,应将存在的问题、修改的考虑以及修改的影响估计作详细的描述,写成维护修改建议,提交审批。

    以上这些文档是在软件生存期中,随着各阶段工作的开展适时编制。其中有的仅反映一个阶段的工作,有的则需跨越多个阶段。下图1.1.15给出了各个文档应在软件生存期中的哪个阶段编写。

     

    1.1.15 软件生存期各阶段编制的文档

    1. 文档说明的问题

    上述13种之多的文档,最终要向软件管理部门,或者是用户回答以下的问题:

    Ø 哪些需求要被满足,即回答“要做什么?”

    Ø 所开发的软件在什么环境中实现以及所需要的信息从哪里来,即回答“从何处?”

    Ø 某些开发工作的时间如何安排,即回答“何时做?”

    Ø 某些开发(或维护)工作打算由“谁来做?”

    Ø 某些需求是怎么实现的?

    Ø 为什么要进行那些软件开发或维护修改工作?

    上述13个文档都在一定程度上回答了这六方面的问题。文档所回答的问题见图1.1.16

     

    1.1.16 文档所回答的问题

    1.5 软件开发计划

    通常的软件项目都是以组建团队为项目启动的第一件事情,接下来要做的就是制定项目计划。

    做计划的时候,我们可以根据以往的经验,估计这个项目要用多少人,多少时间。然后作一个详尽的安排出来,具体到哪个人哪天做什么事情。这样,我们可以按照这个计划有条不紊地完成项目,公司也可以按时地把资源(主要是人员、服务器等)分配给项目组。

    计划,在软件开发中起到冷静、理智地分析项目完成状况,分担项目完成压力的作用。假如你有个很紧的“最终期限”,但是只要你做了计划,并且计划显示你能够在期限前完成,那么你就会在很紧张的气氛中开始第一项任务,并且尽可能地保证质量。毕竟,(计划显示)你有足够的时间。这正是使计划实现的重要因素。恐惧和没有细致的行动方案,只会造成思维迟钝、出错、沟通崩溃。

    我们做计划的原因是:

    (1) 确保我们一直在做需要做的事情中最重要的那件。

    (2) 我们需要和他人合作。

    (3) 当发生意外事件时,需要知道对以上两条会造成什么样的影响。

    (4) 计划可以帮助我们有效地协调使用资源,帮助我们对项目进行有效地控制,及时地发现问题,解决问题。

    管理学上有一则有名的公式:管理 = 计划 + 追踪 + 调控。计划是管理活动开展的前提。这个公式离我们不远,无论我们做什么事情,利用这个公式都可以规范我们的工作。

    一个好的计划是把事情做好(完成项目)的前提,在此基础上,我们还要不断地确认(追踪)关键事件(里程碑)的完成情况,看事情是否按安排在进行,如果有意外发生,要立即想办法解决(调控)。

    1.5.1 制定软件开发计划的步骤

    同样作为项目,软件项目与工程项目却有很大的不同,他们有以下不同点:

    (1) 软件项目的“可视性”不如工程项目。

    (2) 软件项目的复杂度大大超过工程项目。

    (3) 软件项目需要有创造性的智力劳动,更难预测和控制。

    下面我们就以“软件开发计划”为例,学习软件项目中计划是如何制定的。

    制定一个成功的软件开发计划,要遵循特定的步骤。制定软件开发计划的步骤如下:

    (1) 划分任务点。

    一个项目可以看作是一个大任务,将大的任务进行分解,一直到我们可以估计的程度,就可以做出项目计划。把大任务分解成多个小任务,可以帮助我们进行更加精确的估计,暴露出在其他情况下可能没有想到的工作活动,并且保证可以完成更加精确、细密的状态跟踪。

    项目管理把工作任务的这种划分叫做“工作分解结构(Work Breakdown Structure, WBS)”,它是一种逐步明确和解决问题的基本思路,一个庞大的,模糊不清的任务或者问题肯定难以解决,只有把它细分成可以看清楚的、明确的小任务或者工作项才能够明确,并加以管理。

    制定项目计划,必须制定一个工作分解结构(即使是非IT方面的工作项目也是如此),这是前提,基于此才谈得上真正意义上的实施和控制。

    (2) 分配资源。

    划分好任务点后,接下来就要给每个任务点指定人手和必需的设备、物资了。完成任务必需的人手、设备和物资统称为“资源”。

    由于现在只是计划阶段,并不是真正的分配资源,但我们可以从全局的角度看一下资源分配是否合理,到需要的时候资源是否能够到位。从而避免资源过度使用或浪费的情况。

    我们分配资源(主要是人手)的时候,不仅要指定“谁”,还要明确完成某个任务点的开始时间和结束时间。

    项目计划中的每个计划项都要明确:“什么任务”、“谁”和“完成任务的起止时间”。

    完成这步工作后,我们能够知道这个项目需要多少人,多少时间完成了。项目计划开始实施后,我们还要逐项追踪,看看是否按计划执行了,如果有出入要及时调整。

    那是不是说到这步我们已经完成项目计划的制定了呢?还不是,我们还缺少至关重要的一步,那就是获得开发工程师承诺。

    (3) 获得开发工程师承诺。

    项目经理制定计划的时候更多地是依靠自己的经验,他可能安排一个开发工程师用1个工作日完成“合同变更”的详细设计文档。基本上这是合理的。但开发工程师可能有自己的特殊情况,比如刚入职,对技术框架和业务都不太熟悉。需要先阅读相关文档,或者还没有从另外一个项目中完全撤出来,只能将50%的时间投入到这个项目上等等。

    如果项目经理只凭自己的主观判断制定计划的话,那这样的计划在实施的时候阻力会很大。这就要求开发工程师本人对项目经理或开发经理分配给自己的任务表示同意,也就是“做出承诺”。

    但一般情况下,当一个团队长期合作,彼此了解的时候,不再需要逐项确认计划是否合理。但项目经理(或开发经理)制定出开发计划后都会在正式发布前留一个反馈的时间,以便提前发现计划中不合理的部分并进行调整。

    但一旦开发计划发布并开始实施后,就要严格遵守。开发工程师就要对自己承担的任务负责。

    1.5.2 制定软件开发计划的原则

    制定软件开发计划除了要遵循特定的步骤外,还要遵守一定的原则。

    (1) 有效追踪原则

    有效追踪原则是对任务点的划分而言的,指的是在划分任务点时,粒度要适中。

    粒度太大,追踪的效果就差;粒度太小,效率就太低。一般软件开发任务点所用的工时控制在1~3个工作日是比较适中的。

    (2) 共同参与原则

    不是项目经理(PM)一个人的事件,需要相关人员一同参与。

    项目相关人员要共同估计工作量,并做出承诺。

    一般概念中,任务安排和计划是经理的事,员工只管执行就是了。但在软件开发中采取更合理的做法是:制定计划时相关人员也参与进来。这在制定计划的“获得参与人员承诺”步骤中可以体现出来。

    当一个计划涉及很多人、很多事的时候,我们必须采用一个有效的工具来帮助我们制定计划。下面我们就来学习使用Microsoft Project 2003来为“权限管理系统”制定项目计划。

    1.5.3 使用Project工具制定“权限管理系统”项目计划

    Microsoft Office Project Professional 2003Microsoft提供的企业管理工具产品的一员,是一个专业的项目管理软件。它可以帮助我们管理项目,用于安排任务,制定计划和分配资源,还可以监视项目的进展和进度,以图形化的方式显示哪些工作完成了、哪些还没有完成以及完成的百分比,以有效地组织和跟踪任务和资源,使项目在预算范围内按时完成。

    下面,我们使用Project Professional 2003制定“权限管理系统”项目计划。

    我们首先看一下项目的需求。

    盛世西游科技发展有限公司项目组人员组织结构图如图1.1.17所示。

    最近公司承接了一个权限管理系统项目,项目组5个人中,除项目经理唐三藏外,其余4人每个人在图中所示的原角色的基础上再担任软件工程师和测试工程师两个角色。

     

    1.1.17 盛世西游科技发展有限公司项目开发组人员组织结构图

    客户对系统的要求如下:

    权限管理系统应能进行用户管理和角色管理,能为角色分配权限,同时也能将角色赋予用户。

    开发经理孙悟空通过与用户沟通,并对需求进行分析,明确了以下需求:

    权限管理系统整体上分为4个模块:用户登录模块、用户管理模块、角色管理模块和生成菜单模块。其中,用户管理模块包括增加用户、删除用户、修改用户、查询用户、查看用户和角色分配6项功能。而角色管理模块包括增加角色、删除角色、修改角色、查询角色、查看角色和权限分配6项功能。

    盛世西游科技发展有限公司项目组5位成员开始共同参与,用Project Professional 2003制定权限管理系统项目开发计划。

    1. 使用Project Professional 2003创建项目文件

    要在Project Professional 2003中创建项目计划,可执行以下步骤:

    (1) 创建项目文件

    准备项目日程的第一步是创建项目文件。

    1) 启动Microsoft Project Professional 2003

    2) 新建一个项目,以[权限管理系统]项目计划”为名保存此文件。

    此项目文件名为[权限管理系统]项目计划.mpp”,在窗口的左边出现“任务”窗口,指导项目创建的过程,相当于一个向导,如图1.1.18所示。

     

    1.1.18 新建项目“[权限管理系统]项目计划”

    (2) 填写项目信息

    在创建项目文件之后,便可使用文档记录项目的相关信息。为此,需要在“属性”对话框的“摘要”选项卡中填写详细信息。

    1) 选择“文件”à“属性”命令,在弹出的对话框中选择“摘要”选项卡。

    2) 添加表1-5-1中的信息。

    1-5-1 权限管理系统项目详细信息

    标  题

    “权限管理系统”项目计划书

    主  题

    “权限管理系统”项目计划

    作  者

    孙悟空

    经  理

    唐三藏

    单  位

    盛世西游科技发展有限公司

    类  别

    权限管理系统

    关 键 词

    用户 角色 权限

    备  注

     

    该系统具有一定的通用性,可用于不同系统的权限管理模块,可以在这个系统基础上继续开发完成其它业务系统

    属性对话框如图1.1.19所示。填写完成后,单击“确定”按钮。

     

    1.1.19 “权限管理系统”项目计划属性

    2. 划分任务点

    创建项目任务是输入项目中的“活动”。默认情况下,任务以“天”为单位。

    将表1-5-2中的任务全部添加到任务列表中,最终效果如图1.1.20所示。

    1-5-2 创建任务并制定任务工期

    任  务  名  称

    工  期

    (1) 需求分析

    3个工作日

    (2) 概要设计

    2个工作日

    (3) 详细设计

    默认

     

    1.1.20 创建任务并指定任务工期

    1.1.20中,创建好项目任务,分配好各任务工期后,在任务表格的右端,出现了包含有蓝色条状图形的进度表示图:甘特图。

    注意:

    甘特图的来历:

    甘特图(Gantt chart)又叫横道图、条状图(Bar chart)是一种按照时间进度标出工作活动,常用于项目管理的图表。

        甘特图是在第一次世界大战时期发明的,以亨利·L·甘特先生的名字命名,他制定了一个完整地用条形图表示进度的标志系统。甘特图内在思想简单,即以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。基本是一条线条图,横轴表示时间,纵轴表示活动(项目),线条表示在整个期间上计划和实际的活动完成情况。它直观地表明任务计划在什么时候进行,及实际进展与计划要求的对比。管理者由此可便利地弄清一项任务(项目)还剩下哪些工作要做,并可评估工作进度。

     (1) 创建子任务

    一项任务可拆分为多个小任务或子任务。为“权限管理系统”项目的“3. 详细设计”任务添加表1-5-3中的两个子任务。

    1-5-3 创建任务并制定任务工期

                 子任务名称

    工    期

    3.1 用户管理模块(增加、删除、修改)

    3个工作日

    3.2 用户管理模块(查询、明细)

    2个工作日

    1) 在任务3. 详细设计”下方添加表1-5-3中的两个任务。

    2) 选中新添加的两个任务,在右键菜单中选择“降级”子菜单。这就创建了两个子任务,如图1.1.21所示。

     

    1.1.21 创建子任务

    (2) 前置任务

    任务列表中的“前置任务”可用于设置任务的相关型,即制定任务的执行顺序,如图1.1.22所示,任务21. 需求分析”必须在任务32. 概要设计”前完成,则将任务3的前置任务设置为“2”。同理,将任务5的前置任务设置为“3”,将任务6的前置任务设置为“5”。

     

    1.1.22 为任务设定“前置任务”

    3. 为项目分配资源

    我们在前面介绍过,资源可以是用于执行一项任务必需的设备、物资或人员。在软件开发过程中,最主要的资源就是人员。

    资源一般分为如下两类:

    Ø 材料资源:只用于完成一项任务的消耗品

    Ø 工时资源:指按照工作时间来计算的资源,例如人员以及执行任务所需的设备。

    资源的度量单位:

    Ø 对于工时资源,最大单位表示该资源可用于项目的时间,使用百分比定义的。例如,拿项目开发组长唐三藏这个“工时资源”来说,唐三藏总的工作时间为100%(最大单位)。

    Ø 在向任务分配资源时,分配单位是“该资源可以用在任务上的时间”占“该任务所需总时间(100%)”的百分比。例如,要求孙悟空和白龙马两人共同完成需求分析任务(100%),并且孙悟空使用50%的时间做设计,白龙马也使用50%的时间做设计。

    (1) 排定资源

    为了将资源分配到任务点,我们首先要在项目中定义资源。列一下项目中我们将用到哪些资源,并设定这些资源的相关属性。在Project 2003中进行如下操作。

    1) 选择“视图”à“资源工作表”命令,出现“资源工作表”视图。

    2) 将表1-5-4中的信息添加到“资源工作表”中。

    1-5-4 创建任务并制定任务工期

    资源名称

    类型

    缩写

    最大单位

    标准费率

    加班费率

    成本累算

    基准日历

    唐三藏

    工时

    三藏

    项目研发部

    100%

    64.00/h

    60.00/h

    按比例

    标准

    孙悟空

    工时

    悟空

    项目研发部

    100%

    ¥54.00/h

    60.00/h

    按比例

    标准

    猪悟能

    工时

    悟能

    项目研发部

    100%

    ¥44.00/h

    60.00/h

    按比例

    标准

    沙悟净

    工时

    悟净

    项目研发部

    100%

    ¥34.00/h

    60.00/h

    按比例

    标准

    白龙马

    工时

    白龙

    项目研发部

    100%

    ¥84.00/h

    ¥80.00/h

    按比例

    标准

    添加结果如图1.1.23所示。

     

    1.1.23 为项目排定资源

    (2) 为项目分配资源

    1) 在任务列表中,选择任务1. 需求分析”。

    2) 选择“工具”à“分配资源”命令。

    3) 将孙悟空和白龙马分配给任务“需求分析”,每人的单位都是50%。如图1.1.24所示。

     

    1.1.24 为任务“1. 需求分析”分配资源

    4) “权限管理系统”项目的其余任务分配资源,如图1.1.25所示。

     

    1.1.25 为其余任务分配资源

    4. 设置项目里程碑

    要设置项目里程碑,我们首先要了解里程碑的概念。什么是里程碑呢?

    里程碑本来是指标志公路及城市郊区道路里程的碑石。每一千米设一块,用以计算里程和标志地点位置。我们在路上行走的时候,会不时地在沿途观看路标,我们便知道还有多少路或多少时间才能够到达终点。

    在软件项目开发中,里程碑是标志项目重大事件的参照点,用于识别项目日程中的重要阶段。

    一般在需求分析阶段完成后,我们需要对需求进行一次评审。评审组由项目组成员与客户代表团两组人员组成,到时客户方会对需求规格说明说进行确认,不明确的地方由项目经理做出解释。

    需求评审通过称为“需求确认”,此时我们认为“需求确认”就是一个里程碑。因为这对于客户和项目组的意义都是很重大的。对客户,是要让客户知道“我们项目组已经完全理解你要做什么了”,快签字确认吧;对项目组,意味着“客户已经确认需求了,我们可以开始动手做设计了”。这个里程碑是一个明确的分界点,代表着需求分析阶段的结束,设计阶段的开始。

    里程碑并不消耗项目的时间,将任务的工期设置为零(0)可创建里程碑。下面我们就来在“权限管理系统”项目中创建“需求确认”这个里程碑。

    1) 选中任务2. 概要设计”。

    2) 选择“插入à新任务”命令,将新任务命名为“需求确认”。

    3) 将任务“需求确认”工期设置为0,如图1.1.26所示。注意,此任务在甘特图上的图形为菱形。

     

    1.1.26 为项目设置里程碑

     

     

     


    任务实训部分 

    实训任务1:甘特图

    训练技能点

    Ø 甘特图的绘制

    需求说明

    继续权限管理系统工作计划甘特图的绘制。

    实现思路

    (1) 分析权限管理系统的功能需求

    (2) 确定每个阶段的工期

    (3) 确定每个具体功能的工期

    (4) 绘制权限管理系统工作计划甘特图

    关键步骤

    绘制权限管理系统工作计划甘特图,如图1.2.1所示。

     

    1.2.1 权限管理系统甘特图

    实训任务2:为甘特图添加里程碑

    训练技能点

    Ø 为工作计划甘特图添加里程碑

    需求说明

    “实训任务1”中的权限管理系统工作计划甘特图添加里程碑

    实现思路

    (1) “需求评审”阶段添加里程碑

    (2) “设计评审”阶段添加里程碑

    (3) “代码评审”阶段生成里程碑

    (4) “测试评审”阶段生成里程碑

    关键步骤

    “实训任务1”中的权限管理系统工作计划甘特图添加里程碑,如图1.2.2所示。

     

    1.2.2 为项目生成里程碑

    实训任务3:为项目绘制工作计划甘特图

    训练技能点

    Ø 甘特图

    Ø 需求分析

    需求说明

    选定自己的毕业设计项目。将权限管理系统作为自己项目的一个模块,编写自己项目的工作计划甘特图。

    实现思路

    (1) 选定自己小组的毕业项目

    (2) 为毕业项目制定项目计划

    (3) 为毕业项目做需求分析

    (4) 根据需求分析为自己小组的毕业项目书写需求设计说明书

     

     


    巩固练习

    一、 选择题

    1. 下列选项中,属于毕业设计目标的有:()

    A. 积累到行业经验

    B. 积累到团队开发经验

    C. 积累到产品经验

    D. 学习到实用软件工程知识

    2. Y2毕业设计中,我们小组的团队组织结构为:()

    A. 大型软件公司团队组织结构

    B. 微软团队组织结构

    C. 小型软件公司团队组织结构

    D. 惠普团队组织结构

    3. Project 2003中,默认情况下,任务以()为单位。

    A. 小时

    B. 分

    C. 天

    D. 星期

    4. 下列不属于经典软件项目开发模型的有:()

    A. 瀑布模型

    B. 快速原型模型

    C. 增量模型

    D. 敏捷开发

    5. 甘特图中的菱形表示:()

    A. 项目里程碑

    B. 超过最大许可时间的任务

    C. 包含子任务的关键任务

    D. 延迟的任务

    二、 操作题

    为自己小组选定的毕业项目的工作计划甘特图添加里程碑,分别添加需求评审、设计评审、代码评审和测试评审等里程碑事件。

     

    展开全文
  • IT项目管理最佳历程

    2009-08-31 12:34:14
    介绍了如何在项目管理过程中编制计划,管理项目范围、时间、成本等基本而又非常重要的环节,同时,根据多年项目管理工作经验以及和上百位目前在各个IT公司从事项目管理工作的同行的交流,本书作者针对目前屡次困扰...
  • 项目管理模式

    千次阅读 2014-07-14 14:42:18
    这里说的项目管理模式不是各种项目管理里类证书相关的理论,只是自己根据周围的现象的一些思考和推测。一些现象现象1:前几天与朋友聊天,聊到项目经理的选择条件,他说,没有行业背景、不懂业务和技术的项目经理,...
  • PMP项目管理就业前景

    千次阅读 2014-07-16 13:21:50
    PMP国际项目管理师认证,项目管理知识体系 (Project Management Body of Knowledge,PMBOK)是美国项目管理学会(PMI)经过多年研究所汇编而成,是完整、有系统的项目管理标准架构。内容涵盖项目管理九大知识领域与五大...
  • 管理理念:软件项目管理原则谈

    千次阅读 2011-06-28 09:50:00
    我们中的大多数项目管理人员在其个人简历中纷纷写到:“拥有多年的丰富的项目管理经验”,但在实际开发中,“丰富的”管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工,她所谓的项目管理经验只...
  • 项目、团队管理经验

    千次阅读 2018-09-30 18:05:25
    团队管理方法 高效地管理员工有难度,但也并非做不到,关键是要找到规律、遵循规律。按照规律管理员工,难以驯服的员工会变的温顺,低效的团队会变地生机勃勃。管理没有捷径可走。 01 树立制度高于一切的管理思想 ...
  • 软件项目管理

    千次阅读 2009-09-27 22:47:00
    软件项目管理 & 课程背景 21世纪研发已成为企业竞争的主战场,研发项目管理是极具挑战性的一项工作:研发面临市场、客户的压力,需要与内外部的各大部门协调,如:内部的测试、工艺工装、生产、采购等相关职能...
  • [转]项目管理心得:一个项目经理的个人体会、经验总结 本文转自:http://kb.cnblogs.com/page/157087/ 本人做项目经理工作多年,感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导,只有最合适的,...
  • 项目管理

    千次阅读 2007-06-02 11:34:00
    编码人员和美工的配合问题 公司的项目都是基于B/S结构的,绝大多数操作界面都是通过网页的形式展现在用户面前的,页面的美观就成了非常重要的问题。记得去年的这个时候公司迎来了它历史上的第一个专职美工。同时到来...
  • IT 项目管理制度

    千次阅读 2015-10-23 12:04:58
    第一章 总则 为提高XX公司(以下简称“公司”)项目建设管理水平,规范项目建设管理行为,提高项目质量,保证项目进度,...项目管理是把各种系统、方法和人员结合在一起,在规定的时间、预算和质量目标范围内完成项目
  • 如何做好项目管理任务分配

    千次阅读 2017-04-26 14:11:12
    项目管理工具在我工作的10多年中,使用过不少的项目管理系统,Excel, Microsoft Project, dotProject, Redmine, Jira, Teambition, Worktile, Tello…。比我谈过的女朋友还多。这里不讲哪个工具更优秀,只能说应人而...
  • 本书的作者都是在著名IT跨国公司从事过多年项目管理工作的高级项目经理。凭借她们多年积累的工作经验和多次培训的积累,本书作者从一个咨询者的角度出发,向在IT公司从事项目管理的同行们介绍了一套适用于大部分IT...
  • 实战游戏项目管理1-规划篇

    万次阅读 多人点赞 2018-03-24 15:46:57
    做研发管理10多年,进游戏行业8年,经验下来项目管理就是一门技术,结合不同行业不同项目加以不同管理方法,但原理基本一样,这里总结下游戏项目的管理一些实操方法 一般游戏确定立项前都需要做,项目预研产出一...
  • 软件项目管理原则谈

    千次阅读 2006-04-03 02:34:00
    我们中的大多数项目管理人员在其个人简历中纷纷写到:"拥有多年的丰富的项目管理经验",但在实际开发中,"丰富的"管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工,她所谓的项目管理经验只不过是...
  • 项目管理书籍推荐

    千次阅读 2011-02-25 13:58:00
    IT系统 项目管理 考证 书籍 推荐
  • 【西安】IT项目管理与职业生涯规划

    千次阅读 2018-04-24 17:15:18
    将于2018年5月12日在陕西西安举行,此次大会围绕“项目管理”在时代变化中的职业生涯规划,邀请业界知名专家、龙头BAT企业实践专家,给我们呈现行业领先企业多年实践经验以及思考与总结,帮助更多你了解行业发展趋势...
  • 某网络建设项目在商务谈判阶段,建设方和承建方鉴于以前有过合作经历,并且在合同谈判阶段双方都认为理解了对方的意图,因此签订的合同只简单规定了项目建设内容、项目金额、付款方式和交工时间。 在实施过程中,...
  • 项目管理之追MM模式

    千次阅读 2006-11-14 23:17:00
    项目管理之追MM模式项目管理(追MM) 5个过程组就是:启动,计划,执行,控制,收尾。某人(比喻)好不容易找了个女朋友,为了增进进一步的距离,他想来个欧亚8日游,于是他把自己多年的积蓄——3万元,一次性投入...
  • 编者按:为了将更多的软件英雄、软件产品展示在众人面前,CSDN 与《程序员》...本期的展示作品是金牛项目管理平台。对此,CSDN记者采访了该作品的创作人钟礼月。谈到这款由他亲手打造的强大软件,钟礼月滔滔不绝的开
  • 软件项目管理实践 (中文版)

    热门讨论 2008-10-29 12:16:33
    本书内容均为作者多年实践经验的总结和精选,并在多个成功项目中得到了检验。书中还可以实际项目案例的形式进一步说明了相关的概念和方法,有助于读者理解本书内容在实际的商业环境中的应用。 本书是为软件项目经理...
  • 企业信息安全建设工作可以从多个方面来建设与完善,我在这里就介绍信息安全等级保护的基本要求加上自己从事多年的安全工作经验,与各位共勉,干货在后面。 等级保护包含哪些方面 根据GB/T22239-2008 《...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 79,096
精华内容 31,638
关键字:

多年项目管理经验