做一个成功的软件项目经理

做一个成功的软件项目经理

概述

要想做一个成功的软件项目经理需要有丰富的管理知识，同时要有全面的技术知识。

同时在知识的结合下在实际中应用管理学的计划，组织，控制，激励，领导等职能，发挥个人管理的长处，再项目组成员及客户前发挥亲和力、领导力，并做好时间管理和沟通管理。

最终带领整个项目团队不断成长发展并高效的完成整个项目过程。

 

下面为软件项目管理成功相关联的要素：

软件项目经理就是要在有限人员，有限的技术，做好团队的管理让团队向自我管理发展并及时调节团队的冲突，让项目按时保质量的完成。

总的来说软件项目经理需要知识：管理学，软件工程学，开发实践知识T技术知识

 

 

项目成功度量

项目管理成功最理想情况：“多、快、好、省”。

“多”指工作范围大，“快”指时间短，“好”指质量高，“省”指成本低。

这个目标是需要进行权衡那些是否有必要。

目标明确内容：多与快、好、省是正面冲突的。

所以要尽量减少“多”，做好“快”，“好”，“省”。

即尽可能的限制需求，同尽可能的增加技术熟悉成员。

通过计划，评审，考核推进整体项目进展。

通过规范，考核，自我测试，自动测试做好质量的控制。

同时要发动所有人员的积极性，高效完成任务。

项目成败的关键点

抽象分析

为了分析项目成败的关键点对项目相关元素进一步的抽象分析。

如下图：

 

说明：

1.一个项目是否成功站在系统抽象化角度时(输入条件-> 处理 -> 输出结果)

如果 要保证输出结果的正确:跟输入条件有关，同时在处理时起决定做用。

分析情况如下四种：

同上图:

 

分析上图并通过机率算：输入条件影响成功占50%, 处理过程影响成功占 50%

因为输入条件是不可控的，所以要提高成功率只能通过提高处理过程正确并及时纠正错误。

所以做为一个成功的项目经理面对着资源，需求，时间，成本等条件的不合理时，

必须第一时间强硬的进行纠正，否则项目再怎么努力将面临失败。

 

2.通过对整个分析从抽象到具体细化关键点我们会进一步发现：

如下图：

同上图:

 

对于软件项目更加主观化后：

需求所占的比例很大:

a.       关键用户需求合理？

b.       用户和开发对需求理确？

c.       文档清楚确认？

d.       需求变更管理？

所以做为一个成功的项目经理必须让用户及开发对需求理确正确，并形成文档及时签字确认。同时尽可能的限制要求.

 

 

项目管理中又细分为：

个人管理：权威树立、有力领导(执行力)

a.       沟通 – 把信息及时传递给大家

b.       亲和力 –  处理好人群关系

c.       领导力 – 指令确保执行到位

d.       时间管理 – 关键点，

团队管理：高效团队管理

a.       互补？(技术不成熟)

b.       互助？互督？

c.       冲突解决

d.        

项目过程管理：目标，计划，质量，风险等管理

1．  目标清楚—任务明确

2．  计划合理—执行有力

3．  自我测试及时完整？集成测试有效

 

 

 

总的来说：要想项目成功就要，多提要求，限制需求，做好沟通，做好团队管理，做好过程中的计划，质量，风险管理就可以把整体项目成功完成。

 

成败因素汇总

失败的最主要的原因是缺乏有效的项目管理。并且认为技术即不是问题也不是解决方案。问题和解决方案在于人和过程。

 

需求不明确

计划缺失 (计划不周，执行不周)

50%以上的失败项目是由于计划不周而造成的。

 

影响项目成功的因素：

项目的目标、范围是否明确；

是否获得领导的积极支持；

项目的组织是否健全、稳定；

是否建立了有序的、有效的、良好的沟通渠道；

是否具有有效、全面的项目管理，严格的变更控制；

是否建立了良好的、积极的、团队合作的工作氛围；

项目经理PM的经验；

 

项目失败的主要因素：

项目目标不明确

缺乏有力的领导

缺乏高层管理者的支持

技术问题没有解决

不合理的预测

跨部门协作不得力

计划和控制不力

过多的不可控变动

责、权、利不清

