软件外包项目中，甲乙双方各有哪些项目管理难度

(一)关于软件外包项目管理的想法

外包项目一般比较难以管理，由于不是自己来进行具体实施，项目在进行中出现的各种问题对甲方不透明，造成项目的成败往往掌握在承接方手里。这样就常会有进度超期、质量不符合要求、甚至工作结果根本不符合甲方需求等情况的发生。如何去应对？

首先要意识到无论什么样的项目，在实施过程中都会出现各种各样的问题，如果不去主动跟踪，很多问题可能会一直潜伏到验收的时候才浮出水面。从甲方的角度来看，发现问题一定要早，不要等到交付期时才发现，到时恐怕已经无法挽回。越早发现问题，改正的成本越小；越到项目的后期，改正的成本越大，给项目成功带来的风险也越大。所以，甲方一定要建立对外包项目的跟踪控制机制，贯穿实施的全部过程。

其次，软件项目不仅应满足功能性需求，还应该满足可维护性、可靠性和复用性等软件工程上的质量要求。对于承接方的实施人员来说，项目的实施具有一次性，自己不是项目成果的使用者，甚至也不是后期维护的维护者，所以没有进行长远打算的驱动力。而这些质量特性都需要在实施过程中的计划、设计和编码环节进行综合考虑，但承接方为了赶进度、省成本，可能对此并不太重视，认为能够对付合同上规定那些条款也就足够了。这样就造成了软件在交付后，出现问题难以维护。等过了一年维护期后，用户自己对软件维护就更难以进行。对此，甲方要参与到承接方的质量管理中去，要求承接方建立质量保证计划并严格实施。

再次，很多时候甲方并不从事于软件行业，而只是软件项目成果的用户，对软件开发的知识并不了解。所以对于承接方采取的开发流程、技术方法和质量难以衡量。甚至由于甲方接口人员并不懂软件开发领域知识，在同乙方讨论时，被对方抛出的一大堆术语、技术细节所淹没，但为了维护自己的自尊心，出现不懂装懂，胡乱应付的做法，或者干脆就任由乙方去进行各种决策，自己完全撒手不管，让乙方完全掌握主动权。最后在验收后才发现项目结果不能完全符合自己的需要，或者存在这样那样的问题。为防止这种情况的发生，甲方首先要客观面对自身的弱点，选择对软件开发行业熟悉、且有一定经验的人作为接口人（甚至可以外聘项目监理），并建立一套正规的外包项目管理制度和方法，从制度和人两方面来保证项目的正确实施。

与院校等科研学术性单位进行外包合作，尤其要注意，由于这些单位的工作多属研究性质，他们对软件功能上比较重视，也就是要求能走通就行，而对工程上的特性并不愿多投入。所以他们所完成的软件，如果不加控制的话，后期会很难维护和复用。另一点，由于院校的很多项目是导师指导学生来完成，而学生具有流动性，且水平基本上都处于新手水平，开发经验不多，所以开发质量、后期bug的跟踪和修复方面是个风险。而且，院校、科研院所等单位往往工作节奏不快，在进度上也不能太乐观。 具体来说，甲方要从以下几方面来保证外部项目的成功实施：

1、范围管理
甲方的需求提出的越详细清晰、越没有二义性，越有利于乙方展开工作，降低项目风险。如果甲方不能够在项目开始阶段就提出足够细致的需求（很常见），那么可以在实施推进过程中逐步细化，也可要求乙方建立原型来辅助需求的深度挖掘。
撰写详细的软件规格说明文档，作为乙方的范围基准。
要求乙方根据工作范围建立WBS和相应的工作量估计，从而有利于甲方的对项目的跟踪。

2、进度安排
根据WBS和工作量估计，制定进度计划，并以图表的方式表现出来，作为甲方跟踪的依据。
对远期的工作要求有大致的进度计划，对近期的工作要有详尽的进度计划。
为了降低项目的风险，可以要求乙方对软件进行分阶段交付，设置多个里程碑，每个里程碑交付软件的一部分。每次交付验收后，乙方可继续开发其他部分，而甲方可将交付的部分投入更详尽的测试，或者进行现场实测。这样做的好处就是，将项目交付的风险分摊在整个实施过程中，而不是最后交付的那一刻。
分阶段交付的另一个好处是，通过前期的交付，甲方可以对乙方的各方面情况有更充分的了解，例如开发人员稳定性、技术及管理水平、乙方对项目的态度等等。如若发现乙方的资质完全不能满足项目开发的要求，应该立即取消项目，从而避免更大的投入损失。

