技術開發合同，涉及的都是一些數據，軟件，程序等內容，所以對專業的要求非常高，所以當事人在簽訂技術開發合同時總是會有一些問題如一些投資企業對軟件不了解，對程序員也了解的不多，所以往往會引起一些糾紛。那么技術開發合同糾紛內容如何？
一、開發周期技術上無法準確預測
根據國外的一項統計數據，受調查的軟件項目進度平均延期222%，根據筆者與中國軟件企業管理人員及程序員的溝通，對于軟件開發延期的原因，企業管理人員認為項目經理早期計劃不充分是最主要的原因，其次是應急預案制定不足;而程序員則認為客戶需求變更和技術復雜程度是最主要的原因。
以上兩者的差異來源于企業管理人員大多不懂軟件，對于程序員也缺少了解。企業管理人員為了在有競爭對手的商業談判爭取訂單，有時候不得不承諾減少開發周期，同時也是因為競爭的原因，軟件開發成本限制參與項目的程序員數量和技術水準，而以上的結果是項目經理所最不愿意看到的。因此，從某種程度上來講，軟件開發合同前期的商務談判過程決定了軟件開發的成敗，有些軟件開發失敗的真正原因恰恰是對于軟件開發一無所知的客戶。
客觀存在的物體具有我們可以感知的屬性，例如正在建造的房屋，但是對于軟件來講，開發中問題都存在于代碼之中，無論開發經驗多么豐富的程序員，他都無法準確預測開發過程中可能的問題。盡管軟件行業存在很多評估工作量的理論和方法，例如中國某知名企業的開發規范中是這樣表述的：“停工和節假日不安排工作;不考慮加班;考慮測試中發現問題的返工時間;考慮客戶需求的穩定性;考慮各項活動的交接和信息的傳遞時間;考慮風險對活動的影響;考慮項目的效率因素，在正常估算的工期內增加20～40%的余量”。由以上開發規范中的考量因素可以看到，很多因素是無法準確量化的，同時評估工作仍需考慮團隊的凝聚力問題，因此技術上準確地確定開發周期是很難實現的，最終還是靠開發團隊的歷史數據和經驗來粗略估算。
基于以上的原因，項目經理應當在軟件早期的商務談判中向企業的管理人員充分說明開發周期的復雜性以爭取寬裕的開發時間;對于企業管理人員來講，應當在商務談判中與律師協商，妥善安排有關開發周期的合同約定，例如開發合同中軟件開發的各個階段的時間限制應當只作為合同描述內容作為參考使用，而不能作為確定合同違約行為的依據，這樣可以幫助軟件開發人員在總開發周期內對分項時間進行調整。如確因客觀原因造成無法按照預期完成軟件開發(筆者案例中曾有核心程序員離職造成開發延期)，則軟件公司應當及時向客戶進行通報，提出延期請求并以備忘錄、補充協議等形式對雙方的合意進行書面確認。盡管大多數軟件開發合同對于延期交付有罰金作為違約責任，但是開發過程中與客戶協商延期的效果還是要遠遠好于開發周期后協商延期。
二、準確掌握軟件需求的困難
因為客戶與軟件開發人員分屬不同的行業，行業背景和特定專業知識的限制使得雙方對于需求清單中文字表述的內容可能會存在理解的偏差，這種偏差如果只是涉及軟件底層功能的部分調整還有可能及時彌補，但是如果涉及整個軟件模塊或架構的調整，可能給軟件開發工作造成致命的影響。
筆者承辦的一起案例中，軟件需求說明書中表述的具體需求為“監控界面可以實現多路監控”，程序員設計的實現路徑是在同一個計算機上同時打開兩個瀏覽器界面，以上兩個界面可以分別顯示兩組不同的視頻內容，程序員認為以上方式即為需求說明書中所說的“實現多路監控”。但是在軟件進行驗收時，客戶提出“多路監控”是指在同一個瀏覽器的監視界面同時顯示兩組視頻內容，至此雙方對于軟件需求的理解產生歧義。因為以上軟件的功能調整涉及數據服務器以及嵌入的視頻功能模塊的調整而無法在短期內完成，最終致使軟件無法按期交付并引發訴訟。
如果單純以法律規則來判斷以上案例中的爭議，需要確定哪一方的理解更符合“多路監控”所表述的內容，《中華人民共和國合同法》第62條對合同約定不明的各種情況做出了相應的規定，但是遺憾的是無法簡單套用62條的規定來確定以上爭議，因此法院退而去其次，采用“第一時間”的標準來確定程序員理解的“多路監控”方式是否實質違反客戶的需求本意，即客戶發現程序員展現此功能時，客戶是否“第一時間”提出異議，如果答案是肯定的，則可以認定程序員對于軟件需求的理解不符合客戶的要求。
細致分析法院以上思路，我們不難發現，法院在確定軟件需求時是以客戶的意愿作為判斷依據的，但是對于在合同附件中雙方均認可的軟件需求清單來講，脫離具體的文字表述去推斷客戶的具體需求明顯是對開發人員不公，因為需求清單中文字表述的內容是軟件開發人員確定需求最直接的來源和依據，至此，問題又回到了法律規則無法確認的“多路監控”的文本解釋上面。
事實上，我們可以從軟件的開發過程來分析造成雙方對需求理解不同而造成開發失敗的責任，即有能力、有機會消除理解歧義的一方負有排除歧義的義務，而怠于履行義務的一方對軟件開發失敗負有過錯，應當承擔相應的賠償責任。
軟件開發合同中一般都沒有非常明確的針對雙方具體溝通事務的約定，軟件公司在開發前期都會與客戶進行反復溝通以確定需求清單的內容，但是一旦進入開發流程，開發人員有可能忽略與客戶溝通軟件開發的中間成果。例如，由需求清單整理的功能需求說明書(SRS)、軟件產品架構設計說明書、軟件用例等文件都單純成為開發人員之間內部溝通協調的文件，而忽略了與客戶進行確認的過程。技術上來講，軟件開發的所有工作都是以軟件用例作為出發點和基本依據的，軟件用例也是底層程序員了解產品功能和使用場景的依據。與客戶對軟件用例進行溝通也最有可能在開發初期消除對需求理解的歧義。
綜上，由開發合同中的需求清單到最終完成開發、交給客戶驗收的過程中，軟件開發人員將中間工作成果與客戶進行溝通確認的過程可以避免對需求清單理解歧義的發生。客戶對于軟件開發的具體流程和細節并不熟悉，因此軟件開發人員有機會通過溝通來消除軟件需求理解的歧義。因此，以上案例中，應當確定軟件公司對于因理解歧義而導致開發失敗負有責任。從律師的角度來看，應當將軟件開發流程中的關鍵節點確認作為軟件開發合同約定的內容之一，溝通過程中形成的確認文件也可以成為預防糾紛的有效形式。
實踐中對于軟件需求還有一種情況，那就是客戶在開發過程中不斷提出新的功能要求。出現這種情況的原因是多方面的，部分是因為客戶自身的業務需求不確定，部分是因為在開發周期較長的項目中，客戶在開發過程中了解同行業更為成熟的做法和經驗，因此提出新的功能需求。對于律師來講，應當在軟件開發協議中約定需求變更的程序和條件，例如“若需求變更影響不大，不增加費用和延長開發時間;若變更會對開發進度或工作量有較大影響的，應當延長開發時間及增加開發費用”。但是具體實踐中因為程序員缺少相關合同事務的操作經驗，同時因客戶方面繁瑣的審批流程遲遲不能及時回復而程序開發的時間又十分緊張，使得需求控制的相關程序和文件未及時提出并確認，最終在引發糾紛時無法確定具體的責任歸屬。對于項目經理來講，應當及時與律師進行溝通解決程序問題可以有效避免此類問題的訴訟風險。
三、關于軟件源代碼的部分交付
為了在履行開發協議的過程中更好地保護客戶的利益，國外的軟件開發協議中開始出現軟件源代碼在開發過程中部分向客戶交付的條款，也有的是通過第三方的源代碼保管機構，(例如InnovaSafe和National Software Escorw,中國現在尚未發現有提供類似服務的機構，但是隨著商業需求的發展，相信很快就會有這樣的服務在國內出現)理論上來講，軟件開發中會產生大量的迭代版本，開發中間向客戶交付的部分代碼并無實質意義，但是對于開發末期已經進入調試階段的軟件代碼來講，盡管與最終代碼仍有不同，但是其價值已經可以保護和持有代碼的當事人一方。這也是將軟件代碼的部分交付進入軟件開發合同的原因之一。
實踐中，還有一種情況部分交付代碼的情況，客戶在開發過程中為了行政審批的相關項目或者其他有關的商務合作，要求軟件公司先行提供部分代碼以取得中國版權中心頒發的登記證書。按照版權中心的要求，這一部分代碼約3000余行，相對于大型項目的總行數來講，只占非常小的一部分，因此一般軟件公司都會同意客戶的這一請求。
通過對上述內容的閱讀我們知道技術開發，涉及的一些軟件編程等專業性極強的內容，所以客戶在簽訂合同的時候，往往對這些東西不了解，導致約定交易金額等方面便會產生一定的糾紛。