资源配备、供给欠佳

缺乏有效的沟通

项目经理缺乏魅力、影响力

 

 

失败点：没有发动成员激急性，没有及时解决冲突，没有把困难分担下去。

失败点：需求没有及时确认，并完整的确认，无用户需要的完整的需求文档。

失败点：设计采用了不成熟技术,没有做好共用重复劳动。

失败点：人员开发技术不熟练

失败点：计划跟实际脱节

 

技术人员的开发能力不行

 

理解管理

 管理理论知识

管理是通过计划、组织、控制、激励和领导等环节来协调各种组织资源，以期更好地达成组织目标的过程。

计划就是探索未来和制定行动方案。（目标管理,可行的目标，可操作的时间表）

组织就是建立企业的物质和社会的双重结构。（层级原则，管理跨度原则，统一指挥原则，责权一致原则，适当的授权原则，分工与协作原则，执行与监督分离原则，精简与效率原则

并动态原则：职权和知识相结合的原则，集权与分权相平衡原则，弹性结构原则）

指挥就是使其人员发挥作用。

协调就是连接、联合、调和所有的活动和力量。

控制就是注意一切是否按已制定的规章和下达的命令进行。

 

马基雅弗利四项领导原理：

1．  领导者必须要得到群众的拥护。（一，群众要拥护他作为领导者；二，领导者做事要征得群众的同意）

2．  领导者必须维护组织内部的内聚力。领导者必须把组织的成员紧紧地团结在自已的周围，使自已及所在的组织具有吸引和。

3．  领导者必须具备坚强的生存意志力。领导者要有坚忍不拔的精神，不软弱，不气馁，能为组织和自已的生存不断奋斗。

4．  领导者必须具有崇高的品德和非凡的能力。

 

法约尔管理14原则

1.       劳动分工(专业化分工)

2.       权力与责任（职位权力和个人权力，提高个人素质是避免滥用权力最好办法）

3.       纪律(纪律来自于好的领导，尽可能明确而公平的协定，并合理执行惩罚)

4.       统一指挥（一个下属只接受一个上级命令，防止双重命令）

5.       统一领导（凡是具有同一目标的全部活动，仅一个领导者和一套计划,便于资源应用协调指向同一个目标）

6.       个人利益服从集体利益。（领导必须经常监督并以身作则，以缓和两者矛盾,使一致）

7.       合理的报酬（薪资制度应当公平，对工作成绩与工作效率优良者应有一定限度奖励）

8.       适当的集权和分权（提高下属重要性采用分权，降低重要性采用集权）

9.       跳板原则（两领导两下属之间直接联系，必须先请示，后汇报）

10.   秩序（凡事各有其位,有效组织及审慎选人）

11.   公平（努力使公平感深入人心）

12.   保持人员稳定（鼓励职工做长期的服务）

13.   首创精神（在不违背职权和纪律的情况下，鼓励和发挥下级的首创精神）

14.   人员团结（严守统一指挥原则并中强情况的交流，多用口头沟通，尽一切可能保持和巩固人员的团结）

 

梅奥人群关系理论：

提高生产效率主要途径是提高工人的满足度。满足度越高,士气就越高,生产效率也就越高。

1．  强调对管理者和监督者进行教育和训练，以改变他们对工人的态度和监督方式。

2．  提倡下级参与企业的各种决策，以此来改善人群关系，提高职工士气。否定采取解雇和人事考核制裁等强制性手段迫使职工服从的管理方法。

3．  加强意见沟通，允许职工对作业目标、作业标准和作业方法提出意风，鼓励上下级这间实行意见交流。

4．  建立面谈和调解制度，以消除不满和争端。

5．  改变干部的标准。重视管理干部自身的人群关系以及协调人群关系的能力。

6．  重视、利用和倡导各种非正式组织。重视美化工作和宿舍环境，建设娱乐设施、运动设施、生活福利设施等。

 

巴纳德的权威接受论：

管理者的权威并不是来自上级的授予，而是来自由下而上的认可。管理者权威的大小和指挥权力的有无，取决于下级人员接受其命令的程度。最重要的是取得下级的同意、支持和合作。

 

 

个人管理

目标：

 

项目经理的技能：

 

1、领导能力