3、质量管理
软件的质量取决于参与实施的每一个成员，以及涉及到开发的全过程。尤其重要的是，在项目的前期计划中一定要充分认识到质量的重要性，并制定相关计划，采取措施以保证质量指标的实现。
对于甲方来说，由于不直接参与设计与编码，所以对软件的内部质量除要求乙方实行质量保证措施外，较缺乏直接控制的手段。所以甲方要多在系统测试方面下功夫，对于提出的各项需求，做好相应的测试用例，任命专门的验收测试人员。在软件的非功能性指标方面，也要想办法对乙方施加影响。

4、沟通管理
为了能够及时掌握外包项目的状态信息，需要与乙方进行定期和非定期的、各种形式的沟通，出现问题及时能够发现，降低项目失败的风险。对于乙方来说，出于某些原因，并不愿意与甲方完全共享项目实施的情况，除去那些做非正常手脚等情况不谈，乙方害怕甲方过多了解项目实施情况后会有进行微观干预的冲动，指手画脚结果把工作弄得一团糟。所以甲方要认识到沟通的目的不是为了随时插上一脚，而是为了确保自己对项目的进行充分知情，不要有大问题发生后自己却蒙在鼓里。与乙方的交流要建立在互相尊重、信任和实事求是的基础上，对事不对人，尽量不要让乙方产生防备心理。毕竟每天在第一线工作的是乙方的人员，如果他们由于害怕受到批评而想隐瞒的话，甲方是很难控制的。

5、乙方人员安排
虽然说负责实施的是乙方，具体的人员安排由乙方来定，但项目都是由人来实施的，人员的安排对于项目成败至关重要，作为项目成果的使用者，要对此心里有底。我们要看乙方人员安排的是否合理，具体要看乙方人员是否具有足够的软件开发方面的专业能力，对项目业务领域的知识是否掌握，乙方项目组长是否有足够的软件开发和项目管理的经验和能力，人员是否足够，乙方对项目投入的是否足够多等等。国内的现实是，业余的项目组长和程序员占软件开发人员的大部，开发方法基本上是code-and-fix，让他们来主导实施的话，容易让项目走向混乱。作为甲方不可能改变业界的现状，只能尽力做到心中有数，尽可能施加影响，让合适的人来做合适的事。
6、风险管理
7、变更控制
8、验收管理
9、项目跟踪与控制
10、项目管理文档
11、乙方项目管理水平保证 

（二）一次痛苦的软件外包项目经历

某大单位让我开发个软件，实现用手机短信和广播信道实现高速上网。这个项目比较新，他们的软件工程师都不知道从何着手，我提出了系统架构，设计了服务器端和客户端软件。并且合同一开始就明确表示，产品化的工作要他们自己来完成，我只负责技术攻关。
开发工作一波三折，开始的链路层方案，把IP/ICMP/IGMP都做通了，可是发现短信的信道无法支持，又改用应用层方案。应用层方案需要也做通了，却被要求和他们的其他应用绑在一起，最后要求不要使用手机通讯，由他们的软件来做，否则就会有冲突。当初调试浪费时间最多的就是和他们的手机做接口。
需求变来变去，每次都挺急，我一般第二天就可以做个东东出来，长的一周也能出来。可是他们还是觉得我在拖进度。本来他们对于网络一窍不通，我在调试的时候，多次给他们的开发人员讲课，并且告诉他们正确的思路和调试方法。后来，有一次正在调试，他们叫我去开会。会议结束后，我发现有一个程序员正在我的笔记本电脑前翻阅我的源代码。其间有一个多小时的时间，足够他把我的代码拷走了。他们还说我们是大单位，不会赖你的帐的。
现在，他们以时间紧为借口，开发了一个自己的客户端程序，调通了上网流程，再也不调我的程序了。而且声称不准备继续合同了。从10月1日到春节前，3个多月的时间，我先后实现了无线路由器和无线代理服务器的功能。因为是兼职，所以经常加班到深夜，专门在公司附近租了房子，还常常半夜去上电视塔调试。获得的仅仅是1万元的预付款。
看来软件外包真是危险，技术上的成功却不一定能带来商业上的成功，想听听大家的看法。 

分析：这个不能算是严格的案例，只能是问题分析了。在明显你是弱势群体的时候，没有意识到这一点，当然更不会才去必要的措施保护自己了。不过我觉得可能你还是没有让你的客户见到你的真正的工作，如果你能让你的客户明白你做的工作，那么情况应该是另外一个景况。

