软件项目外包坑很多，做好项目管理才是关键

（一）外包软件项目管理要抓住关键点

外包是发包方和接包方互相信任、高度协作的共同行为。为了顺利实施外包，对于发包方，要求企业具有一定的技术水平、项目管理水平、人力资源和沟通控制能力。对于接包方，要求企业具有一定的成本、质量控制能力，具有国际市场开拓能力（包括业务能力、交流能力、接包渠道和商业信誉等）。为了是外包服务形成产业化，还要求形成良好的政策环境和市场环境等。

下面以软件项目外包为例，从发包方和接包方的角度，讨论实施外包的关键因素。

1、项目需求
项目需求是项目规划和正确实施的根本，在外包项目实施过程中，如果客户经常改变需求或提出新需求，常常使项目延期或超出预算，对于合作双方都会受到商誉和经济上的损失。

通常发包方根据外包的项目特点，进行项目外包分析，提出项目需求报告。接包方在实施项目之前应该深入了解和挖掘客户需求，对某些不明确的需求与发包方讨论，对于项目实施过程中的需求变更，规定处理办法，并达成一致，形成项目的最终需求。

在需求分析阶段，接包方首先对发包方的需求认真分析，然后通过业务建模、会谈、问卷、需求会议等方式收集客户完整需求，形成文档，然后经过客户讨论、客户审查、文档修订等多次反复的过程。

2、项目计划
在项目实施之前，通常发包方提出项目实施计划的草稿。项目计划的内容应该完整、可行，对于项目流程、工作量、资源配置和项目里程碑等需要双方接受达成一致。

接包方要及时全面分析计划的内容，要详细地跟本企业的计划进行比对和审核，从而了解外包商对整个项目的流程、内容、估计的工作量和资源的安排是否与项目本身的要求吻合。明显的差异都需要及时澄清并建立共识。

发包方根据接包方对项目计划草稿的建议认真分析和深入讨论，进行必要的修改和补充，形成双方都接受的最终项目实施计划。

3、质量控制
软件外包的质量指软件产品满足用户需求的程度，包括功能需求、性能需求、稳定性、安全性和技术先进性需求、支持和服务需求等。达到客户的质量要求是外包业务的基本要求。

以软件开发项目为例，接包方质量控制的常用方法如下：

通过多次反复、多方参与的评审控制需求和设计的质量。
在编码之前，制定代码规范，并强制执行，以便保证代码的规范性。
通过严格的、完整的测试流程保证编码质量。
需求分析、方案、系统设计、测试计划、实施计划等必须进行内部评审，通过内部评审后指定双方人员共同审查。
必须制定全面的测试计划和质量保证实施过程并通过审查。
系统交付使用前，要经历单元测试、集成测试、系统测试和用户测试、验收测试等质量检验过程。
制定实施和维护计划以及实施和维护操作规程，记录操作过程，及时请发包方确认。
4、进度控制
进度影响双方的成本，可能影响发包方的业务，进度还可能影响产品质量。

接包方应该按照项目计划的进度实施项目，及时定期汇报实际实施的进度。对项目实施过程中影响进度的因素综合分析，及时与发包方交流，提出解决办法。发包方要对接包方的进度进行监控。

软件外包项目实施进度控制的常用方法如下：

通过科学估算，考虑资源配置情况，共同制定合理的双方认可的进度计划。
细分任务，制定更加精细的里程碑，并按里程碑进行验收和考核。
建立常规的进度报告制度，以便及时掌握项目进度。
采用严格的流程来控制需求变更。
进度计划中，将一些比较大的工作拆细，以便设立更多的里程碑。
5、风险控制
风险管理（Risk Management）是指经济单位对可能遇到的风险进行预测、识别、评估、分析并在此基础上有效地处置风险，以最低成本实现最大安全保障的科学管理方法。

发包方要根据外包项目的特点和要求，制定切实可行的计划，选择合适的接包方，并且密切监控项目的实施过程。