2、人员开发能力

3、沟通技巧

4、人际交往能力

5、处理压力的能力

6、解决问题的能力

7、管理时间的能力

 

培养项目经理所需要的能力：

 

1、获取经验

2、寻求别人的反应

3、自我批评总结，改正错误

4、与一些具有你想学习的技能的项目经理进行探讨

5、参加培训项目

6、参加组织团体

7、阅读

8、参加自愿活动

 

亲和力

领导力

时间管理

个人修养—以身作则

团队管理                      

1、建立一个结构合理的项目组

2、寻找合适的人选，熟悉他们技术方面管理方面的长处和弱点，了解他们的能力

3、树立并保持项目组的团队精神

4、争取管理部门的支持

5、项目组内经常的有效的沟通

 

团队的形式

 

 

团队定义中的几个方面对我们理解一个团队是重要的。

 

少量成员	n       2-25人 n       8-12个为最佳
互补技能	n       技术和功能方面的特长 n       解决问题和决策技能 n       人际技能
对一个共同的和绩效目标做出承诺	n       绩效的分离单元 n       管理层通过在公司绩效需求之内定义权限的界限和范围来指明方向。一个共同的目的使团队揉成一个整体，总体力量大于单个个体力量之和 n       团队将各种指标转换为具体而可衡量的绩效目标 n       具体的绩效目标有助于团队跟踪进步
共同的方法（APPROACH）	n       成员间的社会契约与他们的目的相关联并指导他们如何一起工作 n       参照目的与目标不断调整
彼此负责	n       在实现团队目的、绩效目标和方法的过程中，团队成员逐步形成默契的配合 n       彼此承诺和信任

 

 

很多情况适合小组运作而且能从小组协作中得益

运用小组而不是团队，适合于以下情况：

•          个人角色和职责对成果的影响是首要的因素

•          工作成果的协议是在所有成员与领导之间确定，而不是基于相互的责任

 

 

 

给出一个良好定义有助于澄清团队（TEAM）与团队工作（TEAMWORK）行为，后一点在任何组织形式中都是有价值的。

基于的团队工作行为：

•         相互监控绩效

•         提供并接受反馈

•         维持有效的、闭环的沟通

•         愿意并且有能力相互支持

•         在适当场合需要的不同灵活技能

•         随时间变化和成熟

 

SDWTs和SMWTs与传统的工作小组或需要指导的工作团队有着显著不同的特性

特征	工作小组或需要指导的团队	自我指导和自我表现管理的团队
领导	强，以领导为中心	分担领导的角色
责任	只有个人责任	既有个人的也有共同的责任
目标	小组的目标与部门职责一致	团队决定自己特殊的目标
工作成果	个人的工作成果	集体的工作成果
沟通	运用有效的会议形式	鼓励用完全开放的会议并提出有效的解决方案
考评	用他对其他人影响的程度间接的评估	直接用集体的工作成果来评估
工作风格	讨论，决定和委派	讨论，决定而且真正地一起工作

 

团队工作可以影响的绩效和有效性

团队工作使能的条件

团队成功基于个体绩效

团队是部分的总和，而不是一个表演者

自身的成功取决于其它人的成功

团队任务的完成取决于团队成员

 

 

目前大部分公司员工是一个在指导下工作的团队。
策略也经常被自我指挥的工作团队所修改。

 

 

为使管理和员工向自主指导的工作团队方向转变，需要新的行为方式

 

 

什么时候建立自我指挥的工作团队

•         激励发起人、领导和成员

--乐意接受新的文化

--乐意承担新的文化

--乐意学习与同事相互影响的新方法

--敢于向现状挑战

•         合理的逻辑考虑

--小数量（8-12个成员为佳）

--团队成员的地理位置

--所有成员来自相似的业务部门

--考虑一个或少量的业务合伙人作为团队成员

 

 

新的管理范例
今天的监督者/管理者的职责转变到教练/领导者的角色

监督者/管理者	教练/领导者
检查	促进
指挥、管理	教练、协调
告诉	建议、指导
提供资源	参与团队一起确认和保护所需的资源
解决问题	顾问、建议
关注于群体工作结果	在团队以外工作以获得团队目标支持
发布正式和非正式的赞誉/承认	加入并与团队成员共获成功

 

 

