个人体验~软件开发中的项目管理

第一篇：个人体验~软件开发中的项目管理

广西工学院

软件开发中的项目管理

姓名：罗 鑫

学号：200502002072

班别：计Y052班

指导老师：唐新来

一、引言

软件开发是人类大脑智慧的结晶。软件项目开发是以人为根本，离开了人软件开发就无从谈起。并且软件开发涉及到的不是一个人，而是一个集体。一群人要做事，而且要做好事，就得有人管理。有道是：一只狮子领导的一群羊，要比一只羊领导的一群狮子更加有战斗力。所以说，一个团队的战斗力归根结底要看领导者的领导和管理能力。

这次软件测试的论文，我就软件开发中的项目管理谈谈自己的心得和看法。我有幸有几次在学校合作开发软件项目的经验。虽然说那不是商业项目，但是好歹也是学校科研处立项有经费支持的大学生科研项目。分别是《网状结构的描述、应用与研究》《排序结构算法的对比、研究、应用》《基于局域网的存储网格研究、应用》。前两个项目以及基本完成并且结项，后一个项目刚刚申请。我在其中担任的角色是，组长，组员，组长。虽然项目不大，但对我一个学生来说还是一个挺大的挑战。

二、初识软件项目管理

我最初关心软件开发过程的项目管理是大二的上学期，那时候正是我决定锻炼自己，接学校一个科研项目的时候。我有幸成为该小组的组长，下面带个几个水平不错的同学一起进行软件开发。第一次担任组长的职务很不适应。以前自己写代码野惯了，没有太多和别人合作开发的经验，所以开始的工作不知道如何开展，很乱非常乱。大家在一起讨论了几次开了几次会，都是泛泛而谈没有什么实际成果。万事开头难，我们只能在前期的一个月到两个月进行基础知识的补充。我也在这段时间中，开始致力于学习项目管理。到图书馆翻了很多书也了很多项目理书籍，但是当时根本都不懂也不理解。我就觉得书上写的应该比较对吧，所以一看到好的东西就断章取义的来用，来实践。很不幸后来我所实践基本都失败了。

积累了一段时间基础知识后，我们小组算是正式开始工作了。但是小组的组织还是像以前一样无序。大家各种都在忙着自己的事情，而作为组长的我也不能有效把大家聚集起来。组内人心不齐，各种的水平有参差不齐。并且在其中还有一种怪气氛，技术如果不能压住别人的话，没有办法树立作为领导的权威。这点我深有体会作为一个组长威信不够、底气不足的话，是无法让大家信服的。大家各种都按自己的意见来办，意见根本无法统一。当然也根本无法进行协作开发。似乎这个问题也是很多开发小组的无奈，同时我也担任着软件实训的一个小组的组长。没有威信工作根本无法展开，特别是遇到一些很有个性的人，那就是更加倒霉的事情了。

所以为了确定自己的威信和权威，我将精力从软件管理中分开了而专注于软件模型的开发，这段时间我打法我的组员进行基础知识的积累和学习。经过自己的不懈努力，我自己终于做出了软件模型，在得到指导老师的肯定后。之后的小组开发我就基于这个模型来做。同时也算树立了自己的威信和权威，开始了一些很初级的分工，就是我需要什么函数，就要别人帮我做。这样我的小组才渐渐的开始算做合作起来，跌跌撞撞，惨不忍睹。在那年的暑假原来很多人的软件小组，最后也才剩下4个人了。一场激情过后的惨淡，剩下漫长的暑假重复做这编码、调试、编码、调试。经过我们不懈的努力，终于在结项的前几日完成了项目，补齐了各种软件开发文档。一场乱仗就这样结束了。

虽然项目得到了指导老师的肯定和系里头的肯定，但是我却认为这次项目还是失败了，最大的失败就是没有能够协同开发。原因有三：

1、分工不明确。

谁做需求、谁做设计、谁管理、谁写文档基本上都是乱的。要不没有人做、要不都是我自己做的。整个项目做下来我完成了超过80%的代码，70%的文档。我可以一点不客气的说、整个软件基本上都是我一个人在做。如果从作为程序员这个角色来看，这无疑是个荣耀，一个成果。但是我作为一个软件小组的组长，出现这样的情况是严重的失职和失败。且不说组长大材小用了，组员们那些大批人力资源白白浪费掉了，毕竟一个人的精力是有限的，项目做完同时也让我身心疲惫。

2、交流严重不足。

分工不明确有很多原因。其中一个原因是因为我和我的组员交流不够，组员与组员之间的就更加缺乏交流。缺乏交流的所导致的严重后果是，我不明白组员们的想法，组员们不明白我的想法，组员于组员之间都不知道对方在做什么！初步的分工后，各种写各的代码，且不说编程风格了，光是变量和函数的命名在代码集成的时候都可以要人命。各自有各自的一套命名习惯。很多变量和函数的作用原本是相同的，但是因为命名的原因就不得不花很多的精力来检查和修改，极度的浪费时间和资源。而且由于交流的不足，我做代码集成的时候，很多人的代码根本都无法集成进去，我不得不重新自己来写过。

3、文档完全无用。

可以说从项目开始到测试完成，都没有产生任何文档。文档是在最后要结项的时候补的，这样的文档完全无用，完全失去了做文档的意义。文档的作用就是用来指导和驱动软件开发的，现在我们做的文档完全是为了“做文档”而去写的。

三、从另外一个角度看软件项目管理

我的第二次的学校的科研项目课题是《排序算法的研究应用》。这次是我班的龙国力同学带队的。我作为组员加入其中，担任该项目的软件设计人员。在参与这个项目的同时，我同时从组员的角度来看软件开发的项目管理，并且从中总结学习经验。

这一次项目开发，我是组员，当然轻松很多了。我可以把时间放在设计软件的框架上面。从一开始我就明确自己作为一个设计员的责任和任务。项目开发有点磕磕碰碰，但是都是技术上遇到的困难。在整个软件开发上有条不紊的进行着。这主要是得力与龙国力同学的领导，还有一点就是我作为组员的积极配合。我们小组的组长的有权威，我和其他组员都很信服。同时我作为组员积极的配合组长进行工作的展开，经常交流，经常反应最新的情况。

这次项目的分工很明确，组长考虑到各个组员的水平不一。所以在分配任务的时候充分的考虑了这一点。组长：龙国力负责软件的界面框架设计、实现、各种排序算法的整合。组员：罗鑫负责软件内核框架设计和实现，并且辅助界面框架设计。其他组员：分别负责各种不同类型的排序算法的实现。在小组例会的时候，把我以前小组遇到过的问题和大家交流。会议一般都是由组长组织，每次开会都有明确的会议内容和这阶段的分工明细。会议的时间也不长，很有效率。

