在软件开发项目中，许多组织采用合作开发的方式，这种方式的优点在于合作各方可以各取所长。例如业主方可以发挥其对业务过程理解方面的能力，而合作商（一般是专业的软件公司或IT企业）可以发挥其技术方面的优势。但另一方面，这种方式也为项目管理带来了许多困难。由于在合作方式下，项目团队成员来自不同的组织（业主方和合作商），在项目实施过程中的冲突就往往不可避免，在这种情况下，工作任务的确定、各方利益的平衡、团队成员间的沟通以及激励问题等均可能导致项目实施过程中产生各种阻力，因而需要项目经理付出很大的努力来解决。

笔者曾经作为项目管理人员参加过一个全国性软件项目的管理，这个项目的应用范围遍及全国上百个城市，项目实施团队的结构也相对比较复杂，团队成员来自业主方及两家合作商，来自业主方的成员主要负责业务策略和业务流程的制定、项目工程的总体协调并协助进行技术实施；来自合作商的团队成员则负责具体的技术实现和工程实施、对业主方技术人员进行培训并提供技术方案制定过程中的技术咨询。在这样一个环境中，冲突几乎在每个星期都会以不同的形式发生，而解决这些冲突的方法和过程也为管理软件合作开发项目提供了许多经验和教训，尤其在工作任务管理、各方利益的平衡以及通过沟通加强信息管理等几个方面。

任务管理——明确任务，是解决冲突的根源

明确的工作任务和职责划分是项目顺利实施的必要前提之一，但软件项目的特殊性使得项目管理中至关重要的“范围管理”（ScopeManagement）遇到了很大困难，某些子系统的开发任务在业主与合作商签订的项目合同中进行了明确的定义，但仍然有许多任务需要双方在实施过程中逐步明确。在合作项目中，这种情况产生的后果相对更为严重，因为项目团队的工作方式是合作方式，当因工作任务不明确而产生问题时，极易在来自不同组织的团队成员间产生矛盾，从而引发冲突。c

由于软件开发项目本身的特点，在项目启动阶段就给出完整的系统需求是极为困难（甚至是不可能）的，在许多情况下，随着开发进程逐步确定需求，以满足实际环境的不断变化不仅是权宜之计，而且更是现实的需要。另一方面，在大多数软件开发项目中，需求的逐步细化或更改尽管是不可避免的，但也是可以管理的。一般而言，在某一时点上的需求都包含两部分的内容：已经明确确定的部分和目前难以明确确定的部分，而“迭代式”软件开发过程的目标就是随着开发过程的深入逐步减少尚未明确确定的需求，并同时增加明确确定的需求。

“迭代式”软件开发过程的主要原理是：在软件开发项目（尤其是一些大型软件开发项目）中，在项目开始阶段，需求中难以明确确定的部分占有相当大的比例，因此在制定项目计划时基本上无法准确估算其工作任务的范围、进度以及相关的费用，这就给项目实施带来了极大的风险。在这种情况下，软件产品的第一版本（而不是软件原型）反映了需求中已经明确的那一部分的功能，此时，用户可以使用这个第一版本的软件并在使用过程中提出进一步的需求，然后项目团队可以根据上述相对更加明确的需求开发第二版本。在第二版本的软件开发过程中，用户可继续使用第一版本的软件（因为该版本软件是一个实际的完整产品而非原型，因此除了功能相对较弱外，用户基本可正常使用）。上述“迭代式”的软件开发过程能够在一定程度上有效降低大型软件开发过程中的风险。

但这种“迭代式”软件开发过程在合作型软件开发项目中会遇到一些困难，其关键在于：在这种方式下，项目实施过程中许多工作任务是逐步确定的，甚至到底要推出多少个版本在项目启动阶段也很难精确确定。另一方面，合作项目的合同却在项目开始阶段就需要签署，而合同的关键部分——项目费用在采用迭代式开发方式下很难在项目的开始阶段就确定，当然如果项目费用的支付是按照实际费用进行结算的话，这个问题并不存在。但在目前国内许多软件项目中，业主方往往倾向于使用“固定价格合同”以控制费用风险，这一合同形式要求对项目费用有相对明确的估算，这恰恰与“迭代式”软件开发方式产生了矛盾。

解决这一矛盾的方法之一是采用与之相适应的“迭代式合同”，即在项目的第一阶段，有关的工作被分为两部分：已明确确定的工作和尚未明确确定的工作，其工作任务内容分别来自于已经明确的需求和尚未明确的需求，其中明确确定的工作必须在第一阶段完成，并给出明确的费用估算，而尚未明确确定的工作在第一阶段可以是部分完成并在今后的阶段中继续进行；当第一阶段结束后，业主方支付确定的工作任务的费用以及已完成部分的尚未确定的工作任务的费用（这是由于费用结算是分阶段进行的，而工作任务的执行则是连续的，因此有可能根据实际的需要，某些尚未明确的、从而未在项目计划中反映的工作内容也已经在项目实施过程中完成了），并对剩下的工作进行重新估算，这样反复进行直到项目完成（如图所示）。