有效的团队 团队特征

 

 

团队工作形式的意义

团队形成的过程

 

高效团队建设的整个旅途

关注点：

确定团队运作指南：规范

 

团队的组成

项目过程管理

沟通管理:

让所有人参于规范制定与执行，风险识别与控制，

要深入每个人的内部，了解大家并跟大家共处。

管理风险

要让大家明白项目是所有人的项目。

把困难传达到项目组每个人，让每个人明白进展与遇到的困难。

让每个人做好自我测试，并适当用自动测试。

做好考核检查,总结，反思那里没有做好。

范围管理：

需求不清，范围不明

需求确认过晚

需求文档描述不清

计划管理:

如何写项目目标：

•     我们要做什么？

•     我们为什么要做它？

•     它将与什么时候完成？

•     需要哪些资源？

•     如何评估它的效果？

•     项目在哪里完成？

•      

计划的作用：

1、计划是连通团体的经脉

•     压力自上而下充分传递

•     提高团队工作效率

•     明确职责

2、计划是走向目标的诺言

•     确定工作总目标

•     控制开发进程

•     计划是工作的指南针

3、计划是交流沟通的工具

•     工作得以量化

•     获得关键路径

•     合理地调配资源

•     清晰地反映产品状态信息

4、计划是实现成功的保证

•     规范开发活动

•     约束和协调的依据

•     问题的预警与防范

一个完整的计划包括：

计划制定的流程

 

计划制定的原则：

•     产品计划的制订是由上往下制订，由下往上修改的过程；

•     在制订每一层计划时均要充分考虑上下层计划的约束关系;

•     在与各相互关联的计划及与职能部门充分沟通和协调的基础上来制订产品的计划。

 

计划制定的要素：

完整性:

•     是否包含了版本及所有特性的计划；

•     是否全流程的计划（硬件、软件、测试、制造、市场技术、技术支援、生产等）；

•     是否产品卖出去的计划（资料、宣传、操作指导等）；

层次性:

•     是否根据产品的特点进行了分层；

•     每项活动是否分解到个人、时间不超过一周；

•     各层次之间配合关系是否明确；

•     特性是否归类

合理性:

•     计划进度是否符合市场需求;

•     技术难度及解决情况是否支撑;

•     资源需求是否合理;

•     资源需求是否可以保证;

•     各阶段、步骤、任务的时间安排是否合理；

•     关键物料的货期是否影响计划；

•     是否符合流程；

•     是否设置了关键路径和里程碑；

•     每个活动是否有结束的标志。

 

WBS：

 

项目计划形成之前，最好先画WBS表（Work Breakdown Structure），主要原理是：将任务逐级分解直至个人，在矩阵中体现为：先确定横向有多少结点，再将每一结点任务逐渐细化直到个人，工作分解图（WBS）实际上就是将一个复杂的开发系统分层逐步细化为一个个工作任务单元，这样可以使我们将复杂、庞大的、不知如何下手的大系统划分成了一个个独立的我们能预测、计划和控制的单元，从而也就达到了对整个系统进行控制的目的。

WBS示例：

 

WBS的作用：

1、将大系统变成具体的小工作单元，使复杂→简单，难以预测→易于预测，难以控制→易于控制

2、是制定项目计划、编制项目预算、确定项目组织、分配工作的基础

3、使我们对开发项目情况有了更加深入详细的了解，特别是对应做的工作有了更为透彻的概念

4、便于了解整个项目开发系统的结构，便于合作、协调

 

WBS分解：

 

WBS分解的原则：

将主体目标逐步细化分解，最底层的任务活动可直接分派到个人去完成；

 

WBS分解的方法：

自上而下与自下而上的充分沟通

一对一个别交流

小组讨论

 

WBS分解的标准：

分解后的活动结构清晰；

逻辑上形成一个大的活动；

集成了所有的关键因素；

包含临时的里程碑和监控点；

所有活动全部定义清楚；

 

任务时间的估计和计算：

•     让某项活动的负责人进行该项活动的工期估计是较好的做法。

•     任命一位有经验的人进行他们所负责项目的工期估计

•     历史数据可以作为参考