对比之前我带的项目，这次无疑比上次成功了很多。我之前带的项目基本上是自己做、没有明确的分工、缺乏与组员之间的交流、我的想法也无法到达下面的组员、组员的想法也很少反映到我这里。所以项目一做下来，累都累死人。这次我是作为组员加入项目的，我认识到如果组长不分配任务给我不明确我的任务的话，我作为组员就不知道应该如何做起，也

就一直无所事事了。所以组长为了充分利用我们各个人的特点，对我们进行了任务分配，明确我们各种的任务，这样大家就有了努力的方向。同时作为组员我也充分的配合组长的工作，积极和组长交流，明确自己任务的同时也尽量的帮他分担相应的工作。组长就可以更加专心的致力于对软件开发的进行全局性的规划。.这次项目我作为组员得到以下几点体验：

1、相信和支持组长。

相信和支持自己的组长。论他的能力是否比你差，你都要去支持。毕竟每一个人的都是有自己擅长的一面和不擅长的一面。软件开发的组长，是一个团队的核心也是一个团队的灵魂。作为组员应该支持和信任自己的组长，支持并且主动承担一些工作，这样组员于组长之间有了良好的合作气氛，对软件开发百利而无一害。

2、明确自己的能力、工作和职责。

船没有导航的设备是无法遨游于大海之上的，人也是一样，程序员也一样。如果没有具体的工作和明确的职责，人就无法展开工作。到头来只能这做做那做做，最后一事无成。别人眼里头看看来此人就是在消极待工。

3、及时反馈进度。

组员和组长总会意见出入的时候，组员无法确切的理解组长的意思，组长也无法确切的了解组员的进度。经常出现组长想做个飞机，组员却做成了坦克。组员这时候又不得不返工，浪费人力也浪费时间。所以要及时的反馈自己的进度、根据组长的意思及时修正、最大限度的满足组长提出的要求、同时也减少自己返工重做的次数。

同时我从组员的角度看软件项目管理，我有以下心得：

1、组长要相信自己的组员。

作为组长要敢于善于听组员的意见，也要敢于善于把重任赋予别人。要充分的营造一个和谐的合作气氛，减少组员和组长之间的沟通阻碍。

2、分工要明确。

组长要根据个人的能力进行分工，明确组员们的任务、职责和完成时间。尽量把工作摊开来，让自己能够很专心的对整个软件开发进行规划，掌握全局。

3、任务跟踪。

对于每个组员分担下去的任务，要及时检查和纠正。定期召开例会，检查和跟踪当

前的项目进度。

四、初试锋芒

经过前两次的项目之后，自己逐渐有了一点点项目管理的经验了。我自然的就迫不

及待的想在具体的项目中进行实践。所以我又去唐老师那里接了一个项目《基于局域网的存储网格系统的研究于应用》这个项目刚刚申请，还没有完全启动起来。同时现在正好进行清华IT的实训，我接着担任一个实训小组的组长，我的组员就是本宿舍的人。分组没有找到想要的合作伙伴，但是好歹本宿舍还有一个两个不错的合作伙伴。一开始

拿的牌不算太好，甚至有点烂。我就在思索如何把不好的牌打成好牌。

宿舍都有些问题人物、懒、游戏、什么都不管、实训也不参加。对于这些人，我只

好放弃，他们能进来做事那最好。不能的话就算了，反正我的底线是他们不能影响到整个实训的项目开发。

我开始对我的小组做了以下工作：

1、角色分配。

通过对每个人的性格，水平，人缘进行相关的分析和思考后，我将我的组员们进行

角色分工。分为两组：软件开发设计组（组长：吴天柱）软件测试小组（组长：李海强）。选定这两个人为小组组长是有原因的，吴天柱：有一定的项目开发经验并且和我合作过、相当值得信任并且有很强的责任感。所以我让他担任设计开发组长，通过他来督促和管理他该组的组员。李海强：没有太多的开发经验，但人缘很好责任感强。所以我让他担任测试小组的组长，通过他督促和管理该组的组员。

2、任务分工。

我将各个任务肢解，对两个组长分配大任务，并且限定完成任务的时间。两个组长

得到的都是比较大的任务，所以他们就得再次分工，把具体的工作分配到各个组员身上。同时我也限定了每组组长必须在限定的时间内上交想要的文档。这样从上到下就把任务分配下去了。

3、营造协作环境，付重任与人。

为了营造这种交流环境，我把交流协作的中心放在两个小组的组长身上。通过他们

两个为中心进行交流。对于软件的需求分析和软件结构的设计，我只是提出自己的设想和方向，规定一些必需要达到的要求。首先让我的两个组长理解我的基本要求，然后让他们在保证我的基础要求之上，自己进行具体的设计和规划。最后在将他们的设计进行再分工。这样他们就有了充分的自由发挥的空间。这样就有了一定的弹性空间，让大家的意见能够充分的整合在一起。

4、规范文档驱动软件开发。

从实训开始，我就严格的安装整个软件开发的流程一步步往下做。每一阶段都会有

相应的文档产出，同时文档一直在迭代在修改。我们小组在做需求分析的时候，需求分析文档经历过3到4次迭代，来适应新的需求变化。文档的页数从原来的20多页一直增长到最终的40多页。同时各种计划和分工统统文档化，项目计划，某阶段的项目分工，等等都统统以文档的形式记录和传达。文档记录了过去一阶段的工作成果，同时也指引我们未来的工作。

5、人员危机处理。

实训小组可能出现的最大危机，就是人员危机。参加实训的人的积极性，一天比一

天下降，从原来都去听课，到现在很少人听课。这一点我在组队之初，就考虑到了这一点。整个实训项目的进度不能因为几个懒惰的人而中止，所以我在角色分配的时候给有责任心的人，赋予重任就是这个原因。实训进行下去到最后，必然就是那几个有责任心的人撑到最后的。至于对其他那些人，能鼓励就鼓励他们多参与，若不能的话，就随他吧。不可能为了几个人，而耽误其他有心学习的人的实训。

目前我们实训小组的现在正在概要设计和详细设计阶段。前一阶段所做的工作，产

生相应的《需求报告说明书》《项目计划》都得到了实训老师的肯定和好评，小组有条不紊的继续前进。我相信我们认真的坚持做下去，会有很大的收获的。

