浅谈影响软件项目的几个因素.docx

浅谈影响软件项目的几个因素.docx

《浅谈影响软件项目的几个因素.docx》由会员分享，可在线阅读，更多相关《浅谈影响软件项目的几个因素.docx（5页珍藏版）》请在冰点文库上搜索。

序言

　　从事软件开发工作已经5年有余，参与的大大小小项目算起来也10来个了，在这些项目中充当过不少角色，有当过实施员、程序员、系统架构师，也当过几个项目的项目经理。

回首这几年的项目历程真是感慨万千，这当中有成功的喜悦也有失败酸楚，尤感觉国内软件项目管理的不成熟和困难。

相比于别的行业，软件项目常被人嘲笑管理不完善、进度难以控制、质量低劣，我们真是这样吗？

有人说：

软件是一种看得见摸不着的东西，软件业较别的行业有着更多不确定性和不稳定性，所以软件项目成功的少，而失败的多也就不足为怪。

但如果笼统地总结成“由于软件项目不确定性高，软件工程的水平低下”，然后开出的药方就是“采用软件工程的模式进行开发”，可是具体来说，软件工程又有许多流派，许多模型，许多方法，而且这些方法有些还是相互矛盾，相互抵触的，又该何去何从呢？

于是开发人员就这样陷入了软件开发的泥潭之中，左冲右突，不能自拔，越是大型项目，时间越长，人员越多，情况就越是糟糕。

诚然，软件项目失败的因素有方方面面，但总结起来，我个人体会最深有以下几个因素：

1、目标不明确，用户需求不确定；2、变数太多，而缺乏有效的需求变更控制手段；3、沟通不够，得不到有效的支持；4、项目中重要干系人的关系处理不好。

影响软件项目的几个因素

一、用户需求的把握

　　用户需求的把握是整个项目的关键，首先明确用户的需求，才能确定项目目标，制定项目计划和要交付物。

事实上，如果我们不确定在进行的是什么，以及我们进行的项目边界在哪里，那项目不可能成功。

我们的项目人员要从一开始就明白需要交付什么以及不要交付什么。

要在项目中确定用户的需求和建立尽可能清晰的商业所有权。

即使在最好的情况下，用户以前收到的信息也是有限的。

通常情况下，我们很难确定能够提供反馈信息的合适用户。

其实在项目一开始就需要确定主要的用户需求，并且为主要用户提供时间，以便他们确定所在部门的需求，同时他们也有责任提供和验证信息并投入相应的资源。

　　用户需求把握中重要的是框定项目的范围，如果没有很好的框定项目范围，那么管理项目范围几乎是不可能的。

框定项目范围的目的是把项目的逻辑范围清楚地描述出来，并获得认可。

需求范围定义得越清楚，项目的目标就会越明确。

但要做到这一点很难，特别是客户对自己的需求都不是很明确而项目组团队以前又没有做过类似的项目，缺乏相关项目经验时候。

对这样的项目我们采用原型化法挖掘用户需求比较合适，先给客户提供简单的项目原型，让客户在看得见的情况下提需求，引导客户有针对性的提需求，以防客户天马行空般提需求，没个边际，又有利于发现客户的潜在需求。

　　软件项目是为可确定且可测量的商业要求而产生并发展的。

在软件项目初期确定的模糊目标将随着项目的进展而逐渐变得清晰，这是拥有过长的交付期限的项目所共有的特点。

因此在项目开始之前，需要确定最终用户，以便在软件项目的设计和开发过程中充分考虑到他们的需求，同时用户也有责任而且需要采取相应的行动来帮助项目获得成功，这一点非常重要。

用户需求构成了项目的分析和设计阶段中一个至关重要的环节。

需求确定后，就要为这些需求确定基线，并将它们引入到配置管理系统中，同时使用变更控制对其进行管理。

如果这些需求出现了变更或添加了新需求，则需要对项目进行影响分析，并对项目计划进行相应的修正。

而像我们一些采用增量式和迭代方法开发软件的组织而言，还需要冻结每个软件版本的需求，并建立相应的机制以便向开发基线添加新的具有更高优先级的需求（用户需求反馈中确定优先级）。

二、沟通、变更的管理

　　项目管理是一门复杂的科学，其成败取决于很多因素，项目管理中的沟通与变更管理是关系到项目成败的关键之一。

沟通的主旨在于互动双方建立彼此相互了解的关系，而对项目最大的威胁是失败的交流与沟通。

项目进行当中，客户提出需求变更是很正常的事情，不要指望项目能完完全全按原定的需求执行，关键是要有有效的需求变更控制手段及良好的沟通方法来预防需求失控。

　　据国际著名咨询公司——德勤公司的一项调查表明，影响ERP系统成败的风险主要有十项，其中最大的因素就是“对变革的抵抗”，其他一些与变更相关的风险还包括“不实际的期望”、“变更原因说不清”以及“缺乏变更管理策划”等三项。

由此可见，变更管理是项目管理中的重要内容，必须慎重对待。