•     估计应既富于挑战性，又符合实际，稍微激进些的估计比过分不保守的估计要好一些

•      

对高度不确定性任务时间的估算：

采取对每项分工作估计三种时间的办法，然后加权平均计算出这项分任务的计划时间。

1、最可能时间T可能

    根据以往的直接经验和间接经验，这项工作最可能用多少时间完成，也就是我们一拍脑袋所确定的时间   

2、最乐观时间T乐观

    当一切条件都顺利时该项工作所需时间

3、最不利时间T不利

    在完成过程中不利条件都在起作用时该项工作需要的时间

 

    计划时间T计划=（T乐观+4T可能+T不利）/6

 

规范化的活动与经验数据库（模板）:

PERT：

PERT（网络计划评审技术）是以网络图的形式制定计划，求得计划的最优方案，并据以组织和控制开发进程，达到预定目标的一种科学管理方法。

1、用网络图来表达一项开发计划中各工作（阶段、模块等）的先后顺序和相互关系；

2、通过计划找出计划中关键工序和关键路线；

3、通过不断改善网络计划，选择最优方案并付诸实施；

4、在计划执行的过程中进行有效的控制和监督，保证合理地使用人、财、物，按预定目标完成任务。

 

  “向关键工作要时间，向非关键工作要资源”

PERT图示例：

GANTT图：

•     是对任务的一种罗列，标明任务名称、开始时间、完成时间、工期、资源名称等。

•     采用GANTT图虽然没有PERT图直观，但罗列问题任务可较多，特别适合计划条理性不是很强的工作；   

 

演练：各组根据自己的项目

       1、列出WBS表；

       2、画出PERT图；

       3、找出关键路径。

 

项目计划控制的难点：

1、研究与发展缺乏先例

2、有未预计到的技术问题

3、由于新技术或需求变动而造成的计划改变

4、时间周期不定

5、专业人员固有的乐观主意

6、人的生产率的可变性

 

计划监控

•          各级监控点的设立遵循两个原则：

       A、重要的里程碑

       B、时间间隔比较合理

•          监控计划的表现形式为：计划监控总揽图和计划监控一览表。

•          计划监控总揽图将各级计划的关键点浓缩在一起，直观，便于控制。同时，各监控点在时间上也形成对应。

•          通过计划监控一览表，严格定义了每一监控点的完成标志，以使监控点不会产生歧义性的理解。

计划更改与状态转移：

•          计划更改须经过评审，其评审批准部门同计划制定。一级计划更改须填写一级计划更改单，并修订相关计划。

•          原则上，一级计划不予修订，二、三级计划要及时修订滚动。以保证一级计划最终按目标实现。

•          在版本立项通过后，即为该版本建立状态转移表，直至版本转产，状态转移表是一级监控的检查档案。

•           

•          正规控制

在每周末、每月末或每个阶段末进行情况汇报和检查等，通过PERT图和GANTT图以及预算报告和工作总结及阶段评审的报告等及时发现问题和进行评审

•          非正规控制

通过工作之外的交流和沟通进行控制，在非正规控制的场所要比在办公室更坦率、更诚实，这样能了解到正在酝酿的问题，这要比等到这些问题出现在情况报告中或某次会议上快得多

 

 

项目控制的五个步骤：

1、及时掌握最新情况和项目进展

2、分析计划进度和质量产生偏差的原因

3、处理偏差

4、公布修改方案及滚动的计划

5、周知管理部门

项目经理如何召集会议：

为明确计划和方案，项目经理应该定期不定期召集例会，例会可以讨论以下问题：

•          里程碑计划为什么没有完成？

•          其影响如何？

•          工作何时可以完成？

•          是否需要替补行动计划？

•          何日才能回到计划进度上来？

项目情况回顾检查会：

回顾检查会准备：

•          明确界定会议的目的

•          议程要明确，并要提前进行准备

•          邀请必要的人到会，尤其是关键人物入会

•          如果有重要人物参加，最好让你的发言人预先演习

•          以对你最有利的方式组织项目回顾检查会

•          遵守议程

•          自上次回顾会以来的主要成就

•          进度状况、成本状况（实际与计划相对照）

•          重大问题及行动计划