五、结语

以上的一些感想和体会，都是通过反思和总结这一年多来的我参加的各种学生科研项目和实训中得到的。可以保证文章完全的真实性，虽然我所想的和专业的软件项目管理还是有很大很大的差距，但是那也是我通过很多次的实践得到的。其中也经历了很多劳累和心酸，毕竟这是通过自己努力得到的东西，在我自己看来还是弥足珍贵的。

第二篇：软件开发项目管理（范文）

管理目标

1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。

2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。

3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。

执行概述

1、建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。

2、明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。

3、跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。

4、解决项目过程中出现的问题和冲突，一般集中在需求不明/工作量或时长/开发难度/跨部门协调等几个方面。

5、调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。

6、风险识别、风险控制以及风险的预案。

项目管理

1、需求阶段

对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求讨论，明确项目的目标、价值。确定项目范围、功能及优先级。

组建项目团队，特别要搞清楚项目的关键人。项目启动会议，相关的关系人都必须参加。

2、设计阶段

根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。

设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。

该阶段交付成果需要进行评审。

3、执行阶段(开发和测试)准备开发环境、测试环境。跟踪，推动项目按计划进行。

项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。按里程碑对阶段成果进行评估，以确保该阶段完成的质量。代码审核，包括CS审核、SQL审核、WEB审核等。对需求变更进行控制管理。

测试阶段BUG响应及改进、收集反馈意见。对项目风险进行管理。

4、发布阶段

包括制定项目发布计划，用户培训，发布上线。

5、试运行阶段

数据监控(日志、服务器状态)，根据监控出现的问题，及时进行处理，改进性能问题，特定情况执行补丁升级。

6、收尾阶段

产品交付，项目总结会。

常见问题

1、开发时间的估算

制定项目计划时，需要估算每个任务所需的时间，其中主要是开发任务中模块的分配和时间估算，在公司现有的技术框架下，开发人员主要的工作是投入在具体的业务逻辑实现上。通常单个模块开发时间取决于以下因素：

1、负责模块的业务逻辑的复杂程度。

2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度)。

3、模块技术实现上是否存在难点，所谓的技术难点定义是：在现有系统中还未实现的、开发人员自身未没接触过的技术。对于这样的难点，开发者没有相关的代码可以参考，自己也没有经验，所以需要投入学习时间用于研究解决。

模块分配和开发时间估算的步骤：

1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。

2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下：

A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。

B、技术难度较大的模块由技术水平比较高的人负责。C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。

3、模块分配完成后，开发人员评估自己负责开发的模块所需要的时间。在此过程中应

4、对开发人员估算的时间进行确认。在确认过程中作为，项目管理者将预估时间和开与开发者讨论每个模块的技术实现细节，使时间的估算更加准确。发人员估算时间进行比较。那些差异较大的，与人员探讨其中的缘由。对于时间周期比较长的任务，将任务拆分为更小的子任务，每个任务的完成时间为8-24工时，消除时间周期较长的任务，避免不确定性影响项目的进度。

2、CodeReview CodeReview是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是测试后出现大量bug的主因，有时甚至导致返工；关于CodeReview执行，首先应有编码规范和代码审查规范。通过这两个文档来规范开发人员的代码实现，代码编写者必须要严格按照规范来进行；代码审核者根据这些标准来CodeReview代码，同时在CodeReview过程中需要不断完善该文档。

CodeReview一般可按以下步骤实施：

1、检查开发者的代码实现是否遵循了编码规范。

2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。

3、代码编写者和代码审核者坐在一起，由代码编写者按照UseCase依次讲解自己负责的代码和相关逻辑，代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug，对这些bug记录在案。

4、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要检查Bug。同时全面兼顾，确保代码整体上结构优良；审核完毕后，代码审核者编写“代码审核报告”记录发现的问题及修改建议，提交给相关人员。

5、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。

6、代码编写者bugfixed完毕之后给出反馈。

7、代码审核者把CodeReview中发现的有价值的问题更新到“代码审核规范”的文档中，对于特别值得提醒的问题可群发email给所有技术人员。

3、需求变更管理

需求变更管理也是项目管理中最重要的一个环节，对需求变更管理的有效性将直接影响对待需求变更的正确态度：

1、需求变更是不可避免的。

2、需求变更要必须被管理。

3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。需求变更管理的目标：

1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。需求变更流程：

1、确定需求的基准线。将以UserCase作为需求基准线，在UserCase确认之后的任项目的成功与否。何需求改变，都需要走需求变更流程。

2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。

3、项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。项目管理者对项目的成功与否负有主要的责任。需求变更的决策应由项目管理者做出。

4、需求变更确认后，由专人将生成需求变更单记录下来，通知给项目中所有关系人。

5、确定变更的负责人。承担需求变更的具体工作，比如基线控制，对需求变更的记录，并通知相关人员。

6、相关人员接收到确认的需求变更后，需求分析人员修改需求说明书和UserCase的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。

7、按照变更后的计划实施项目，并进行检查，跟踪，对变更后的实施反馈和可能出现的问题及时沟通和处理。

8、需求冻结。项目越到后期，需求变更对项目的影响就越大，所以在一定时候要进入需求冻结阶段，不再接收新需求或需求的变更。

4、风险管理

影响项目成败的因素涉及方方面面，并且风险伴随着项目的始终，是客观存在的，风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，常见风险如下：

1、目标以及需求不明确

为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或口头的传达上，没有正式的业务需求文档，在没有明确的需求范围的情况下，有时为了迎合业务部门的口味匆匆开工，过程中用户不断地提出新的想法，技术人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。

在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。

2、项目目标扩大以及需求变更

在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求。

前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户)，所有的需求要经过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、UserCase确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。

3、代码质量风险

质量风险主要指开发代码的质量。在制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响很大。开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发质量问题。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发非常重要。

往往有这样一种情况，每个团队成员按照项目计划报告进度都是100%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题。这需要在项目实施过程中采取有效的措施来规避风险，通常的做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以发现架构设计问题；管理评审，通过组织级的质量审计看产品以及实施过程是否满足质量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要求的代码，走查通常能够发现50%-70%的错误；每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。

4、人员技能和资源的不足

项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见，一个熟练的技术人员完成同样一个任务需要3天，但一个新手可能就需要7-10天。项目管理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的角色，及时采取相应的技能培训，以保证项目的顺利实施。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风险在后期或中期出现。

5、缺乏良好的团队协作

软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。

6、项目会议