接包方一定要对整个项目足够了解，其中包括项目需求、工作范围、实现方法和预期经济利益的来源。对于已经完成的部分，要有一套合理的评估方法。

发包方可以通过下列方式来控制风险：
通过考察企业实力、资格认证和服务经验严格选择接包方。
通过严密的法律条款、严格的合同审核来保障知识产权和商业机密。
通过严格的过程的过程控制来控制外包业务的质量和进度。
接包方可以通过下列方式来控制风险：
进行严格的需求管理和控制，充分挖掘客户需求。
严格规范合同起草、谈判、审查和签署，在合同条文中明确规定外包服务过程的责、权、利、知识产权和商业机密保护。
执行规范的项目管理和控制，严格控制质量和进度。
通过有效的人力资源管理来稳定队伍、建立后备队伍和提升团队的技术能力和综合素质。
建立和保持畅通的沟通渠道。

6、交流与沟通
实施外包项目是发包方和接包方互相配合、共同合作的过程。要保障外包业务的顺利进行，必须建立有效的沟通渠道。
建立有效的沟通渠道包括以下内容：
确定可以采用哪些交流工具，以及什么情况下应该采用什么沟通工具（现场交流、电话交流、传真、电子邮件、在线交谈等）。
确定交流的时机和频率，包括接包方提交进度报告和双方召开项目实施交流会。
确定交流的格式（例如，规定周报的格式）。
确定交流的形式（现场交流、电话会议，双方项目联系人）。 

（二）做好项目管理，才是软件开发管理的关键

