软件开发合同纠纷的律师随笔

吴国平北京市隆安律师事务所

笔者曾经承办多起软件开发合同纠纷，部分案件由法院判决，部分案件在仲裁委员会仲裁结案。笔者发现仲裁委员会在认定软件纠纷案件时的思路与法院存在一定差异，这种差异的原因来自仲裁员特定的软件或电子行业背景，正是这种背景使得仲裁员对于软件开发合同中争议问题的把握更为准确，最终认定的事实也更容易被当事人所接收。当然，法院法官在审理此类案件时对于法律规则的适用掌握更为严格，此为法院审理软件开发合同纠纷的特点。综合来讲，软件开发合同纠纷涉及多种编程语言和开发工具，相应的专业问题比起一般的合同纠纷更为复杂，案件审理中只有熟悉软件行业的特点和相关处理流程才能对争议的问题作出准确的判断，这无疑对承办律师和法官都提出了很高的要求。

以下，根据笔者的案例对于软件开发合同纠纷的特点简述如下：

一、开发周期技术上无法准确预测

根据国外的一项统计数据，受调查的软件项目进度平均延期222%，根据笔者与中国软件企业管理人员及程序员的沟通，对于软件开发延期的原因，企业管理人员认为项目经理早期计划不充分是最主要的原因，其次是应急预案制定不足；而程序员则认为客户需求变更和技术复杂程度是最主要的原因。

以上两者的差异来源于企业管理人员大多不懂软件，对于程序员也缺少了解。企业管理人员为了在有竞争对手的商业谈判争取订单，有时候不得不承诺减少开发周期，同时也是因为竞争的原因，软件开发成本限制参与项目的程序员数量和技术水准，而以上的结果是项目经理所最不愿意看到的。因此，从某种程度上来讲，软件开发合同前期的商务谈判过程决定了软件开发的成败，有些软件开发失败的真正原因恰恰是对于软件开发一无所知的客户。

客观存在的物体具有我们可以感知的属性，例如正在建造的房屋，但是对于软件来讲，开发中问题都存在于代码之中，无论开发经验多么丰富的程序员，他都无法准确预测开发过程中可能的问题。尽管软件行业存在很多评估工作量的理论和方法，例如中国某知名企业的开发规范中是这样表述的：“停工和节假日不安排工作；不考虑加班；考虑测试中发现问题的返工时间；考虑客户需求的稳定性；考虑各项活动的交接和信息的传递时间；考虑风险对活动的影响；考虑项目的效率因素，在正常估算的工期内增加20～40％的余量”。由以上开发规范中的考量因素可以看到，很多因素是无法准确量化的，同时评估工作仍需考虑团队的凝聚力问题，因此技术上准确地确定开发周期是很难实现的，最终还是靠开发团队的历史数据和经验来粗略估算。

基于以上的原因，项目经理应当在软件早期的商务谈判中向企业的管理人员充分说明开发周期的复杂性以争取宽裕的开发时间；对于企业管理人员来讲，应当在商务谈判中与律师协商，妥善安排有关开发周期的合同约定，例如开发合同中软件开发的各个阶段的时间限制应当只作为合同描述内容作为参考使用，而不能作为确定合同违约行为的依据，这样可以帮助软件开发人员在总开发周期内对分项时间进行调整。如确因客观原因造成无法按照预期完

成软件开发（笔者案例中曾有核心程序员离职造成开发延期），则软件公司应当及时向客户进行通报，提出延期请求并以备忘录、补充协议等形式对双方的合意进行书面确认。尽管大多数软件开发合同对于延期交付有罚金作为违约责任，但是开发过程中与客户协商延期的效果还是要远远好于开发周期后协商延期。

二、准确掌握软件需求的困难

因为客户与软件开发人员分属不同的行业，行业背景和特定专业知识的限制使得双方对于需求清单中文字表述的内容可能会存在理解的偏差，这种偏差如果只是涉及软件底层功能的部分调整还有可能及时弥补，但是如果涉及整个软件模块或架构的调整，可能给软件开发工作造成致命的影响。

笔者承办的一起案例中，软件需求说明书中表述的具体需求为“监控界面可以实现多路监控”，程序员设计的实现路径是在同一个计算机上同时打开两个浏览器界面，以上两个界面可以分别显示两组不同的视频内容，程序员认为以上方式即为需求说明书中所说的“实现多路监控”。但是在软件进行验收时，客户提出“多路监控”是指在同一个浏览器的监视界面同时显示两组视频内容，至此双方对于软件需求的理解产生歧义。因为以上软件的功能调整涉及数据服务器以及嵌入的视频功能模块的调整而无法在短期内完成，最终致使软件无法按期交付并引发诉讼。

如果单纯以法律规则来判断以上案例中的争议，需要确定哪一方的理解更符合“多路监控”所表述的内容，《中华人民共和国合同法》第62条对合同约定不明的各种情况做出了相应的规定，但是遗憾的是无法简单套用62条的规定来确定以上争议，因此法院退而去其次，采用“第一时间”的标准来确定程序员理解的“多路监控”方式是否实质违反客户的需求本意，即客户发现程序员展现此功能时，客户是否“第一时间”提出异议，如果答案是肯定的，则可以认定程序员对于软件需求的理解不符合客户的要求。

细致分析法院以上思路，我们不难发现，法院在确定软件需求时是以客户的意愿作为判断依据的，但是对于在合同附件中双方均认可的软件需求清单来讲，脱离具体的文字表述去推断客户的具体需求明显是对开发人员不公，因为需求清单中文字表述的内容是软件开发人员确定需求最直接的来源和依据，至此，问题又回到了法律规则无法确认的“多路监控”的文本解释上面。

事实上，我们可以从软件的开发过程来分析造成双方对需求理解不同而造成开发失败的责任，即有能力、有机会消除理解歧义的一方负有排除歧义的义务，而怠于履行义务的一方对软件开发失败负有过错，应当承担相应的赔偿责任。

软件开发合同中一般都没有非常明确的针对双方具体沟通事务的约定，软件公司在开发前期都会与客户进行反复沟通以确定需求清单的内容，但是一旦进入开发流程，开发人员有可能忽略与客户沟通软件开发的中间成果。例如，由需求清单整理的功能需求说明书（SRS）、软件产品架构设计说明书、软件用例等文件都单纯成为开发人员之间内部沟通协调的文件，而忽略了与客户进行确认的过程。技术上来讲，软件开发的所有工作都是以软件用例作为出发点和基本依据的，软件用例也是底层程序员了解产品功能和使用场景的依据。与客户对软件用例进行沟通也最有可能在开发初期消除对需求理解的歧义。