组织会议是项目执行过程中一项非常重要的工作任务，项目过程中很多重要的决定都是在会议中做出的，不成功的会议会对项目本身造成了不好的影响。

不成功的会议通常表现为如下形式：

1、会议氛围不好，参与者发言不踊跃；

2、会议讨论常常偏离主题；

3、会议没有取得预期的结果；

4、会议时间常常一拖再拖。

这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的，很多人都对这样的会议都有抵触情绪，对此也是深恶痛绝。以下是组织会议时应该注意的问题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：

1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有可能取得成功，这是会议成功的充分条件。

2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只是一个发表想法的人，他不用对会议的成功承担责任。

3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。组织会议的十一条最佳实践：

1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。

2、提前发出会议议程，以便会议参与者知道他们来做什么。

3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确保必要人物都在的情况下一次会议参与者越少效果越好。

4、提前预约参与者的时间，以确保他们能按时到场。

5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在开场时说： A、再一次强调会议的目标，我们来做什么。

B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。

C、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人的讲话，等别人说完你再说等等。

6、会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。

7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。

8、会议要有结论。我们常在会议上听到有人说：“大家讨论了这么半天，结论呢？”。没有结论的会议是没有意义的。

9、会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。

10、会议后的action执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。很多会议往往都不注意这一点。

11、按时结束的会议会受到所有人的欢迎。

第三篇：浅谈软件开发项目管理

浅谈软件开发项目管理

摘要：在软件项目开发的过程中，软件项目管理的成功与否是决定一个项目是否能够顺利高效率完成的重要保证。但是我国大部分的软件企业在进行项目管理时都存在着各种问题，从而使项目不能顺利有效地完成。文章探讨了在项目管理过程里出现的常见问题，并给出了相应的解决策略。

关键词：软件项目管理；项目经理；项目计划

软件行业在现在的众多行业里是一个极具挑战性和创造性的行业，体现了软件开发者的智慧和汗水，同时软件开发是一项复杂的系统工程。牵涉到许多方面的因素，在实际工作中，经常会出现各种各样的问题，甚至会面临失败。如何总结、分析失败的原因。得出有益的教训，对于项目开发人员来说，是在今后的项目中取得成功的关键。

一、软件开发中实行项目管理的意义

项目管理就是在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求，实际上就是通过项目各方干系人的合作，把各种资源应用于项目，以实现项目的目标，满足项目干系人的需求，其本质就是对时间、质量和成本的管理。随着软件开发的深入、各种技术的不断创新以及软件产业的形成，人们越来越意识到软件过程管理的重要性，管理学的思想逐渐融入软件开发过程中，项目开发的管理日益受到重视。

二、目前在软件项目管理中存在的误区

现在大多数企业都认识到了在项目中进行管理的重要性，但是仍然有许多企业在实施项目管理的过程中存在着这样那样的误区，主要表现在：项目经理不够专业。在软件企业中，缺乏专业的项目管理人员来实施项目管理及担任项目经理，通常被任命的项目经理主要是因为他们能够在技术上独当一面，但是他们在管理方面特别是项目管理方面的知识比较缺乏。项目计划缺乏纲领性。项目经理对总体计划、阶段计划的作用认识不足，因此制定总体计划时比较随意，不少事情没有仔细考虑：阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。缺乏有效的管理意识。部分项目经理不能从总体上把握整个项目，而是埋头于具体的技术工作，造成项目组成人员之间忙的忙、闲的闲，计划不周、任务不均、资源浪费。有些项目经理没有很好的管理方法，不好安排的工作只好自己做，使项目任务无法有效、合理地分配给相关成员，以达到“负载均衡”。缺乏有效的沟通制度和机制。在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足，造成各做各事、重复劳动，甚至造成不必要的损失：有些人没有每天定时收邮件的习惯，以至于无法及时接收最新的信息。风险管理意识淡泊。有些项目经理没有充分意识到风险管理的重要性，对计划书中风险管理的章节简单应付了事，随便列出几个风险，随便地写一些简单的对策，对于后面的风险防范起不到什么指导作用。项目干系人的不确定性。在范围识别阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以至于无法得到完整需求或最终经权威用户代表确认的需求：或者是多个用户代表各说各话、昨是今非，但同时又要求项目尽早交付：项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。缺乏项目团队的合理分工。项目团队内部有时由于各阶段不同角色或同阶段不同角色之间的责任分工不够清晰而造成工作互相推诿、责任互相推卸的现象；有时各阶段不同角色或同阶段不同角色之间的责任分工比较清晰，但是各项目成员只顾完成自己那部分任务，不愿意与他人协作。这些现象都将造成项目组内部资源的损耗，从而影响项目进展。

三、解决软件项目管理中存在的误区的有效策略

要想解决上面描述的误区，归根到底还是要从管理学的角度入手，即在软件项目的开发过程中加入过程管理的内容，这样我们可以在软件开发中对各个过程的质量加以控制，从而达到保证软件产品质量的目的。为了有效提高管理水平，我们应该努力做到：项目经理接受系统的项目管理知识培训是非常必要的，有了专业领域的知识与实践，再加上项目管理知识与实践和一般管理的知识和经验的有机结合，必能大大提高项目经理的项目管理水平。计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。提高项目经理的计划意识，采用项目计划制定相关知识、技术、工具，加强对开发计划、阶段计划的有效性进行事前事后的评估。加强项目管理方面的培训，并通过对考核指标的合理设定和宣传引导项目经理更好地做好项目管理工作。技术骨干在担任项目经理之前，最好能经过系统的项目管理知识，特别是其中的人力资源管理、沟通管理的学习，并且在实际工作中不断提高自己的管理素质，丰富项目管理经验，提高项目管理意识。制定有效的沟通制度和沟通机制，提高沟通意识：采取多种沟通方式，提高沟通的有效性。通过制度规定对由于未及时收取邮件而造成损失的责任归属；对于特别重要的内容要采用多种方式进行有效沟通以确保传达到位，例如：除发送邮件外还要电话提醒、回执等，重要的内容还要通过举行各种会议进行传达。通过学习项目管理知识掌握风险识别、量化、对策研究、反应控制的工具和方法，掌握项目风险管理所必备的知识。通过加强对项目规划中风险管理计划的审核提高项目组的风险管理意识。总结本行业项目中常见的风险及其对策作为风险管理计划中必要的风险内容，并切实评估相应对策的有效性和可行性。项目的目的就是实现项目干系人的需求和愿望。项目干系人管理应当从项目的启动开始，项目经理及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。项目经理应当对项目成员的责任进行合理的分配并清楚地说明，同时应强调不同分工、不同环节的成员应当相互协作，共同完善。

