软件项目案例分析报告

软件项目案例分析报告内容摘要：

多的时候；其次是 1 对 1 的沟通，与下面的项目经理和团队成员 进行面对面沟通，可以及时了解项目进展、团队成员的思想波动，有针对的为其提出建议、解决方案，让团队成员感觉到项目经理的人文关怀，并传达公司的温暖；最后是避免不了的项目活动，聚餐、爬山、电影都是很好的活动方式，这取决与项目经理的权限和公司的财务制度。 8 组织能力 ： 这里的核心团队是指子项目的项目经理和关键技术人员，具体视不同的项目规模而定，人员的管理和沟通是有成本的，我个人认为 35 个人比较合适，太多的人员太多的细节靠一个人有限的精力是无法进行跟踪和控制的；当然这里的核心团队成员是指那些 技术和架构水平高超、有一定的项目管理能力、善于团队协助的人；核心团队成立越早越好，有利于项目的稳定和提前进入角色。 如前文中所述，不善于团队协助的人只能带来负面效应。 协作能力主要表现在项目内部各团队之间的协作、与公司内部其他团队的协作，与项目相关的友商的协作能力上。 软件工程 ： 软件工程按照传统的理解即需求分析、系统设计、系统开发、系统测试，这对项目经理而言是最起码的要求；就大部分国内项目而言，项目经理还是要样样都懂一点的，我不太赞同工作 3 年就自命不凡担当项目经理的人，技 术、业务、人际关系的把握的积累都是需要时间的；当然外企也有职业的项目经理，他们可以不专技术，而专注过程。 软件过程能力（ Software Process Capability）：描述了在遵循一个软件过程后能够得到的预期结果的界限范围。 该指标是对能力的一种衡量，用它可以预测一个组织（企业）在承接下一个软件项目时，所能期望得到的最可能的结果。 IT 企业有自己的软件能力成熟度，当然个人也有自己的软件能力成熟度，即体现在个人对过程的定义、监控、跟踪和度量上。 本人有幸在 3 家 CMM5 的公司工作过，不过仍称不上对 CMM 有多 深的研究，一来过于繁琐，再则软件能力成熟度 9 与所在的 IT 环境有密切的关系，过程的实施和度量需要一系列的保障；事实上严格遵循 CMM 流程的企业并不多，基本上都是为了内部评估而评估的；不过基于过程的思想值得项目去参考和学习。 关于本项目的话，如果一定要说有什么软件能力成熟度的话，我认为是 2级吧，项目管理的基本流程和系统文档已经有了，做类似的项目是具备一定的复制性的。 4. 架构能力 系统架构，这个与项目经理的角色和定位有一定关系，项目经理需要从整体上把握系统的各个环节，硬件、操作系统、数据库、软件、软件框架、甚至测 试，都需要有所涉猎，能做到一精多专已经是不错的状况了。 系统集成，这项能力与具体的项目有关，对于小项目来说只需要完成相应的业务功能，对性能的考虑、系统扩展型、系统部署、外围系统的接口要求并不高，所以对系统集成考虑的较少；如果实施大中型项目的话，项目经理最好具备起码的思想和评估能力。 关于系统架构、系统集成能力的提高，需要本身知识储备的日积月累、阅读大量的相关资料、以及项目实施过程中的学习，除此之外，别无办法。 5. 技术学习 项目经理需要的一个最基本的能力便是对他们的基本技术技能进行深度和广度的拓展。 目前的 技术知识更新换代过于频繁，但技术本身的内涵确实恒久不变的。 如 Oracle 从 9i 到 11g，其 Concept 变更的并不多，其基于关系的数据库特性在短期内还是无法改变的；如 java 和 . 之争，其核心仍是面向对象的；如各技术框架之选型，无非是实现展现层、业务逻辑层、控制层、数据持久层的分离；适当的扩展自己的技术能力也是与时俱进的一种体现。 10 6. 业务学习 相比技术而言，业务是更难学习的，尤其是财务、 ERP、金融证券业务等，与 IT 背景相距深远，但是又不能不学，作为项目经理需要与甲方业务方进行沟通，缺乏相关知识背景 ，会造成沟通上的鸿沟，甚至无法理解对方的意图。 当然并不是说项目经理一定要成为业务专家，事实上也是不太可能的。 7. 文档能力 项目经理一定要会写，这是由项目经理的工作性质所决定的，从解决方案、系统架构、需求文档、验收文档的编写，到设计文档、测试文档的规格要求，无不打上项目管理人员的烙印；撰写文档是组织自己思路进行深层思考的过程，如果文档无法表达明白的话，相信自己的思考也一定不成熟；撰写文档也是沟通的需要，会议纪要、需求文档如果写的不清不楚的话，双方如果进行确认。 想清楚才能写明白这是很简单的一个道理。 项目 经理的能力依据项目的规模和公司的成熟度有不同的要求，不能一概而论；举例而言，在本系统中假设时间为 100 的话，各项过程所占的比例分别如下： 图 21各个过程所占比例图 11 3 管理平台系统项目组织结构 如果你处在一个专业的 IT 公司，你未必会意识到项目组织结构对 IT 项目管理的影响，因为在大多数的专业 IT 公司中，基本上都是项目型组织或者强矩阵型组织结构，在这样的组织结构中，项目经理对项目全面负责，对客户高度负责，项目团队工作精力集中，协作强，沟通效率高，你会感觉到项目经理的权威和职能至少还是有保障的。 假如不幸你处于职能型组织或者弱矩阵型组织中，有时候你会感觉无所适从，人力资源的获取、管理、考核都无法正常开展，你会发现自己置身于一个弱势地位，团队建设有时会变得瘫痪，严重一点会影响团队合作甚至拖垮项目的总体进度。 图 32团队结构图 如果你要寻求合适的资源，首先需要向了解各个部门内部合适的人选，然后征求个人的选择和看法；其次与其直接汇报经理进行沟通，看该资源是否能全身投入；再次协调不成需要向上级领导进行汇报；需要经过层层沟通。 其次关于考核和冲突管理，关于考核，在弱矩阵型组织和职能组织中团队成员的考核是由汇报经理决定的， 这也决定了项目经理作为管理者的弱势地位，无法实施项目经理正常的权限， “ 要敢管 ” 就完全成了一句空话，更有甚者会出现团队成员未经允许擅自离队的情况；团队有合作也有矛盾，不同的团体之间也会 12 有矛盾产生，通常管理者会站在自己成员的角度进行所谓的护短行为，如前面所述，严重的影响了项目经理的积极性和整个团队的和谐和建设。 解决办法：如果无法改变 IT 部门的组织现状，则至少保证现场项目经理的权威，现场的团队管理应由项目经理全权负责，其次考核应该由项目经理和汇报经理双方共同决定，再次建立一个仲裁组织，对项目中遇到的冲突进行决策。 4 管理平台项目风险 项目风险管理是指对项目风险从识别到分析乃至采取应对措施等一系列过程，它包括将积极因素所产生的影响最大化和使消极因素产生的影响最小化两方面内容。 风险识别 确认哪些风险有可能会影响项目进展，并记录每个风险所具有的特点。 风险量化 评估风险和风险之间的相互作用，以便评定项目可能的产出结果的范围。 风险对策研究 确定对机会进行选择的步骤及对危险作出应对的步骤。 风险对策实施控制 对项目进程中风险所产生的变化作出反应。 本文无意讨论项目风险管理的一般流程和相应的控制，只是根据项目中 所遭遇到的问题把自己的一点心得体会表达出来，很多在其他人眼中也许算不上风险，有一部分甚至超出了项目管理的外延，但对于部分 IT 企。