技术开发合同，涉及的都是一些数据，软件，程序等内容，所以对专业的要求非常高，所以当事人在签订技术开发合同时总是会有一些问题如一些投资企业对软件不了解，对程序员也了解的不多，所以往往会引起一些纠纷。那么技术开发合同纠纷内容如何？
一、开发周期技术上无法准确预测
根据国外的一项统计数据，受调查的软件项目进度平均延期222%，根据笔者与中国软件企业管理人员及程序员的沟通，对于软件开发延期的原因，企业管理人员认为项目经理早期计划不充分是最主要的原因，其次是应急预案制定不足;而程序员则认为客户需求变更和技术复杂程度是最主要的原因。
以上两者的差异来源于企业管理人员大多不懂软件，对于程序员也缺少了解。企业管理人员为了在有竞争对手的商业谈判争取订单，有时候不得不承诺减少开发周期，同时也是因为竞争的原因，软件开发成本限制参与项目的程序员数量和技术水准，而以上的结果是项目经理所最不愿意看到的。因此，从某种程度上来讲，软件开发合同前期的商务谈判过程决定了软件开发的成败，有些软件开发失败的真正原因恰恰是对于软件开发一无所知的客户。
客观存在的物体具有我们可以感知的属性，例如正在建造的房屋，但是对于软件来讲，开发中问题都存在于代码之中，无论开发经验多么丰富的程序员，他都无法准确预测开发过程中可能的问题。尽管软件行业存在很多评估工作量的理论和方法，例如中国某知名企业的开发规范中是这样表述的：“停工和节假日不安排工作;不考虑加班;考虑测试中发现问题的返工时间;考虑客户需求的稳定性;考虑各项活动的交接和信息的传递时间;考虑风险对活动的影响;考虑项目的效率因素，在正常估算的工期内增加20～40%的余量”。由以上开发规范中的考量因素可以看到，很多因素是无法准确量化的，同时评估工作仍需考虑团队的凝聚力问题，因此技术上准确地确定开发周期是很难实现的，最终还是靠开发团队的历史数据和经验来粗略估算。
基于以上的原因，项目经理应当在软件早期的商务谈判中向企业的管理人员充分说明开发周期的复杂性以争取宽裕的开发时间;对于企业管理人员来讲，应当在商务谈判中与律师协商，妥善安排有关开发周期的合同约定，例如开发合同中软件开发的各个阶段的时间限制应当只作为合同描述内容作为参考使用，而不能作为确定合同违约行为的依据，这样可以帮助软件开发人员在总开发周期内对分项时间进行调整。如确因客观原因造成无法按照预期完成软件开发(笔者案例中曾有核心程序员离职造成开发延期)，则软件公司应当及时向客户进行通报，提出延期请求并以备忘录、补充协议等形式对双方的合意进行书面确认。尽管大多数软件开发合同对于延期交付有罚金作为违约责任，但是开发过程中与客户协商延期的效果还是要远远好于开发周期后协商延期。
二、准确掌握软件需求的困难
因为客户与软件开发人员分属不同的行业，行业背景和特定专业知识的限制使得双方对于需求清单中文字表述的内容可能会存在理解的偏差，这种偏差如果只是涉及软件底层功能的部分调整还有可能及时弥补，但是如果涉及整个软件模块或架构的调整，可能给软件开发工作造成致命的影响。
笔者承办的一起案例中，软件需求说明书中表述的具体需求为“监控界面可以实现多路监控”，程序员设计的实现路径是在同一个计算机上同时打开两个浏览器界面，以上两个界面可以分别显示两组不同的视频内容，程序员认为以上方式即为需求说明书中所说的“实现多路监控”。但是在软件进行验收时，客户提出“多路监控”是指在同一个浏览器的监视界面同时显示两组视频内容，至此双方对于软件需求的理解产生歧义。因为以上软件的功能调整涉及数据服务器以及嵌入的视频功能模块的调整而无法在短期内完成，最终致使软件无法按期交付并引发诉讼。
如果单纯以法律规则来判断以上案例中的争议，需要确定哪一方的理解更符合“多路监控”所表述的内容，《中华人民共和国合同法》第62条对合同约定不明的各种情况做出了相应的规定，但是遗憾的是无法简单套用62条的规定来确定以上争议，因此法院退而去其次，采用“第一时间”的标准来确定程序员理解的“多路监控”方式是否实质违反客户的需求本意，即客户发现程序员展现此功能时，客户是否“第一时间”提出异议，如果答案是肯定的，则可以认定程序员对于软件需求的理解不符合客户的要求。
细致分析法院以上思路，我们不难发现，法院在确定软件需求时是以客户的意愿作为判断依据的，但是对于在合同附件中双方均认可的软件需求清单来讲，脱离具体的文字表述去推断客户的具体需求明显是对开发人员不公，因为需求清单中文字表述的内容是软件开发人员确定需求最直接的来源和依据，至此，问题又回到了法律规则无法确认的“多路监控”的文本解释上面。
事实上，我们可以从软件的开发过程来分析造成双方对需求理解不同而造成开发失败的责任，即有能力、有机会消除理解歧义的一方负有排除歧义的义务，而怠于履行义务的一方对软件开发失败负有过错，应当承担相应的赔偿责任。
软件开发合同中一般都没有非常明确的针对双方具体沟通事务的约定，软件公司在开发前期都会与客户进行反复沟通以确定需求清单的内容，但是一旦进入开发流程，开发人员有可能忽略与客户沟通软件开发的中间成果。例如，由需求清单整理的功能需求说明书(SRS)、软件产品架构设计说明书、软件用例等文件都单纯成为开发人员之间内部沟通协调的文件，而忽略了与客户进行确认的过程。技术上来讲，软件开发的所有工作都是以软件用例作为出发点和基本依据的，软件用例也是底层程序员了解产品功能和使用场景的依据。与客户对软件用例进行沟通也最有可能在开发初期消除对需求理解的歧义。
综上，由开发合同中的需求清单到最终完成开发、交给客户验收的过程中，软件开发人员将中间工作成果与客户进行沟通确认的过程可以避免对需求清单理解歧义的发生。客户对于软件开发的具体流程和细节并不熟悉，因此软件开发人员有机会通过沟通来消除软件需求理解的歧义。因此，以上案例中，应当确定软件公司对于因理解歧义而导致开发失败负有责任。从律师的角度来看，应当将软件开发流程中的关键节点确认作为软件开发合同约定的内容之一，沟通过程中形成的确认文件也可以成为预防纠纷的有效形式。
实践中对于软件需求还有一种情况，那就是客户在开发过程中不断提出新的功能要求。出现这种情况的原因是多方面的，部分是因为客户自身的业务需求不确定，部分是因为在开发周期较长的项目中，客户在开发过程中了解同行业更为成熟的做法和经验，因此提出新的功能需求。对于律师来讲，应当在软件开发协议中约定需求变更的程序和条件，例如“若需求变更影响不大，不增加费用和延长开发时间;若变更会对开发进度或工作量有较大影响的，应当延长开发时间及增加开发费用”。但是具体实践中因为程序员缺少相关合同事务的操作经验，同时因客户方面繁琐的审批流程迟迟不能及时回复而程序开发的时间又十分紧张，使得需求控制的相关程序和文件未及时提出并确认，最终在引发纠纷时无法确定具体的责任归属。对于项目经理来讲，应当及时与律师进行沟通解决程序问题可以有效避免此类问题的诉讼风险。
三、关于软件源代码的部分交付
为了在履行开发协议的过程中更好地保护客户的利益，国外的软件开发协议中开始出现软件源代码在开发过程中部分向客户交付的条款，也有的是通过第三方的源代码保管机构，(例如InnovaSafe和National Software Escorw,中国现在尚未发现有提供类似服务的机构，但是随着商业需求的发展，相信很快就会有这样的服务在国内出现)理论上来讲，软件开发中会产生大量的迭代版本，开发中间向客户交付的部分代码并无实质意义，但是对于开发末期已经进入调试阶段的软件代码来讲，尽管与最终代码仍有不同，但是其价值已经可以保护和持有代码的当事人一方。这也是将软件代码的部分交付进入软件开发合同的原因之一。
实践中，还有一种情况部分交付代码的情况，客户在开发过程中为了行政审批的相关项目或者其他有关的商务合作，要求软件公司先行提供部分代码以取得中国版权中心颁发的登记证书。按照版权中心的要求，这一部分代码约3000余行，相对于大型项目的总行数来讲，只占非常小的一部分，因此一般软件公司都会同意客户的这一请求。
通过对上述内容的阅读我们知道技术开发，涉及的一些软件编程等专业性极强的内容，所以客户在签订合同的时候，往往对这些东西不了解，导致约定交易金额等方面便会产生一定的纠纷。