实施有效的项目管理绝非易事，对于软件企业而言，这不是一个小的改变，而是一种变革，企业需要为此付出艰苦的努力，同时，成熟有效的项目管理无疑将对企业起着至关重要的作用，项目管理的水平将是企业核心竞争力之一。

第四篇：软件开发项目管理实施方案.

项目管理实施方案

作为一个项目管理者,如何要成功的做好项目管理;首先必须先要明白的是在特定的领域中赋予这个角色所要实现的目标、承担的职责、以及项目管理者的具体工作内容是什么? 从我个人的浅见和角度以及我们所从事的IT领域来分析回答以上三个问题。第一:目标

作为一个项目的管理者,必须要明确的知道自己的工作目标;我个人认为项目管理者的目标无非就是以下两点:

1、就是清晰明确地了解项目利害关系者的需求和期望,努力做到满足项目利害关系者的不同需求;项目利害关系者包括:项目团队成员和项目团队外成员(比如各部门的部门负责人和市场人员,客户等。

2、就是保证开发项目按需按时保质的完成。第二:职责

作为项目的管理者,首先要端正态度,要明确知道自己的工作职责,认识到这份工作职责的本质。项目管理者不是来管人的,而是来支持人的,是来协调资源的,是来营造一个适合团队成员比较认同的工作环境和氛围的,是来为一个共同的目标和大家一起战斗共同成长的。可以大概概括成以下几点:

1、建立有效的工作流程保证项目的顺利进行。

2、制定详细周密的项目计划。

3、跟踪,推动项目按计划进行。

4、积极解决项目过程中出现的问题和冲突。

5、调动开发团队的积极性,创造力,推动团队成员在项目过程中不断成长。

6、项目风险识别、风险评估、风险解决和风险管理策略以及做好突发风险的应急预案。

7、实现目标

第三:项目管理者的具体工作内容

最后一个是项目管理者的具体工作内容,作为项目管理者必须清晰的知道自己的工作范围和所要做的工作内容以及工作重心,分为以下六点:

1、项目前期阶段

对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求讨论,明确项目的目标、价值;确定项目范围、功能及优先级。组建项目团队,特别要搞清楚项目的key person(对产品有决定权的人。项目启动会议,相关的

利害关系人员都必须参加。

该阶段完成后的成果:确认后的最终软件需求规格说明书文档。

2、分析设计阶段

根据确认后的软件需求规格说明书,制定项目进度计划,工作任务分解(WBS;资源申请,项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源;数据库设计;系统设计;文档(包括Use Case、Demo系统原型、Test Case等;评审会议。

该阶段完成后的成果: A、User Case(系统用例;B、DEMO(系统原型;

C、系统设计文档(概要设计和详细设计;D、数据库设计文档。

最后对完成的成果,包括User Case和设计文档等进行评审。

3、执行阶段(开发和测试

准备开发环境、测试环境;跟踪,推动项目按计划进行;以周报的形式通报项目的进展情况。对项目的阶段成果进行评估,以确保该阶段完成的质量,包括代码审核、SQL 审核等。对需求变更进行控制管理;对项目风险进行管理;测试阶段BUG FIXED及改进、收集反馈意见。

4、发布阶段

包括制定项目发布计划,用户培训,发布上线。

5、上线后监控

数据监控(日志、服务器状态,根据监控出现的问题,及时进行BUG FIXED及改进或做补丁升级。

6、结束阶段

产品交付,项目总结会。

第四:基于以上三个问题所做的应对细则

要做好项目管理,并能确实解决好以上三个问题,实现目标、履行职责、完成工作中的具体内容,从我个人这几年的工作经验和面临的一些问题,还有所积累的一些项目管理中的

一些知识以及自己的观察和思考的角度看,应该要努力做好以下这几个方面的具体工作:

1、项目开发时间的估算

制定项目进度时间表的时候,需要估算每个任务所需的时间,其中开发任务中模块的分配和时间估算是其中最主要的部分;在分配模块和估算开发时间时需要遵循的原则和目标:

1、保证项目整体的进度。

2、有助于确保开发编码的质量。

3、有助于提高开发编码的速度。

在公司现有的技术框架下,开发人员主要的工作是投入在具体的商业逻辑上。通常每个模块所需的开发时间取决于以下三个因素:

1、所负责模块的商业逻辑的复杂程度。

2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度。

3、该模块技术实现上是否有技术难点;这里所谓的技术难点定义是:在现有系统中还未实现的、开发人员自身也未没接触过的技术。对于这样的难点,开发者没有相关的代码可以参考,自己也没有经验,所以需要投入一些时间研究解决。

模块分配和开发时间估算的步骤:

1、在划分好模块后,首先自己先估算一下每个模块所需要的开发时间。

2、然后召集所有开发人员,讨论模块的分配和开发时间估算。将划分好的模块,让开发人员从中挑选他们感兴趣的模块。这样做可以提高开发人员的主动性和参与性。在分配模块的时候还需从以下几方面考虑,以确保开发的速度和质量: A、相同类似的模块由同一人负责开发,比如用户管理的增删改由同一开发者负责。

这样做的好处就是开发者对相关逻辑会更加熟悉,同时接口的定义也会比较明确,沟通的成本比较低,同时功能实现的缺陷也相应的会降低。

B、技术难度比较大的模块由技术水平比较高的人负责。C、业务逻辑比较复杂的由对这块逻辑比较了解的人负责。

3、模块分配完后,开发人员评估自己负责开发的模块所需要的时间。在此过程中最好做到要和开发者比较详细的讨论每个模块的技术实现,以便使时间的估算更加准确。

4、对开发人员估算的时间进行确认。在确认过程中作为项目管理者应参考以上提到的三个因素,同时将自己估算的时间和开发人员估算的时间进行比较。这其中的差异当然会存在的。对于那些差异比较大的,将与技术人员探讨其中的缘由。对于时间周期比较长的任务,尽量将任务通过再细分的手段细化任务,争取每个任务的最长时间不超过3天;时间周期越长的任务,不确定性越高,风险也越高,越有可能成为项目的瓶颈,影响项目的进度。

2、Code Review Code Review是保证项目中代码质量非常重要的一个环节,在这一环中我们公司做的非常欠缺,把关不严格;这是导致每次测试后出现大量bug的主要原因,这一环需要纳入绩效考核中,实行责任追究制,实施重点监控。出现这样的薄弱环节,造成这样的原因,我想也是有很多因素造成的;比如开发人员对需求不是很明确,以自己比较主观的因素去完成任务的;还有对整个系统业务逻辑没有正确的清晰的认识的原因,以及对项目组成员培训不到位的原因等众多因素纠集在一起才产生的。

如何做好这方面的工作?首先编码要有“编码规范”文档,Code Review要有“代码审

核规范”文档:记录代码实现应该遵循的标准。通过这两个文档来规范开发人员的代码实现,代码编写者必须要严格按照规范来进行;代码审核者根据这些标准来Code Review代码,同时在Code Review过程中不断完善该文档。

在做好这些前期工作的前提下,分以下几个步骤来实施:

1、检查开发者的代码实现是否遵循了编码规范。

2、从代码的易维护性、可扩展性角度考察代码的质量,提出修改建议。

3、代码编写者和代码审核者坐在一起,由代码编写者按照Use Case依次讲解自己负责 的代码和相关逻辑,从Web层-到Manage层再到Dao层;

4、代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏的bug;对这

些bug记录在案。

5、代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍。代码需要一

行一行静下心来看。同时代码又要全面的看,以确保代码整体上设计优良。

6、代码审核者根据审核的结果编写“代码审核报告”,“审核报告”中记录发现的问题

及修改建议,然后把“审核报告”发送给相关人员。

7、代码编写者根据“代码审核报告”给出的修改意见,修改好代码,有不清楚的地方

可积极向代码审核者提出。

8、代码编写者bug fixed完毕之后给出反馈。

9、代码审核者把Code Review中发现的有价值的问题更新到“代码审核规范”的文档中, 对于特别值得提醒的问题可群发email给所有技术人员。如果通过以上步骤,还因为是代码编写者的原因而出现严重的缺陷问题,将通过绩效考核来加深代码编写者的印象,并在周报会议上做通报批评。

3、需求变更管理

需求变更管理也是项目管理中最重要的一个环节,对需求变更管理的有效性将直接影响项目的成功与否。

对待需求变更的态度:

1、需求变更是不可避免的。

2、需求变更要必须被管理。

3、积极发现引起变更的因素,促使变更尽可能早的出现,减低变更带来的风险。需求变更管理的目标:

1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

通过制定需求变更的流程,确保项目中的需求变更有效地进行,实现上述的目标。需求变更流程:

1、确定需求的基准线。将以User Case作为需求基准线,在User Case确认之后的任何需求改变,都需要走需求变更流程,这一环节我们基本没有,期间有时候使的工

作很混乱,也就是因为没有一个规范的变更流程而造成的;如果建立了这么一个流程规范和机制,需求变更没有走这个流程的将不被认可。

2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。

3、项目管理者评估该需求变更。针对接收到的需求变更的要求,召集相关人员讨论该需求变更的合理性、可行性,实施的代价以及对项目的影响。包括可能影响的项目范围,进

度,费用,质量等计划。项目管理者作为项目的负责人,对项目的成功与否负有主要的责任。所以需求变更的决策者应该由项目管理者承担。

4、需求变更确认后由专人将需求变更记录下来,通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括(客户方,需求分析人员,测试人员,相关开发人员。需求变更记录格式如下: 序号变更提出时间变更描述变更类型(是 对原有需求 的修改还是 新增需求 原因变更提出 者

开发人员对进度的 影响(工 作量 2

5、确定变更的负责人。承担需求变更的具体工作,比如基线控制,对需求变更的记录,并通知相关人员。

6、相关人员接收到确认的需求变更后,做以下事情。需求分析人员修改需求说明书和User Case的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。

7、按照变更后的计划实施项目,并进行检查,跟踪,对变更后的实施反馈和可能出现的问题及时沟通和处理。

8、需求冻结。项目越到后期,需求变更对项目的影响就越大,所以在一定时候要进入需求冻结阶段,不再接收新需求或需求的变更。

4、风险管理

风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程,贯穿于整个项目过程中,风险管理包括风险识别、风险评估、风险解决以及风险管理策略。

在项目的实施过程中需要不断地识别和应对风险,并加以有效的控制,风险管理的好与坏直接影响项目的实施效果,从某种意义上讲,项目实施对于项目管理者就是识别、分析、应对、控制风险的过程,使项目的约束性目标和质量目标朝有利的方向发展。

项目不同于日常任务,它有明确的起止时间和目标,要在明确的范围、时间和成本约束下,达到相应的质量标准,并取得用户的满意。影响项目成败的因素涉及方方面面,并且风险伴随着项目的始终,是客观存在的,作为一个项目管理者,应该具备良好的风险控制意识,善于识别风险并分析风险的影响,从中发现影响目标的风险点,并施

加影响或采取应对措施,把风险的负面影响降到最低,并且风险控制应该贯穿项目始终。

风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面,导致这些问题的因素主要包括目标以及需求不明确、范围蔓延以及需求变更、代码质量或返工风险、人员技能和资源的不足、缺乏良好的团队协作等。下面将详细描述一下这些问题以及出现这些问题时的应对方案:

1、目标以及需求不明确

为了市场竞争或内部管理决策的需要,业务部门提出的需求往往要求的时间比较紧迫,需求的提出大多停留在几张纸或口头的传达上,没有形成正式的业务需求文档,在没有明确的需求范围的情况下,有时为了迎合业务部门的口味匆匆开工,过程中用户不断地提出新的想法,技术人员开始疲于奔命和应付,很难保证项目的进度和质量,也难以取得业务部门的认可。所以,在项目的前期一定要采取相应的手段或措施,与业务部门共同明确项目目标、需求范围,充分考虑现有的时间和资源约束,将需求排定优先级, 对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取 得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统 原型等手段让用户在前期充分暴露自己的想法和需求。

2、范围蔓延以及需求变更 在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在 看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控 制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的 结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相 关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断 是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求，当然实际 情况下可以采取一些软措施缓解矛盾。需求变更风险：需求已经打上了基线，但此后仍然有变更

发生，对项目造成影响。如何减少此类风险的发生？ 前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户，所有的需求要经 过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确 认、User Case 确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变 更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风 险的重要手段。

3、代码质量或返工风险 质量风险主要指开发代码的质量。如何提高开发人员开发的质量？在制定项目计划 时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响也很大。有 时开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发 质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到现在为止，我们这 个方面做的不是很规范，做的也很不足，大家编写的代码随意性比较大，代码编写者的 主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范，code review 时严格考核。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对 指导开发非常重要。返工是项目组最不愿意看到的，既浪费人力、物力和财力，又影响团队积极性。需 求不明确或范围没有有效控制都可能造成返工，另外造成返工的原因是质量没有达到用 户要求。往往有这样一种情况，每个团队成员按照项目计划报告进度都是 100%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题，不得不花费很大精力回头 排查、修改程序，造成这种情况的主要原因是过程中质量保证没有做到位，把大部分问 题留在了后面。这就需要在项目实施过程中采取有效的措施来规避返工的风险，通常的 做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以 发现架构设计问题； 管理评审，通过组织级的质量审计看产品以及实施过程是否满足质 量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要 求的代码，走查通常能够发现 50%-70%的错误；每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在 项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。

4、人员技能和资源的不足 项目实施过程中由于人员技能欠缺造成的进

度延后和软件质量问题并不少见，一个 熟练的技术人员完成同样一个任务需要 3 天，但一个生手可能就需要 7-10 天。项目管

理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的 角色，及时采取相应的技能培训，以保证项目的顺利实施。如果对于项目中某些部分专 业性特别强或新技术，短期内又不能快速建立技能的情况，可以考虑将该块任务外包，借鉴合作商的力量降低实施风险，当然要进行外购人力成本与自建人力成本的效益分 析。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。如何减少 此类风险的发生？在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻 克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找 可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风 险在后期或中期出现。项目所需人力资源无法按时到位，导致资源风险。如何减少此类风险的发生？这个 就需要在项目计划制定的时候提前申请确认资源，并在项目过程中不断沟通协调。

5、缺乏良好的团队协作 软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各 模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清 楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在 的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。项目风险管理的要点：

1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生 的风险不属于风险管理的范畴。这也将是考验一个项目管理者的经验和知识对能否 管理好风险至关重要的内容。

2、对不可预期的风险，项目管理者要有潜在的风险意识评估，做好一些可操作性的预 案准备。

3、详细明确的项目计划、以及项目执行过程中每个要点的质量保证是降低项目风险的 必要条件。

4、风险报告是项目团队以及领导了解项目风险的一个有效手段。风险报告的格式： 序号 风险简介 对项目的影响 解决方案或对策

5、团队管理 团队就是一组个体为实现共同的目标而相互依赖、一起工作的共同体。团队工作顾名思 义就是团队成员为实现这个共同的目标而付出的共同努力，项目团队的工作是否有效直接关 系到

项目的成败。团队管理是个渐进的过程。世界上只有完美的团队，没有完美的个人。好的高效的团队 不是管理出来的，而是营造出来的。团队成员需要有大家可认同的团队文化，这需要大家共 同的努力。

1、营造良好的工作环境和氛围。

2、建设优秀或鲜明的团队文化。

3、保持高效的沟通。

6、项目会议 组织会议是项目管理者日常工作中一项非常重要的工作任务，项目过程中很多重要的决 定都是在会议中做出的，也有很多由于不成功的会议而对项目本身造成了不好的影响。首先看看不成功的会议常常表现为哪些形式：

1、会议氛围不好，参与者发言不踊跃；

2、会议讨论常常偏离主题；

3、会议没有取得预期的结果；

4、会议时间常常一拖再拖。这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的，很多人都对这样的会议都有抵触情绪，对此也是深恶痛绝。以下是组织会议时应该注意的问 题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：

1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有 可能取得成功，这是会议成功的充分条件。

2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要 希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只 是一个发表想法的人，他不用对会议的成功承担责任。

3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。组织会议的十一条最佳实践：

1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。

2、提前发出会议议程，以便会议参与者知道他们来做什么。

3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确 保必要人物都在的情况下一次会议参与者越少效果越好。

4、提前预约参与者的时间，以确保他们能按时到场。

5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在 开场时说： A、再一次强调会议的目标，我们来做什么。B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论 如何做上面。C、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人 的讲 话，等别人说完你再说等等。

6、会议过程中时刻注意引导和控制会议，以确保会议按照目

标进行。一次会议的氛围 是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。

7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成 果之一。

8、会议要有结论。我们常在会议上听到有人说：“大家讨论了这么半天，结论呢？”。没有结论的会议是没有意义的。

9、会议后别忘发会议纪要，以及一些 Action，什么人什么时候做什么。

10、会议后的 action 执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知 了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性 也会降低。很多会议往往都不注意这一点。

11、按时结束的会议会受到所有人的欢迎。

7、版本控制 版本控制也是项目管理者的一个重要工作内容之一，一个项目或产品的完成不可能是一 步到位的，在项目完成的后期可能会有多个不同的版本的发布（开发版本，测试版本，发布 版本等）。需要做好版本的管理和控制。

8、项目总结 在项目完成后，总结整个完成项目的过程和经历，为下一次的项目启动提供参考经验，完善不足，避免在类似的项目中出现可能存在的相同的错误发生。

第五篇：软件开发项目管理应用(4天)

软件开发项目管理应用（4天）

一、课程目的为了加强企业信息科技部门建设，提升信息科技部门人员管理技能，充分掌握并应用项目管理的流程、工具和方法，从而提高IT项目实施的效率和效益。拟开展企业信息化项目管理应用培训，经培训使参训人员能用项目管理方法论指导企业信息规划和IT项目建设。

二、课程收益

熟悉项目管理概念和工具技术的应用

了解项目实施和监控过程方法

理解企业信息科技部门IT项目管理体系，掌握企业信息中心项目化管理应用。

三、授课方式

课程讲解、实战训练、案例研讨、模板演示、讨论引导

四、课程对象

分管领导，部门经理、项目经理、项目成员、信息中心人员及对项目管理有兴趣的员工。

六、课程大纲

破冰

（一）项目管理过程活动梳理

1.1项目与项目管理

1.1.1信息化项目管理应用

1.1.2项目管理过程活动流程介绍

1.1.3美国项目管理学会(PMI)项目管理专业人员(PMP)考试制度 □ 问题解答

1.2.软件开发项目管理过程

1.2.1软件开发项目生命周期选择

1.2.2.1新版项目管理思想生命周期的化繁为简

1.2.2.2 HP项目生命周期模型介绍与研讨

实战训练1：确定企业项目生命周期方法与模型

1.3.软件开发项目实施组织环境和项目管理因素

1.3.1软件开发项目组织环境：环境—方法—人—工具

1.3.1.1项目组织环境对项目的影响

1.3.2项目接口与支撑体系

模板演示1：IT项目多功能团队接口/界面和工作关系管理

1.3.3软件开发项目管理状况分析

1.3.3.1项目目标和过程成功要素

1.3.3.2导致项目失败的12大因素

（二）软件项目管理方法技术实操演练

2.1项目启动

2.1.1成功的软件开发项目启动

2.1.1.1项目分类（IT工程类项目、软件开发类项目、系统维护类项目……）

4.1.1.2软件开发项目组织类型与项目利害关系者分析管理

4.1.1.3项目角色管理与职责矩阵

2.1.2项目经理选择与项目经理的责权利

2.1.2.1项目经理应该具备哪些能力标准和素质要求

2.1.2.2没有合格项目经理怎么办?

演示：技术型项目经理如何转到技术管理型项目经理

2.1.3软件开发项目经理的两个权利来源

2.2项目规划

2.2.1约定开发过程规则,是项目管理流程,制度,模板和控制的基础保障

2.2.2如何定义软件开发项目的多目标性

2.2.3从软件开发项目需求管理到完成概要设计

2.2.3.1业务需求如何转换为技术需求,技术需求如何转换为产品需求

2.2.3.2需求的接口界面

2.2.3.3如何杜绝需求评审走过场

2.2.3.4项目不断提出需求变更应该如何应对？

2.2.3.5项目需求变更的应对措施：时段法、版本法、有无法……

2.2.3.6如何与业务部门达成需求变更流程规则？

案例研讨：中兴通讯如何管理定性需求

2.2.4 IT项目规划进度规划

2.2.4.1软件开发活动的逐渐明晰与PERT估算方法应用

2.2.4.2中国移动软件开发项目活动工期估算方法介绍

2.2.4.3如何使计划适应变化？

2.2.4.4可操作性和可控计划是如何做出来的？

2.2.4.5三级计划制定的时间点

2.2.4.6开发计划制定的步骤和注意事项

2.2.5、IT项目资源规划

项目多、时间紧、人员少，项目如何确保满足业务要求，过程中又如何实施进度监督与控制，资源或需求发生变化后的进度基准如何确定，对项目进度应如何评价？

2.2.5.1如何调节资源使用的高峰低谷

2.2.5.2进度压缩在软件开发中的应用

2.2.5.3如何通过绩效杠杆调节软件架构师、开发人员和测试人员的协同工作

2.2.5.3.1软件开发项目的考核KPI和考核方法

2.2.5.3.2如何设置开发项目激励奖金？

2.2.5.3.3软件开发项目经理如何评价项目成员绩效？

2.2.6 IT项目费用规划

2.2.6.1费用估算

2.2.6.1.1费用估算依据

2.2.6.1.2费用估算方法

2.2.6.1.3准备金分析

2.2.6.1.4实现价值分析

2.2.7 软件项目质量规划

2.2.7.1 IT项目管理与ISO

2.2.7.2 IT项目与CMM

2.2.7.3 IT质量规划

2.2.7.4SPPP、SQA、QC和SCM

2.2.7.5质量管理工具(益本比分析、基准对照、实验设计、因果图、控制图、流程图、直方图、帕累托图、趋势图、散点图、统计抽样、检查)

2.2.8 制订项目管理计划

2.2.8.1项目管理计划的作用

2.2.8.2项目管理计划的适应范围与应用裁剪

2.2.8.3项目管理信息系统、配置管理系统、变更控制系统之关系与作用 模板介绍：项目管理计划模板介绍

2.3.软件开发项目指导、执行与控制

2.3.1如何实现软件开发项目的过程可控、可视、可度量

2.3.2项目绩效状态报告

模板演示:IBM软件开发项目绩效状态报告模板

2.3.3软件开发项目经理如何指导项目成员执行项目任务

案例研讨:某集团信息中心如何通过建立项目化运作机制,解决项目资源冲突问题

2.3.4如何保证各配合部分提交的工作包是符合质量的?

2.3.5风险应对与监控

2.3.5.1风险规划,让项目防患以未然

2.3.5.2谁来识别项目风险?如何识别项目风险?

2.3.5.3如何评估风险给项目带来的机遇或影响?

2.3.5.4风险评审、风险审计、风险责任

2.3.5.5为什么需要对风险进行集中管理

模板演示:风险管理列表

2.3.6如何规避同样的问题重复发生

模板演示:问题管理流程模板示例介绍

2.4.软件开发项目收尾

2.4.1项目验收

2.4.2项目总结

2.4.3项目后评估

2.4.4如何做好项目移交

2.4.5项目成员解散

模板演示:软件开发项目总结报告

2.5.软件开发多项目管理

2.5.1多项目管理工作方式

2.5.1.1项目群管理

2.5.1.2项目组管理

2.5.1.3项目总监与项目池、资源池

2.5.1.4多项目的多级控制

(三)软件开发项目的激励方法

3.1软件开发项目团队建设与激励

3.1.1软件开发项目经理权利类型

3.1.1.1职位权利,强制权利,奖赏权,专家权,个人魅力,权威权利

3.1.2项目经理领导与管理方式

3.1.2.1专制型,民主型,协商专制型,协调型,引导者

3.1.3软件项目团队建设活动

3.1.3.1例行活动、项目阶段重大成果……

3.1.3.2软件开发团队激励:项目管理之星、项目攻关荣誉奖、月度之星、季度明星、BUG克星……

模板演示:软件开发团队建设指导模板

3.1.4软件开发项目激励方法

3.1.4.1需求法,双因素法,XY方法,期望法,光环法

3.1.4.2项目激励方式:荣誉奖、积分卡、发表扬信、公告、宣传,奖赏

3.1.5项目团队绩效评估

现场训练:抱团打天下

(四)软件开发项目的有效沟通

4.1项目沟通技巧

4.1.1项目沟通渠道计算

4.1.2项目沟通类型

4.1.3项目沟通模型

4.1.4如何将技术语言转换成业务语言进行有效沟通

4.1.5有效的项目沟通影响因素

游戏:项目沟通模拟游戏

4.1.6沟通宝典：项目利害关系者政治关联分析法

案例研讨:根据案例资料识别和管理项目利害关系者

4.2常见的冲突及解决技巧

4.2.1冲突来源

4.2.2有效的冲突管理思维

4.2.3项目冲突的五种有效解决方法

4.2.3.1规避,缓和,折中,正视问题,妥协 课程总结

培训联系:左老师

电话:021-63233980

手机:***

QQ:2749919646

邮箱:zuozl@tsinghui.com