分析：这个是一个多方面的问题：
1、合同上的问题：要明确交付物、各种款项交付
2、需求分析、范围管理与开发方法选择：这个项目有了比较明确目标，但是集体的范围没有确认需求分析没有去做导致的后面的需求便来变去。
3、知识产权的问题：开发人员对自己的源代码没有保护，导致源代码泄漏，泄漏后没有合法取证，导致以后的结果
4、个人软件开发的思考：个人开发主要考虑的是技术方面，对项目管理一无所知，没有风险计划、成本进度管理等等，这是以后个人开发中要十分注意的

分析：一个企业是否需要外包,是通过自制/外包两方面分析而决定的,很显然,那个公司是没有能力完全那个新技术的项目而采取外包方式的,但软件外包,一般只外包开发的组件,或者模块(让你帮助开发),或者选择一个咨询公司要求提供解决方案,一般不会选择外包技术攻关,而且一般人/团体/公司也不会去接这种外包单,因此我认为这个外包的案例在接单的人身上发生了很大的问题,第一,你应该理清楚,公司外包给你的是什么?第二,知道你接下这些外包的是以什么方式提交给公司?如你技术攻关, 只要你答应也可以,那应该在合同上说明,只要他们使用了你接下的技术点来开发了,就应该付款;第三,签订明确的合同,将工作,提交成果,什么形式,什么方式使用,应该承担的风险全部写明确,并签订,技术保密协议.综上所述,要解决这方面的问题是,第一,明确这种外包该不该接;第二,签订非常明确的合同;第三,对风险,时间要充分估计;第四,防止技术泄密,采用法律文件的形式保护自己的知识产权.

分析：这种事情在IT行业经常发生。
普遍客户工程师在技术及知识上比较欠缺些。不知道方向，如何下手是很正常的事情。承包方应引导客户提出业务模型，最好是类似选择题的方式。旁边注释优劣。当选择好后，要进行一次评审，需要对方的项目责任人参加并签字。
不能一开始就做（大忌），除非对方给的是明确的需求说明。
如果实在对方提不出需求，也只能开发一个业务模型，等确定好以后才开发实质的东西。
说白了，这个项目的失败，不能全怪客户。
首先，目标就没有明确，需求以及设计方案都没有得到正式认可就开发，往往导致离客户的意愿越来越远。

分析：应该设立需求变更的范围，超出这个范围就应该要求对方重新签订补充合同，并支付相应费用。不要随便答应客户的要求，一切以合同签订时的需求为准。也要让客户站在你的角度想想，多体谅你。

分析：这个不能算是严格的案例，只能是问题分析了。在明显你是弱势群体的时候，没有意识到这一点，当然更不会才去必要的措施保护自己了。不过我觉得可能你还是没有让你的客户见到你的真正的工作，如果你能让你的客户明白你做的工作，那么情况应该是另外一个景况。

分析：项目合作中作为提供技术方案解决的一方一定要注意保护自己的知识产权，自己的技术方案是合作者赖以于自己合作的关键，一旦失去了技术方案的独有性那么合作也就没有意义。这里只能告这个单位违约，其它的也就顶多给予一些道义上的谴责罢了。

分析：如果你们双方有委托开发合同,这家单位的行为属于单方解除合同,应支付违约金.
如果合同中就软件的知识产权归属没有规定属于单位所有,则你拥有产权,可以向该单位提起侵权诉讼,要求其停止侵权,赔偿损失.

分析：我对合同的理解是，违约责任是合同的一个必须要素。他们的行为应该可以构成单方面解约了吧，难道在合同中没有对此有所约定？不知道你的合同是怎么样的，我想如果是一份规范的合同，应该可以按照合同约定索赔，是否有盗取你的劳动成果这点斩切不谈（这个取证太困难了）最明显的是他们单方面解约，应该可以要回一些损失吧。

分析：我认为主要原因还是出在合同的签订上。我们现在签订这种软件合同：
1、要确定需求。只有需要明确，才知道要做什么，才会有验收的标准，否则项目肯定拖也会被拖死。
2、合同的违约条件。不能任由解除合同，否则吃亏的只能是自己。

分析：读了一些国外项目管理的文章,感觉国外的项目管理和国内还是有很大不同之处的;他们只做合同内的,如果额外的工作,你可以说NO;我给你开发了一个模块,你就要按约定给我相应的费用;如果你不给我可以告你违约,你要赔我一大笔款子;不管你公司大小;嘿,如果国内要能做到那样的话,我们做项目经理的,不是很轻松了 .

（三）软件外包，需求分析由谁来做？

如果你是以客户（甲方）的身份在看这个回答，那答案是肯定的。连需求文档都不想写还想让别人做好你的项目？我只能负责任的猛喊一声：“醒醒，大哥，别做梦了！”
在生活和工作中，我们通常不是充当甲方角色就是充当乙方角色，往往两个角色交替着来。看起来，甲方给钱，应该是主导地位，那为啥软件外包领域的甲方经常在项目交付的过程中狼狈不堪？

