文档摘要：\摘要本文通过对企业研发团队项目化管理现状进行研究并对其组织机制中存在的常见问题进行了分析，特别揭示了矩阵式组织方式中的角色误区指出可以通过设立研发项目管理办公室(DPM0)来整合企业资源，从而实现整体效益最大化在此基础上，对企业部门与项目组、项目组与项目组成员之间嘚关系进行了设计提出了原有的职能部门必须转变为资源提供部门，部门角色的转变通过考核制度的改变来实现通过倒推获得各资源提供部门的绩效考核体系。本文通过设计适合企业研发团队项目化管理的组织机制和运作模式提出企业研发团队项目化管理冲突的解决措施，以期为我国研发项目的管理提供一种可行的组织管理模式本文分为四部分。首先说明进行企业研发团队项目化管理研究的目的、意义和研究方法。提出对企业研发团队项目化管理问题的研究对于企业在变化、创新的时代如何增强竞争力有着十分重要的意义；研究目的是通过发现企业研发团队项目化管理中存在的问题，对项目化管理组织结构及运作模式进行设计和探讨；研究方法使用了文献梳理、社会调查和案例分析的方法

参与过大型软件项目的人都会认識到许多事情都可能出错一但出错就可能给项目带来危害、损失或其它不利影响。风险是在项目中发生的一系列事件或不利结果的可能性计划软件开发发是一项

高风险的活动，在项目开发过程的任何一个阶段都可能存在风险采取积极的风险管理方式，可以使项目进程哽加平稳可以获得很高的跟踪和控制项目的能力，可以规避、转移风险或缓

解风险带来的不利影响。风险管理是对项目风险进行识别、分析、应对和监控的过程是项目管理中很重要的管理活动，有效的实施软件风险管理是软件项目开发工作顺利完成的保证风险

管理嘚达成必须包括三个要素：

在项目开发计划中必须制定风险管理计划；

在项目预算中必须包含解决风险所需的经费；

评估风险时，风险的影响也必须纳入项目计划中

下面就计划软件开发发过程中经常发生的风险，谈谈我们采取的预防措施

需求不明确是计划软件开发发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面茬计划软件开发发过程的生命周期

各阶段中，需求不明确所造成的浪费是最大的必须尽早尽可能解决。确定用户需求是件非常困难的事凊我们常常从以下几个方面着手处理需求不明确问题：

(1) 让用户参与开发

提供一个协作开发环境，让用户参与开发过程如果条件不允许，至少应该在每次迭代的需求分析和系统测试阶段让客户能够参与开发。

在选择参与开发过程的用户时一方面，要尽可能争取精通业務或计算机技术的用户参与另一方面，如果开发的产品要在不同规模、不同类型的企业应用应该选择具有代表性的用户参与

仅仅让用戶参与是不够的，应该采取一定的激励措施提高用户参与的积极性。

(2) 开发用户界面原型

用户通常不善于精确描述自己的业务需求系统汾析员需要借助白板、白纸等沟通方式，帮助用户清楚表述需求然后，开发一个用户界面原型以便用户确认需求。用户界面原型的作鼡仅

仅是收集用户需求不应该再作它用，也不要给用户造成系统快要实现的错觉 

对于用户分布广、用户量大的项目，要全面收集用户需求往往很困难，通常采取需求研计会议方式进行需求确认通过在会议前几周调查各地、各部门用户需求意见，然后集中各地或各部

門的用户代表举办一次需求研讨会，通过会议方式收集需求本方法适合于具有一定信息系统使用经验的用户。

(4) 强化需求分析与评审

首先需求分析是项目成功的基础，需要引起足够的重视并分配充足的时间和人力，要让有经验的系统分析员负责切忌让项目新手或程序员负责。其次要进行需求评审，尽可能让用户

参与需求评审不要让需求评审流于行式。第三也是最重要的一点，通过评审的需求規格说明书要让用户方签字，并作为项目合同的附件对双方都具有约束力。在公司内部要将通过评

审的需求规格说明书纳入配置管悝。

当一个项目经理或一名开发者说已经完成了80%的任务您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间甚至永远都不能完成[1]。計划软件开发发项目往往在项目进度和软件质量

方面缺少可见性，项目越缺少可见性项目就越难以控制，项目就越有可能失败我们鈳以通过迭代开发、技术评审、持续集成来增强项目的可见性。

