專案背景是這樣子的，某成本測算系統要在原來的住宅邏輯上要求融入商業的邏輯，針對需求第一時間就會考慮這些問題，並且考慮解決的方式、面臨的風險等。
1、商業和住宅相互比較差距有多大？
2、住宅的邏輯可以包括商業的多少？
3、系統目前框架擴充套件性如何？
4、對於需求是編輯、新增還是重構？
在基本了解需求之後就動手對系統進行整改，在這個過程中沒有考慮的問題開始浮現，設想的解決方案不能解決問題，業務測試中需求理解出現偏差等，所以針對這些問題提出一些的思考和總結，這些內容可能是很多軟體開發中普遍存在，也是總結過很多遍的內容。
1、明確的需求，乙個明確的需求對於軟體開發來說是至關重要的，在軟體工程相關的書籍和前人的總結中都是很重要的一條忠告。但是很多時候情況並不會按照設想一樣有著明確的需求，要麼業務人員對業務的不確定性，描述的不夠清晰明了，要麼就是對接需求人員沒有真正理解到需求，這個時候就是不明確的需求。在專案中比如「反算」、「業態」等這樣表意不清晰的詞彙，如果這個時候不帶著嚴謹的態度弄明白，而是按照自己一知半解的來開發，結果很可能是返工或者重來的風險。這就要求我們對待需求保持著精益求精的態度，明確的需求是乙個好的開端。
2、共同的語言，在業務系統中，業務人員和技術人員相互溝通的過程中很多時候就是業務對乙個需求訴說著各種專業的名詞，業務的角度解釋為什麼是這樣子？依據了行業的什麼標準？參考了什麼規則？設計的初衷是什麼？這時候的技術人員完全就是不理解，似懂非懂的樣子，然後按照自己已經理解的開始對業務人員訴說技術上怎麼解決，設計怎麼樣的資料庫和字段、使用什麼軟體技術，然後業務人員因為行業原因一樣不懂，覺得是按照他訴說的樣子開發的，在測試的時候大家都會恍然大悟原來不是這樣子。究其原因還是大家沒有乙個共同的語言，沒有統一語言，交流不在乙個頻道上，這也就是為什麼要在乙個行業深耕多年，才可以把這個行業的業務做好，因為這是乙個通過多年付出學習成本，學習相關行業知識的過程，和業務對接的時候無縫對接，在開發時候選擇最優的技術，甚至想到業務沒想到。但是很多時候這是乙個比較理想的狀態，所以合理就是與業務人員建立共同的語言，互相在共同語言的框架下溝通，這樣出現偏差的可能性相對小了。
3、換位的思考，換位就是系統開發人員站在業務的角度審視系統，比如業務人員使用系統功能的時候，是否會出現歧義，是否操作的順暢，是否接受這種方式，不同的業務操作習慣，要求不一樣，比如會計相關的業務對數值精度相當的敏感，金融行業對安全性要求高等。
4、完整的文件，不管是在系統開發前的文件，還是開發中，開發後的文件都是記錄乙個功能開發過程，方便開發人員依據文件開發，是業務、需求、開發一起確認的，當要功能朔源的時候有查詢的內容。而且對於要進行二次開發，新增需求時候重要考慮的文件資訊。
在這個系統融入商業需求中，與業務人員的溝通，對**調整與重構對這些思考深有體會。很多專案這些問題是不可以避免，更多的是盡量進行規避，減少不必要的需求誤差，尋求最合理的方式，對業務要足夠重視。這就是業務與技術的矛盾，業務建立業務的圈子，技術建立技術的圈子，沒有交集，出現矛盾的狀態。
技術與業務的關係
乙個公司裡面，真正值錢的東西，不是技術，而是業務知識，技術是實現業務的一種手段，是為業務服務的，主從關係，不可搞錯 從技術角度，追求的不再是純粹的技巧，而是方法這個層次，努力尋求正確的做事方法。即關心 怎樣才能蓋出好房子 而不是 如何把石頭從貨車裡搬運到工地上 用流行的話說，就是 只要方法正確，結果...
關於技術與業務的理解
首先，技術團隊，最終是要實現客戶價值。中間的定位是更高效的實現客戶價值。如何高效實現？從三個角度看，一是是否有結果，結果是晉公升的前提，要考慮我們是否產生了客服價值。看產生客戶價值的過程中，技術團隊與單純的業務團隊不同，技術團隊還要看是否可持續發展，從業務到產品到技術有幾個環節。從業務來看，有個好想...
原創 是什麼導致了業務人員和技術人員的矛盾？
在實習的兩個月裡，作為技術人員，我經常是要和業務人員溝通的。特別是在接手大眾人才網的工作後，每天的工作幾乎都變成了應對業務人員無盡的需求。業務經常變化，結果導致技術也要跟著業務不停的變化。曾經有一次，上午根據業務人員更改的功能，下午就被業務人員要求修改回來。業務人員的這種不斷變化的結果往往導致技術人...