•          下个阶段的计划

•          特殊议题（具有紧迫性的议题）

•          总结由本次会议产生的各行动事项，明确责任人和时间

•          切勿超时

 

 

质量管理:

让每个人明白产品质量跟每个人有联系。

让开发人员不断完善开发文档，必须思考清楚:日志完整，异常情况及处理，测试是否周全。

 

规范工作

把规范（设计开发测试规范）通过不同途径传达到每个成员，并要多次传达。

途径1 会议上说明,培训， (保证规范被学习)

途径2 检查规范情况,并通报执行情况 (保证规范被执行)

途径3 多次沟通规范执行情况，是否需要完善, 让大家一起来制定规范(保证规范可执行)

 

做好测试

做好自我测试

适当的自动测试

做好回归测试文档

做好测试记录

文档管理：

1、正规的文档要受控，要盖章，参考别人文档时一律以盖章的为准，未盖章的草稿文档不要随意放置

2、文档必须要有审核后方能归档，作者和审核人不能是同一人，本着最了解的人最有权的原则，不能走形式

3、版本升级后和版本文件要收回归档到文档管理部门，并注明版本已升级

4、注意文档保密性，不要随意复印，草稿应在归档后销毁

5、为保持科研成果，项目经理在批准项目组人员复印文档时，要注意是否与其工作有相关性

6、养成良好的工作习惯，工作进行到一定阶段就马上形成文档，文档应当成为工作结束和计划完成的标志

 

阶段评审：

    阶段评审是保证质量，提高效率的好办法，但要真正让它发挥作用，还必须认认真真地明确评议的要素，划分清楚评审的职责

1、何时进行评审

2、谁来评审

3、评审什么（不要陷入细节）

4、下什么结论（避免会议没有结果或形不成决议、无人下结论或拍板）

 

产品测试：

测试过程规范各阶段输出：

1、产品计划阶段

       SVVP、WBS 

2、需求分析阶段

       系统测试计划

3、概要设计阶段

       集成测试计划

       系统测试方案

4、详细设计阶段

       单元测试计划

       集成测试方案

       系统测试用例，规程

       系统预测试用例

5、编码和单元测试阶段

       单元测试方案

       单元测试报告

       集成测试用例，规程

       系统测试用例，规程

6、集成测试(执行)阶段

       集成测试报告

7、系统测试(执行)阶段

       系统预测试报告

       系统测试报告

标准化管理：

•          公用基础模块是在不牺牲差异的情况下优化公用和重用

可靠性管理：

产品的可靠性主要包括三方面内容：

1、产品的可靠性：在规定的条件下，规定的时间内，产品执行所需功能的能力。指标为可靠度和平均失效间隔时间MTBF

2、产品的可用性：产品在一未知时刻，需要执行任务时，处于可工作可使用状态的特性，主要指标为可用度

3、产品的可维修性：在规定条件下使用产品在规定的时间内，按规定的程序和方法进行维修时，保持或恢复到能完成规定功能的能力。主要指标为：平均维修时间MTTR

 

可靠性与产品成本：

    故障成本是所有公司面临的一个问题，从成本角度来看，任何真正的质量改进，必须从降低故障成本入手，从经费的分配来看，只有增加预防成本才能有效地降低故障成本。

 

可靠性管理包含的基本内容：

1、系统、模块、外围设备及系统软件的可靠性要求

2、失效报告分析与纠正系统

3、设计质量的评审

4、工艺质量的评审

5、产品质量的评审

6、已售出设备及技术状态的管理

 

可维修性：

可维修性包括：

1、自含的计算机辅助故障诊断

2、自检测

3、模块设计

4、模块化软件

5、标准模块

6、自建备件概念

7、较少模块数量

8、大量使用冗余技术

 

如何在设计中构建质量：

质量是设计出来的，在开发设计中应该注意质量的管理：

1、文档的审核一定要全面

2、所选元器件尽量从优选库中选择，如果是新的元器件，最好通过认证后再选取

3、测试的过程要有详细的联调测试过程记录

4、测试验收手册要经过详细的评审

 

设计更改及维护：