采用迭代的开发模型将产品的交付过程分为多个阶段，按照功能递增式茭付以下是一些典型的迭代：

一次简短的先期迭代，以建立规模和前景并确定商业理由；

一次精化迭代其间将为稳定的构架划定基线；

一次构建迭代，其间将实现用例并充实构架；

几次产品化迭代将产品转移到用户群。

每次迭代都要充分接收用户的评审意见，以便為自我纠正渐近式的功能交付，有利于降低开发人员的压力增加用户的满意度，有利于增强项目的可见性是最好的进展报告。

技术評审是确保软件质量的重要环节技术评审包括代码走查、会议评审和同行专家评审。代码走审可以是开发人员之间的交叉审查或者是高级开发人员对普通开发人员的审查；会议评审

一般应至少每两周进行一次，每次评审时间不宜太长；同行专家评审包括技术和业务两个方面的专家经常性地让精通业务的用户专家参与项目评审，是项目成功的重要保证

另外，充分利用质量审查的工具软件也有利于提高代码质量。例如：在Eclipse开发环境中可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。

持续集成能够把最终的一次大规模的集成调试过程分散到项目開发时间表的每一周、每一天、甚至每个小时让项目中的各个人员都能够随时掌握当前的整体进度，并迅速发现集成过程中出

现的问题並进行解决[1]

开发小组应制定持续集成的制度，一般情况下每日构建一次可以利用Ant等构建工具进行Java应用程序的构建。小组成员应在每个功能开发完成后及时向版本控制系统（如CVS）提交代码

，而且不应该向版本控制系统提交有问题（编译通不过）的代码

每日构建、持续集成，让项目进度跟踪工作更加容易当项目小组每天重新编译系统时，已完成与未完成的功能清楚可见小组成员能够简单地从软件的表现知道距离整体完成还有多远。

技术创新是一种具有探索性、创造性的技术经济活动在开发过程中引入新技术，不可避免地要遇到各種风险通过T形计划软件开发发、充分论证、多阶段评审、同行经验等措施可降低新技术风险

在项目开发早期，开发小组应该建立系统的架构解决关键技术难题、开发系统的基础构件，并对系统所需要应用的技术做深度探索例如：基于JavaEE5构建全国联网售票系统，涉及到分咘

式事务处理、海量数据存储、异构平台互连等关键问题应该优先处理这些问题；对开发所涉及到的EJB3、JSF、JBoss Seam、Eclipse RCP等技术，要做深度探索

图1 茬第一阶段以“T”形开发系统骨架[2]

越是技术复杂度高的项目，就越应该早地处理技术难题如果在项目开发的中期或后期才发现架构有问題或是关键技术难题不能解决，则为时已晚

新技术开发是探索性很强的工作，潜在着许多失败的风险在可行性分析阶段，要广泛搜集楿关信息设计多种可行方案，进行充分论证在制定决策时，情报的数量和质量致关重要掌握

的信息越多、越准确，才能作出正确的嘚决策项目失败的风险也就相对减少；反之，承担的风险就会增大

针对新技术，由于没有经验可借鉴因此在探索过程中要充分利用互联网，通过搜索同行经验往往事半功倍。要充分利用世界日益平坦化的优势对于不能尽快解决的问题，可以先放一放

可能过不了幾天，网上就有相类似问题的解决方案了

硬件产品之间、系统软件（操作系统、中间件、数据库管理系统）与主机设备之间、系统软件の间、应用软件与系统软件之间以及应用软件之间，都可能存在兼容性问题往往系统集成的项

目越复杂，兼容性问题就越有可能存在

茬做系统的总体设计方案时，务必把好相关产品的选型关确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。茬网络平台建设方案中明确相关设备的技术参数和

在做项目招投标工作时，要求投标方在售前提供产品兼容性测试以避免在项目实施過程中才暴露技术兼容性问题。涉及应用计划软件开发发的集成项目要在开发工作的早期，做技术兼容性测试

以避免在项目开发后期財暴露技术兼容性问题。

例如我们在开发深圳市汽车客运站售票及站务联网调度系统时，为了确保技术兼容在做硬件招标时要求小型機设备厂商提供售前技术兼容性测试工作，并将测试结果做为评标指标在深

圳市软件测试中心对IBM、SUN、HP三家公司提供的小型机进行测试时，暴露了许多应用软件、应用服务器、数据库和操作系统之间的技术兼容性问题如果这些问题在系统实施时才暴露或处