这种合同制定方法使得业主方与合作商共同承担项目实施过程中的风险，随着项目实施进程的不断推进，产品需求和相关的工作任务变得越来越明确，工作任务中的“已确定”部分比例越来越高，双方所承担的风险也随之降低。
　
利益管理——建立开放的、互相信任的项目团队文化，平衡各方利益

当项目团队成员分别来自于业主方和合作商时，利益冲突几乎是不可避免的，尤其是对于涉及相对复杂技术的软件开发项目，利益冲突往往是最难以解决的问题之一。

首先，在技术方案的制定过程中，合作商方面的团队成员会倾向于选择那些对于他们自己所在公司而言费用相对较低的方案，而这些方案却常常不符合业主方的最大利益；另外，合作商方面提出的技术方案也经常会包含一些购买由其生产或经销的产品或工具等，这些建议的提出并不一定是恶意的，甚至确实存在充分的理由，但在业主方看来，却有可能成为合作商试图损害其利益的证据。

在这种情况下，一种开放性的、互相信任的团队文化的建设就有助于制定一个客观而准确的项目技术方案和实施计划。在许多情况下，召集一个由项目各方人士（包括没有利益关系的第三方人士）参加的评估小组有时是十分必要的，这种评估不仅包括技术方面的评估，更应当包括经济方面的评估。但从根本上来看，良好的团队文化与规范化的评估流程相比，同等重要（有时甚至更为重要）。

在项目启动之初就努力建立一种“项目导向”的思考方式对于解决各方利益冲突也能起到帮助作用，在这种思考方式下，项目本身的成功对于每个项目团队成员和项目参与各方（包括业主方和合作商）均是首要的：如果项目失败，则不仅业主方受损，从长远来看，合作商的利益（其市场地位）也会受到损害。同时，对于那些来自业主方的项目管理人员而言，适当的“换位思考”也是需要的。例如，来自于合作商的工程师可能会建议购买由他们公司生产的产品而不是购买其他公司的（可能是价格相对低廉的）产品，初看起来这一提议自然是损害业主方利益的，但如果考虑到对相关产品的熟悉程度将有助于工作效率的提高从而最终节约人工成本，这种建议也是有一定合理性的。

信息管理——充分的沟通和参与是有效的激励机制

在合作项目中，对于涉及到项目进度和人力资源调度这样一些问题而言，充分的沟通是一个关键性的管理手段。尽管定期和不定期的项目评估能够在一定程度上解决一些问题，但需要记住的是，只有那些具体负责某项工作的团队成员对有关的工作才最有发言权，也只有他们的行动才最终决定了某些计划或决策的执行效果。如果在计划制定过程中缺乏沟通，那些持有不同意见的项目团队成员就可能在执行中降低努力水平。而对于软件开发这样的项目而言，团队成员的努力才是保证项目成功的最关键的因素之一。

“参与”是激励机制中的重要一环，每个团队成员（尤其是那些负责某一子系统的工程师）都应当在计划制定过程中发表意见，不仅是因为经过充分讨论后的计划才能更加切合实际，更重要的是，团队成员在执行其“自己的计划”过程中会更加努力。在软件开发项目中，团队成员大多是技术人员，对于技术人员而言，通过新工具和新技术的使用能够提高其专业水平，因此在软件项目实施过程中适当引进新工具和新的开发环境有时也是一种良好的激励手段，当然这种手段的采用要有两个前提：相关的工具确实有效，同时需要提供一定的培训以保证工作的效率。

在大型的软件项目中，地理位置有时会造成沟通上的困难，尤其在合作方式上，软件开发工作可能在业主方或合作商的所在地进行，或者在远离双方总部的另一个地区进行技术实施，这样某一方或者是双方的团队成员就会远离其所在组织的管理层，这样对其日常工作绩效的考核就会产生一定的困难。因此，定期的工作总结无论对于项目参与各方还是对于每个项目团队成员而言都是很重要的，这些总结不仅能够反映团队成员的工作绩效，还能及时反映有关的困难以使这些困难得到及时处理。很重要的一点是，上述工作总结应当发送给团队的所有成员及相关组织的高层管理人员，在软件项目中，开放的沟通环境所带来的优点一般要大于保密所带来的好处。当然，业主方和合作商的高层管理人员也应当经常到开发工作所在地了解情况，尽管物理距离与心理距离不是一回事，但在某些情况下，物理距离的缩短是有助于心理距离的拉近的。