　　需求的改变是项目最头疼的事，客户今天说要天上的大雁，明天脑子冒个泡又想吃深海的石斑，作为买方，他们没有完全付款，当然能够喜欢要什么就要什么，但是我们怎么控制让客户尽量少地变口味呢？

除了上面所说的项目范围的锁定外，还需要的就是做好沟通。

有时候客户只会从结果考虑，他们想要深海石斑，不会想到抓石斑鱼是很不容易的，先要建造一条远洋渔船，结一张结实牢靠的大网，雇请有经验丰富的船员……我们先要知道的是客户最关心的是什么。

如果客户希望要吃的是石斑鱼，不管花多少钱，只要能上菜就满意了，我们可以先答应他的要求，然后告诉他们石斑对于我们来说一点难度都没有，不过需要一个月的时间去抓，那就是要推迟一个月才能吃上石斑鱼，他们说不定就放弃了。

这个时候项目经理的沟通、谈判技巧是很重要的，既要不吭不悲，又要理据充分，不能胡编乱造哄骗客户，客户不是傻子，他们如果怀疑你的能力和诚信，以后就更难沟通了。

在难度不大改变不多的时候，我们更应该的是作出适当的退让答应客户的要求，然后让他们知道我们作出了多大的牺牲去帮助他们实现愿望。

　　变更管理工作的核心是沟通。

沟通是取得那些提出变更人支持的基础。

为了达到获得支持的目的，沟通必须：

培养客户对软件应用项目的价值与战略重要性的认同感；保持信息的一致性与重复性，因为在项目执行中最容易受到影响的就是信息的清晰性；通过意识的一致性培养信任；形成双向交流，就信息源所提出的问题及其回答给予回应；了解不同的对象会有不同的需求、兴趣及理解问题的倾向性；增强项目进度的透明度，并确保包括各相关业务部门在内的各方了解项目的进展。

有了有效的变更控制管理手段及正确的沟通方法，项目才能顺利开展，保证项目成功。

三、项目重要干系人关系处理

　　项目干系人是指参与项目和受项目活动影响的人，包括项目发起人、项目组、协助人员、顾客、使用者、供应商，甚至是项目的反对人。

项目干系人的需要和期望在项目开始直至结束都是非常重要的。

如果要保证项目成功，必须要处理好项目中各重要干系人的关系。

据统计，国内软件项目的成功率不足25%，虽说项目失败的原因有很多，除了对客户需求不明确、项目计划不清楚、需求变更难以控制等等之外，还有重要的一点就是“关系”没有处理好，在国内这个特别的软件行业环境，处理好项目中各方关系尤为重要。

我个人觉得项目中的开发商和客户、销售人员和技术人员、项目经理与开发人员的关系对项目影响最大。

1.开发商和客户的关系

　　开发商和客户之间是软件产品的提供者和使用者之间的关系，一个卖东西，一个买东西，两者之间的关系是平等的，公平交易，这本是两者之间的正常合理的关系。

可是国内现在软件行业开发商和用户之间的关系是严重不平等的，开发商为了得到订单，往往委屈求全，放弃自己应该坚持的原则，在竞标时相互压价，甚至采用某些不够光明正大的手段来得到订单，自己把自己放到了一个被动的地位。

许多开发商都有这样的口号“以客户为中心”，他们不仅是这样说的，而且也是这样做的，这种不平等的关系，能够长期坚持下去吗？

　　考察这种不正常的情况出现的原因，既有开发商的原因，又有客户的原因。

开发商的原因，一方面是经济大环境的影响，大家都这样干，随大流而已，另一方面就是企图用这种方式来讨好客户，给客户留一个好影响，这样才好拿到订单。

而客户的原因，则往往出于对于软件知识的缺乏了解和恐惧，唯恐自己吃亏上当担责任，所以对开发商不够信任，有敌对情绪，心里上有挑毛病，找问题的倾向。

结果就是这样双方在开始接触的时候就小心翼翼，唯恐出现问题，一旦发生冲突，开发商就盲目退却，而客户就得寸进尺，最后项目弄得一团糟。

开发商怕得罪客户，却没有认识到有时和客户冲突是不可避免的，客户怕开发商来欺骗自己，于是一次一次进行试探，开发商越让步，客户越认为自己受到了欺骗。

开发商的让步往往换不来客户的信任，而是换来了客户的更加不信任。

由于开发商自己不相信自己，自己欺骗自己，最后也无法得到客户的信任。

　　毕竟软件开发是由开发商来完成的，那么就应该也必须由开发商来决定项目的进展和内容，可是现在却往往由于客户的压力而妥协，放弃自己的原则，这样来做软件开发，恐怕失败居多。

所以在软件项目开发当中，应当以开发商为中心，而不是以客户为中心，客户的意见只是参考和借鉴，不应该害怕和客户发生冲突，而应该分析冲突产生的原因，把冲突看成问题的征兆，而不是单纯来消除冲突本身。

　　开发商和客户之间的关系，是一种良好的合作关系，而不应该是尔虞我诈的生意场上的竞争关系，双方的目标是一致的，而不是对立的。