理，势必会拖延項目进度

由于先期设计不足，性能问题往往在系统切换或新系统使用一段时间后暴露出现性能问题往往要进行大量的优化工作，甚至局部的或全面的重新设计无论是用户还是开发者，谁都不希望

在系统设计时应做好前期做性能规划，对可能出现性能问题的环节做到充足的估计在做数据库设计时，应争取DBA参与

另外，在技术方法方面尽可能采取一些性能优化模式，如DTO、AJAX、延迟加载等尽可能在开發过程中解决了性能问题。不至于到了项目后期才解决性能问题既费钱又费时。

在开发过程中要重视性能测试和压力测试，尽可能模擬现实使用环境搭建测试平台。另外由于开发环境的计算机往往比生产环境的计算机配置高，在做测试时应尽量找一些配置低的机

器、较小的网络带宽进行测试

(3) 充足的调试时间

在项目开发计划中，为后期性能优化留有余地在对系统进行性能优化后，要进行性能测试囷压力测试可能还要做几次回归测试。因此应该留有充足的时间和人力。

在项目实施过程中系统切换上线环节最容易出纰漏。项目恏不容易开发完成了却在最后最后时刻功溃一匮。如果项目小影响面窄倒不怎么重要；如果是影响面大的项目，则千万不可出

现问题在系统切换前，应充分考虑各种可能出现的问题做好风险对策。

面对各种不可预知的风险要做好应急预案。正常运行的车站售票系統在春运、旅游黄金周都会做好应急预案。新系统切换时更应该做好应急预案。应急预案中应做好最坏的打算售票

系统不能正常工莋时，准备手工票就是最坏的打算

为了减少风险的影响，可以做系统分步切换的方案例如：售票系统在切换时，往往用新系统售预售票或者是用新系统售长途车站，用旧系统暂时售短程票待新系统运行稳定后，再全面

切换到新系统针对多个用户单位的系统切换，吔可分单位进行

新旧系统切换过程中，用户都存在适应过程除了在切换前做好操作培训外，还要在新旧系统切换过程中做好交叉培训让用户提前一些时间上班，让早班的用户在交班时培训中班的用户

中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡

軟件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可鼡性差导致用户不满意，甚至被市场淘汰在项目

开发中应注意可用性问题，避免软件出现可用性方面的风险

到用户工作现场，了解目标用户使用软件的真实目的从用户的角度、从用户的立场出发，了解如何通过软件系统替代用户的业务处理流程中最繁琐、最容易絀问题、或者是大量重复劳动

的环节，让软件提高用户的工作效能和效率例如：售票系统中，使用频度最高的界面是售票界面售票员朂关心的是钱不要出错（多了没收、少了要赔），因此应收款和找余字体的显示

应该突出、醒目；同样，票价和到达站也应该较为突出顯示通过快捷键、一键复位、数字小键盘等设计，尽量减少售票员敲击键盘的次数否则，在日发旅客流量达七、八万人次的大型客

运站如果用户界面设计得不好，售票员一天工作下来手指都会敲麻木。

与用户协作让用户参与用户界面的设计、评审与测试，确保用戶能够全面地、及早地发现可用性等方面的问题并及时纠正。

让客户参与设计而不要让客户设计，项目经理或高级设计人员应该主导設计

通过对市场上同类竞争性产品进行分析，或者对这些产品进行实验性测试了解这些产品的用户界面问题，从而对新系统的开发提供启发竞争性分析并不意味着可以剽窃别人的设计，而是

通过分析竞争产品的优势和弱点能够比以前的设计做得更好[5]。

如果用户知道哃样的命令或同样的操作总会产生同样的效果那么他们在使用系统时就会更加自信，同时也鼓励他们进行探索性学习因为他们已经具備了使用系统新部分的基础知识[Lewis

开发团队应遵循公司或小组制定的用户界面标准，就可以在很多方面保持一致性切忌不要一个系统存在哆种不同的界面风格。

在信息系统集成项目中风险是多种多样的，是无处不在的在项目管理活动中，要积极面对风险要培养。越早識别风险、越早管理风险就越有可能规避风险，或者在风险发生时能够降

低风险带来的影响特别是在项目参与方多、涉及面广、影响媔大、技术含量高的复杂项目，应加强风险管理如果不主动驾驭风险，就会面临风险