产品设计更改是开发过程中的经常现象，往往导致软、硬件版本的不一致和系统新的错误，项目的设计更改需要严格的控制。维护是软件在交付用户之后的设计更改，由于已经发布给用户，维护和版本升级更需要严格的控制。

1、软件开发的很大一部分资源花在更改和优化原有的设计上，对设计更改决不能持一种“改一改就行”的态度，要充分重视

2、维护占软件开发费用和软件生命周期的一半以上，设计更改更是大量地在维护中实现，由于维护阶段软件已经发布，维护时更加要注重质量，加大测试的力度

3、软件的更改不是影响系统一部分的质量，而是影响很大一部分甚至是整个系统的质量，必须进行回归测试

4、更改后的软件必须经过充分测试，相关部门审查通过之后才能归档和发布

 

 

 

风险管理:

公开讨论风险，让所有人动脑思考风险, 发现风险及时反馈。

建立风险控制文档，让所有人一起动脑想解决方法。

对上： 把问题困难反映到领导层，不要期待都要项目组自我负担.

 

 

开发原则(RUP最佳实践)

迭代展示价值

实践1.管理风险

实践2.在迭代中执行项目

实践3.采纳并管理变更

实践4.客观地度量进展

持续关注质量

实践5 测试你的代码

实践6 适当利用自动测试

实践7 产品属于每一个人

平衡利益相关者优先级

实践8 了解领域

实践9 从用户的角度描述需求

实践10按优先级实施需求

实践11利用遗留系统

团队间的协作

实践12 建立高绩效的团队

实践13 围绕架构进行组织

实践14 管理版本

提高抽象级别

实践15 利用模式

实践16面向组件与服务的架构

实践17 积极推进重用

实践18 对主要观点建模

适应过程

实践19 合理精简过程

实践20 不断重新评价你在做什么

项目经理实际操作

项目启动

项目一开始必须要不断给项目组灌输管理理念。

对团队精神，互助，互督，沟通, 项目对每个人都很重要

让每个人参于制定规范,执行规范，监督规范执行。

做好自我测试，产品是属于每个人。

 

项目组长 组成

从项目启动并组织核心团队—项目组长

 

项目开始：制定规范:

1.       项目组开发设计规范

2.       项目成员沟通规范

3.       项目考核规范

4.       项目现场行为规范

5.       项目编码规范

 

项目开始：制定文档模板

制定各种文档模板（需求说明，数据库，概要设计，详细设计，开发说明）

用旧的系统演示或采用（UI界面图进一步的演示）

 

制定管理计划

《管理计划v.1》

《考核表v.1》

需求阶段

跟客户沟通需求-> 用户角度描述需求 ：及时确认需求并现场签字确认

 

跟客户沟通注意事项:

1． 关键开发人员必须到场

2． 及时把会议纪录汇总，签字确认

3．  

需求确认注意事项

及时审查需求文档

 

完成文档

《需求规格说明》

《计划时间表》

《管理计划v.2》

 

注意事项

设计阶段

要多次评审内部设计。

对于共用的部份要及时推进。

 

完成文档

《数据库设计》

《概要设计》

《详细设计》

《架构及共用设计》

《开发说明》

注意事项

做好配置管理,

做好版本控制

 

开发阶段

做好配置管理

项目经理面临的困难及解决

1.       项目人员不足(向领导追要人员, 当处理过晚不断向上反应)

2.       项目人员开发经验不足（培训）

3.       项目人员冲突（对事不对人,增加沟通机会）

4.       需求确认过晚（当处理过晚不断向上反应）

5.       需求规格未及时签名确认（当处理过晚不断向上反应）

6.       开发技术不确认不成熟（关键技术必须要经过项目组评估）

7.       进行重复相似工作（前期必须要把重复工作独立先做）

8.       整体流程无法跑下去（关键点要先做，优先级完成需求）

9.       道理明白可实际上却无法操作（把问题提出来，让所有人参于解决方案）

10.   当遇到问题无法解决，及时向上反映

 

 

参考文档

《敏捷与秩序—RUP最佳实践》Per Kroll , Bruce Macisaac清华大学出版社

《现代管理学》张德 清华大学出版社

《软件项目管理理论与案例分析》吴吉义 中国电力出版社

《哈佛模式.项目管理》

《亲和力》

《领导力》