双方之间的矛盾是共同利益基础上的矛盾，而不是不可调和的敌我矛盾。

否定了这一点，软件是不可能成功的。

2.销售人员和技术人员之间的关系

　　俗话说：

屁股决定大脑。

一个人担任的角色不同，他考虑问题自然会更多考虑到自己的切身利益，至于这样做可能会给别人带来的麻烦，就管不了那么多了。

在有的开发商内部，销售人员和技术人员之间的关系是脱节的。

在许多公司，为了提高销售人员的工作积极性，对销售人员采用提成的方式进行奖励，而将底薪定得很低，这样一来，销售人员为了拿到项目的订单，往往会屈从于客户的压力，许下许多难以兑现的诺言，或者由于对于技术的不了解而随意答应客户的要求。

等到合同签订完毕，进入项目开发阶段时，客户会拿这些诺言来要求开发人员进行兑现，结果是开发人员非常被动，对销售人员抱怨很大，于是告诉客户这些要求无法满足，而客户也勃然大怒，你们这些人怎么一拿到钱就变了脸了呢？

问题就是由于销售人员不考虑技术人员将来的实现，从而许下了过高的诺言，这样做的结果也许可以拿到订单，可是由于销售人员和技术人员的口径不一样，最后客户无所适从，感到自己受到了欺骗，接着将一腔怒火发到了技术人员头上，两者之间的合作和信任关系逐渐变成了对抗和欺骗的关系。

　　其实销售人员和技术人员应该是一个自行车的两个轮子，应该把他们的利益绑定在一起，销售人员做售前、签定合同时技术人员必须参与配合，销售人员的提成应该按项目的回款分期付，项目出现商务或进度问题时销售人员有义务跟进，他们的关系必须是相互合作，相互支持的，而不应该是互相拆台，相互对抗的，一旦他们之间相互对抗，那么就会给整个项目带来灾难性的后果。

3.项目经理与开发人员的关系

　　完成一个项目就象部队行军打仗一下，项目经理象部队的将军，开发人员象士兵，这之间本来应该是相互团结，相互帮助，共同面对问题的团队关系。

可是有些项目经理把这种关系扭曲成了管理与被管理的强制性关系，用种种规章制度，种种理论上的管理方法来强迫开发人员接受。

项目进度安排得死死的，没有弹性空间，指望每个人开发人员能100%投入工作。

在这种糟糕的管理下，开发人员没有任何办法，要么被动接受糟糕的管理，要么辞职以抗议。

一旦项目发生了这种情况，它想成功就非常难了。

　　其实软件项目中的团队管理重要的是人性化管理，软件是以人为本的，况且大凡开发人员都比较有个性，都比较自我，喜欢按自己的工作方式来做事，所以做为一个项目的项目经理应该了解项目组中的每个成员，多用个人的影响力或针对成员的个性来协调、管理项目成员的工作，而不是靠过于理论化的条条框框来强制要求开发人员。

对于喜欢晚上干活，晚上才来状态的开发人员，可以针对他们的工作习惯用目标管理进行授权并实行弹性工作时间制，不要强逼；对于不太喜欢跟客户打交道，喜欢专心搞技术钻研的开发人员可以多安排项目中技术攻关的活由他们做，满足他们的自我实现感；对于喜欢跟客户交流，喜欢做规划的开发人员，可以多安排系统分析、需求分析的工作给他们等等。

正所谓的尊重个人兴趣、习惯，用人用长处，当然这些都要在项目在可控的范围内进行。

　　项目经理和开发人员并没有本质的区别，都是一个项目团队的成员，他们只是所处的岗位不同，担任的责任不同而已，大家的目标应该都一致，即把项目做好。

在软件开发的问题上，尤其在大型项目的具体的技术细节上，往往项目经理不甚精通，如果他不能吸纳开发人员的智慧而是自己一个人拍脑袋来做决策，那么到最后估计他要拍屁股走人了。

总结

　　总的来说，软件项目的不确定性高，变数太多，各种资源难以量化管理等特性注定软件项目管理是一门相当复杂的学科。

影响软件项目成败的因素很多，上面所陈述的只是九牛一毛而已。

但是如果在项目一开始能很好的把握好用户需求，限定项目范围边界，在项目执行过程中采用有效的需求变更控制手段及合适的沟通方法，同时处理好项目各重要干系人的关系，软件项目开展肯定顺利很多，项目最后失败的风险也会降低许多。

纵观国内软件行业，有时候真感到我们象趴在玻璃窗上的苍蝇一样，感觉前途一片光明却又苦于找不到出路。

但不管怎么样，既然投身于这个行业了，就应该执着地走下去，直至找到真正的光明。

最后引起屈原的一句诗词与同行人共勉：

路漫漫其修远兮，吾将上下而求索。

参考文献

1、《计算机信息系统集成项目管理基础》  中国软件评测中心　编著

2、《计算机信息系统集成项目管理实践》  中国软件评测中心

3、《软件项目管理过程控制与人员管理》  电子工业出版社

4、《成功的项目管理》    机械工业出版社

5、《成功经理人讲座》    余世维