软件开发过程中，往往有很多细节和意外让我们的计划赶不上变化。譬如需求变更、人员流动等。为了保证项目进度可控，有效规避项目在开发过程中的风险，项目管理的作用在软件开发中的重要性可想而知。
项目管理大致有项目计划和开发团队管理两方面。
建立项目计划
(1)设计总体架构
针对项目的实施需要，采取适合项目且相对成熟的框架结构。
前些年，我在某集团技术部门担任技术员时，那时公司的产品总出现各种各样的问题，例如日常发布系统时或访问量稍微过大时，系统就会出现故障，一天下来收到了100多份bug邮件，影响了业务系部门的正常使用。
之所以出现这么多的bug，是因为无论业务系提什么需求，技术部都全盘接受了，按理这样也不会导致出现这么多bug，技术部服务于业务部，是正常的，毕竟公司的主要收入在业务部。可问题是，数据字典是每个开发人员自己设计的，导致大多数数据字典冗余、甚至设计不合理。各自只关心自己负责的模块。等到模块之间有关联时，问题就接踵而至了。
那时候公司用asp.net +mssql server技术，并没有采用相应的框架，代码冗余多，后来团队经过两个多月的整改，系统才勉强能正常使用。
(2)控制可扩展度
扩展度过大，将提高系统的复杂程度，延长开发时间；扩展度过低，会直接影响系统的二次开发与维护。控制系统的可扩展性，能提高开发效率，降低系统维护的难度。
不知你有没有觉得，项目前期没有做好，后面复制粘贴的现象就会到处可见，导致冗余的代码越来越多，维护越来越困难。
(3)建立基础设施
合理分配软、硬件等基础设施的部署所需要的时间与成本。
(4)划分开发任务
利用WBS（Work Breakdown Structure，工作分解结构）对可交付结果进行分类与划分。每个项目划分为多个不同阶段，每个阶段又可以分为多个工作包（Work Package），工作包是WBS里最小的可交付结果，最后从工作包中分解出多个开发任务列表，分配给各个开发人员。
(5)部署开发进度
从需求调研、进行概要设计、进行详细设计、执行开发任务、测试、联合调试、SIT部署、生产环境部署都常常延误，项目经理必须有谈判能力、预判风险能力、控制能力。项目经理就是在满足各方项目干系人的利益的情况下，推动项目向前发展，最后达到项目验收。
(6)测试项目成果
每个工作包都应该同步部署测试工作，提高项目的质量。对出错BUG的工作包应该由测试人员以文本方式记录，向开发人员展示错误所在，让开发人员及时进行修改。
管理开发团队
(1)组建团队
按照工作任务与项目时间的前提条件建立团队，按团队职责分配人员，一般小组控制在6~10人之间。当团队人数超过20人时，应该考虑把团队分解成2个独立团队，负责不同的开发任务。
(2)分配开发任务
在每个迭代周期内（一般是15~30个工作日），应该把每个工作包进一步细分为多个开发任务，开发任务的开发时间应该控制在15个工作小时以内，如果开发任务的开发时间超出15个工作小时，应该考虑把任务再度细化。而开发任务应该以自由选择的方式分配给每个组员。
(3)跟进开发进度
在迭代的前期举行一次会议，让组员了解开发的进展及流程，并以自主选择的方式分配开发任务。用工具记录开发流程的进展，在每个工作包完成开发后应该进行性功能的测试，并以文本方式记录测试结果。
每天举行一次10多分钟的站立会议，让组员汇报昨天已完成的开发任务，当天将要做的任务，以及开发过程中所遇到的问题。
并在每周末举行一次例行会议，交待总体进程。
在迭代末期举行一次冲刺会议，总结项目的进展，交行已完成的任务，回顾该迭代周期内所遇到的问题，为下一个迭代做好准备。
期间千万不要忽视开发规范和代码审查。
关于代码规范，感兴趣，请浏览《你见过马化腾18年前编写的代码吗？》
代码审查，顾名思义，是一个检查代码并确保其能正常工作的过程，并且尽可能的优化代码。
有人会对代码审查的流程反感，我写的代码还要别人审查，难道怀疑我们的编码能力。
其实不然，有人检查我们的代码其实是件好事，能减少因为粗心的犯错带来的风险。 即使再好的开发人员也会有大意的时候。
在团队中的每个人都有自己的强项，通过代码审查。有些人可能会提出一个更聪明的解决方案，用一个更适合的设计模式来降低复杂度并提高性能。
通过别人的审查，他们可以察觉到可能的问题和发现能改善的地方，对代码提交者的编码水平提高有很大的帮助。
审查者则可以通过读别人的代码学习到很多新知识和技巧，并找出适合他们自己工作的解决方案。
(4)系统测试
对每个已完成的工作包进行适时的测试，保证系统质量与性能。对测试结果进行文本的记录，并把测试结果与绩效工资收入挂钩，并以真实数据计算组员的绩效收入。
测试人员应该以文本方式记录bug，并与开发人员共同工作的，把突出的缺陷演示给开发人员，以提高修改的效率。
这里的绩效考核就要慎重了，搞不好会导致团队人员的流失
(5)解决开发中的问题
对开发人员进行前期培训，可适当按工作能力分配任务，指导组员的开发。当遇到问题时应该在当天的站立会议时即时提出，避免影响开发进度。
(6)流程化管理
流程化管理(process　management)，是一种以规范化的点对点的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法。它是一个操作性的定位描述，指的是流程分析、流程定义与重定义、资源分配、时间安排、流程质量与效率测评、流程优化等。因为流程化管理是根据团队的具体情况而设计的，因而这种流程会随着内外环境的变化而需要被优化。
针对一个IT软件管理来说，应该抓好以下四大流程管理：
编码规范的制定与执行;
开发任务流程化的制定与执行;
开发进度流程化的制定与执行;
测试成果的制定与执行。
流程化的管理减少了团队成员盲目与重复的去工作，提高了团队的工作效率。同时也提高了团队管理者的效率，为管理提高了一个便捷的管理工具，所以一个高效团队的打造，离不开流程化的管理。