软件开发项目要成功，更多的取决于甲方，取决于甲方的能力，态度，还有期望。项目换乙方不难，但是换甲方，基本就死了。so，做一个好的甲方很重要，我们来谈谈为什么，以及如何做一个好的甲方。

1.场景还原
甲方：“我要做个聊天室，大家可以在里面聊天”。
（你看需求很明确了，就是能聊天嘛，这有什么难以理解的，直接开始做就成了。）
乙方开发团队：这个聊天室是一个能容纳多少人的聊天室？聊天室里聊天是语音聊天、文本聊天还是视频聊天？除了聊天功能还有没有别的功能等等。
乙方商务：需求文档是评估工作量最直接的数据来源，没有需求文档，项目做到最后该花多少钱都说不清楚。
这个世界之所以有那么多矛盾，就是因为我们的思想是不透明的，没有人知道你在想什么！
你找人帮你做软件开发，你一定非常明确的知道你想做的是什么，软件的使用场景是什么，解决什么问题。你在你的领域混了很多年，你觉得有些问题很显然，但是乙方没有。你觉得理所当然的问题，乙方可能完全没有听说过。所以，作为甲方，你应该不厌其烦，尽可能详细的说明白你的需求。

2.类比案例
甲方：“我想要一辆车”
乙方：加班加点好不容易赶制出来了。
甲方：“这不是我想要的，我想要的是四驱的，座椅加热的，还得是敞篷的。”
乙方：加钱、延期。
甲方：不爽。
结果：埋下了不欢而散的种子。
很多软件项目做出来效果不理想，追根究底都是甲方一开始没说清楚。你不能觉得你的需求很常见，很简单，所以乙方应该理所当然的做出你想要的东西。如果你要的软件真的这么常见，那你就不用定制开发了，直接买现成的。每个需求都是独特的，所以请不要用这样的语言来描述需求“做一个跟 xxx 软件差不多的就行了”。

3.一个成熟的甲方
一个成功的软件项目，往往甲乙双方都不是爷，各有各的责任，各有各的义务。一些海外项目，包括香港和台湾的，都是非常详细的需求文档，并且对接的人非常耐心的跟乙方解释业务逻辑。更重要的是，甲方非常清楚，他的责任在哪里。在出现问题的时候，他会判断这个问题是谁的原因，不会把所有责任往乙方身上推。这是我们值得学习的地方，也是需要改进的地方。

4.如何梳理需求
对于需求不明确的客户，如果他有能力自己梳理清楚需求，当然皆大欢喜，制作出需求文档再找平台开发也可以。
更多的情况是，客户自己不会，也没有产品经理，需求不明确又不能进入开发怎么办？针对这种情况步联科技推出了一款服务，『910梳理需求』是步联科技为企业提供的高端产品设计增值服务。产品方向确定后，选择谁来做，具体怎么做往往是胜利的关键。我们会让一线公司的高级产品经理为您梳理项目，让您找准关键，事半功倍。

（四）现下软件外包行业,开发者（乙方）的最大难点是？

作为外包的开发者（乙方）理解不到雇主（甲方）想要什么？
PS：有时需求了解的很详细了，但是开发出来的还是让雇主（甲方）不满意，项目重复修改，导致项目延期甚至最终流产、收款难度大等问题！
“我有一个想法，你有现成案例和演示地址吗？”
好不容易有个客户资源,首次面对雇主（甲方）就遇到这个问题，如果这个问题都不能够处理，那何来后期合作呢？往往就在第一步就被雇主（甲方）拒之门外。
无忧案例网（51case）可以帮到您，开发者（乙方）可以把案例上传到平台，雇主（甲方）直接根据这个案例来联系开发者（乙方），首次协商就有共同语言，有利于下步合作哦！
“我突然想到一个地方，之前没想到，你帮我加上吧。”
在开发过程中，由于之前只是一个想法，需求功能没有具体设计规划，导致有些地方没有完善，雇主（甲方）会一直纠结，并让开发者（乙方）加上。
无忧案例网（51case）是一个现成的案例共享平台，开发者（乙方）提供专业的项目案例展示，雇主（甲方）则通过与其需求相近的案例找到合适的开发者；开发项目可以根据现成案例来完善，这样可以最大程度还原雇主（甲方）的想法。
“有一个地方和我想的不一样，要修改，你帮我修改了吧。”
在测试过程中，因为没有参照案例，项目都是重头开发的，雇主（甲方）觉得开发出来的和之前说的不一样，一定要修改，不改就不打款。