需求溝通為什么那么難？
例如：客戶在談需求時，他認為需要改變一些內容，但是他不會去說業務上的背景和他所在環境。當然，如果業務背景程序員不了解，我們可以主動去問、去了解。比較容易出問題的就是，客戶說的一些需求程序員是能夠理解的，但是程序員理解的東西跟客戶理解的東西是完全不一致的，更糟糕的是，大家并不能夠發現這中間的差異。
一些不懂軟件開發的客戶，他往往對于系統的認知是停留在他能看得到的東西。比如同樣是在頁面上加3個按鈕，客戶會覺得加一個按鈕花一天，那加另外一個按鈕也是花一天。但是他不能理解的是，可能一個按鈕我們只要10分鐘就能加好，因為是很簡單的功能，或者說是已經做過的東西，我們再做一遍當然很快。但另外一個按鈕，是全新的內容，會涉及到很多東西，那么可能加這個按鈕卻需要一周，甚至更長時間。
再比如，很多客戶說他想做一個頁面或者功能，這是經過他加工過的。而他在這個加工之前，原本有一個痛點或者問題的，那么如果我們按照他加工的內容來開發，即使是百分百還原他的構想，也不是他需要的。
最佳解決方案怎么來的？
那么，軟件開發正確的溝通方式是什么？客戶直接告訴程序員你的痛點或者問題，而不是解決方案！這一點很重要！因為大部分時候，客戶的解決方案其實并不能、也基本不可能站在一個開發者角度去思考。
程序員要做的，就是首先讓客戶把問題/痛點表達出來，也可以說一些解決方案，然后程序員去思考，告訴他這個方案是不是可行，是不是有一些你沒有想到的地方。我們從程序的視角，客戶從業務視角，一起去討論出一個最好的解決方案。
客戶一般是當前處于一個困境下，給出來的需求是非常短期、緊迫的，或者說不是站在一個全局的角度給出了一個需求。而作為程序員，是需要看到全局的。這部分需求實現的代碼是不是能符合整體系統的框架，會不會跟其他內容有沖突？再去評估客戶的需求對于未來來講是不是一個可持續的狀態，避免出現拆東墻補西墻，或者說把后期修改更新的途徑封死，不停地打補丁。
總而言之，每當程序員拿到一個需求，一定要去考慮這個需求在未來會不會發生變動，他的考慮是不是整體的、全面的？需求溝通不一致，客戶發現做出來的東西跟他想的是完全不一致的，這個成本其實是很高的。
怎樣才能做出好的軟件？
固定價格的項目由于有成本和預算的限制，程序員認為他可能對于需求沒有那么多的精力和時間去細細了解。而軟件開發ODC的付費模式，就是按時間去計費，這種服務與總包形式的服務核心不一樣，總包形式只關注于結果。但是軟件本身，并不像汽車、手表這種消費品，軟件本身是不確定的，它本身就是一個思維的產物，所以怎么想——這個過程很重要。統一了需求以后，才能做出一個比較好的產品。
所以軟件開發ODC服務相對來講，會比傳統的外包（固定價格、總包）形式的合同更有利于把產品做好。不管是程序員，還是客戶，都愿意花時間去面對問題，把需求了解清楚了以后再開工。雖然從時間上來看，似乎會比傳統的合作方式成本更高一點。但是，這種形式的服務規避了更大的風險，從長遠來看，從達成的結果和效率來看，未必比固定價格要貴。
還有一點很重要，因為對時間付費，所以這對客戶也是有約束的。這部分約束反映到整個項目中，就是從需求端先行把控，客戶會督促自己盡快明確需求，想清楚問題/痛點。如果需求不清楚造成的返工，客戶也是有責任的。
軟件開發ODC服務的合作形式需要兩方的信任，最終造成的效應就是不管是甲方還是乙方，都希望盡可能地把這個項目需求整理清楚，然后考慮清楚，進而把項目做好，解決眼前的痛點乃至長遠的考量，最終確保做出來的軟件是可用的，且對業務/企業發展起到積極促進作用的。