(7)需求变更，修改项目计划
在开发过程中，遇到需求变更，要做好详细的文本记录，让客户了解需求变更的实际情况和开发方为之所付出的成本代价。与客户探讨，让客户了解计划修改对项目进度所造成的影响。同时为开发人员争取工作量。
笔者曾遇见过，项目开发过程中，需求变更了，可给予相应的开发人的工作量却没有任何变动，这对开发人员很不公平，开发人员只好通过加班加点来完成任务。这样很容易导致人才流失，做完了这个项目，组员都陆陆续续辞职了。
软件开发管理，必须得提高软件团队管理能力，管理者就要利用一切机会让团队成员感受到团队的力量，让他们不孤单，不委屈，并通过每一次的开发任务让他们不断成长。
做好项目管理，在软件开发中不容忽视，只有做好了，才不会影响项目进度，才能推动项目向前发展，最后达到项目通过验收，顺利完成项目的开发任务。

（三）软件项目外包常见的3个坑

软件项目外包过程中经常会遇到几个坑。其根本原因在于甲乙双方对软件开发的理解不一致。尤其是甲方对软件开发的特点和流程不了解的时候。我在这里提出来，提醒管理同行注意。建议在项目启动过程中乙方给甲方宣讲，避免之。

第一坑： 合同签订后，客户不断加功能，乙方不断退让，导致项目的功能越来越多，十分繁复。专业的名称叫做项目范围蔓延。
甲方的心理可能是贪便宜，就好比买一辆车，如果有一些免费的配件附送，要一些又何乐而不为呢。另外软件外包合同中描述的详尽程度有限，导致甲方在细节执行上可以要求乙方添加功能，而且可以拿付款等条件要挟乙方。
      然而实际情况是，软件项目的预算是有限的，软件开发的人员成本也很高，项目签订的时候往往就只有少于10%的利润。因此项目范围蔓延对乙方是一个灾难：因为事情多了，预算还未增加。这时乙方通常通过在其他模块偷工减料，减少后期维护成本等方法来避免亏损。最后受害的还是甲方。有时甲方发现，项目完成了，过一段时间乙方的公司却倒闭了，软件找不到人维护，就是这种情况。
      这种情况甲方应该明白，软件开发项目是一项高风险的活动，行业失败率是80%。因此必须慎重。最好的项目是甲方需要的核心功能全部按质按量完成，乙方也可以赚到自己的利润，双方皆大欢喜，下次还有合作的机会。添加功能由于汽车加配置，甲方也应该添加相应的预算和时间，合情合理。

第二坑： 甲方不断修改需求，修改界面，乙方不断退让，最后导致整个项目烂尾楼。
甲方应该意识到，修改需求，修改界面，犹如房子建设过程中修改图纸，难度是比较大的，伤筋动骨。往往会导致软件中后期出现难以修复的bug。而且由于软件开发都是人力来做，现在人力成本上升，软件修改成本也很高，往往导致项目严重超值，继而导致甲乙方为增加预算扯皮，从而导致烂尾楼。
正确的方法是在项目的早期，甲乙方对软件设计充分沟通，拿出一份最佳方案，签字确认之后再开始软件开发。而软件开发中原则上不修改设计方案。
界面上细微调整由于不影响程序结构，通常不会有大的影响。注意方案定稿之后，不要反复修改就行。少量改动是允许的。
如果确实需要修改需求怎么办？这种情况需要走变更流程，甲乙方对修改的原因，修改的后果充分讨论，增加相应预算和时间，进行修改。往往甲乙方讨论之后，会觉得预算和时间上难于承受，因此放弃修改。

第三坑：项目镀金
乙方为了迎合甲方，主动添加一些项目计划外的功能。或者对软件做一些无关痛痒的美化。
项目镀金也会导致成本上升，时间拖延，压缩了项目利润。乙方需要这些项目利润来提高员工待遇，更新设备，安排员工培训，提高竞争力。另外一方面，项目镀金会分散团队的精力，而这些精力应该被用于优先完成软件核心功能，以及做一些必要的缺陷处理，性能优化。