軟體開發要以客戶為導向，而不是技術為導向；換句話說，就是要做面向客戶的軟體開發。客戶是對產品或專案買單的人，我們辛苦的努力，最後能換回多少人民幣，關鍵就是客戶了。面向客戶的開發，能夠維繫和客戶的良好關係，減少返工次數，降低風險，最終提高開發效率，保證按時交付。
那麼如何做好面向客戶的軟體開發呢？我認為要把握住下面這幾點：
1、把滿足客戶的需求作為團隊共同的願景
通常，專案組內不同分工的人員都把完成自己的本職工作定義為自己成功的標準。需求人員的成功就是盡可能大範圍地捕獲客戶的需求；系統架構設計師的成功就是設計乙個穩定適應性強的架構；開發工程師的成功就是編寫出滿足系統設計文件要求的**；測試工程師的成功是保證系統沒有已知的bug... ...這些目標在一起，此消彼長，卻不能保證整個組內有乙個共同的目標。但是，當滿足客戶的需求這個願景為團隊所有成員所接受並且贊同的時候，在很多小問題上的爭議將蕩然無存，因為所有人都知道，大家是為了乙個共同的目標去努力的；同時，這還能建立起合作和信任，這比所有人技能的總和還要大。
2、選定客戶可控的軟體生命期模型
瀑布模型不適合做面向客戶的開發，因為在瀑布模型面前，只有走完整個模型，客戶才能看到他要的東西。換句話說，客戶在整個專案週期中，對專案是不可視的。不可視的專案週期給客戶一種對專案失去控制的感覺，這會引發很多問題，比如進度計畫，比如需求變更，等等。
階段交付，通常是受客戶歡迎的模型。這樣，客戶對整個專案的進展情況，有了直觀的認識。很多更改進度計畫或者提出進一步需求的想法，會被客戶主動拋棄，因為客戶知道了，這對專案會帶來什麼後果。同時，在每次交付之後，都能矯枉過正，最大化地滿足客戶需求。
3、弄清楚真正的客戶是誰
這個問題非常重要！
通常，客戶會派出代表來提出需求，監控專案進行。但是，在很多時候，這個代表根本無法對專案做出決定性的決定！在他身後，有著更大的領導在指揮。這也是在專案進行中，客戶代表會提出很多不合理要求的原因。在專案啟動階段，務必要通過各種手段，對這一情況深入了解，然後在專案進行中，做好對幕後領導的匯報工作（哪怕只是對巨集觀問題的郵件抄送也比什麼都不做強很多）。
4、準確捕捉客戶需求
客戶對自己的需求往往是十分模糊的，即使提出書面的需求說明書，也不過是乙個草案，無法指導開發進行。但是，當客戶看到開發出來的東西的時候，通常思維會變得活躍起來，會提出很多進一步的需求。開發方的需求人員，應該善於利用這一點，使用介面原型法，誘導客戶提出更多的需求出來。
5、控制客戶需求範圍
客戶的需求在天花板上，而我們的產品在地下。
客戶由於不懂軟體開發，會提出很多很多不切合實際、很難滿足的需求；通常，客戶還會認為他們提出的需求很容易實現。所以，一定要在專案啟動階段，把客戶需求從天花板上拉下來，甚至放到地下踩兩腳！
6、對需求變更的態度
不管專案組成員做得多麼好多麼到位，需求變更是遲早會出現的。教條式的全盤拒絕變更，以及完全迎合客戶滿足所有變更都是不可取的。較好的態度是接受對專案影響不大的變更，以此保持和客戶的關係。
7、維繫和客戶的關係
在每個里程碑都搞乙個和客戶的慶祝活動，經常發一些印有團隊標誌的紀念品，最重要的是，要偶爾給客戶代表的上司發郵件，稱讚客戶公司和客戶代表幾句。
做這些應該找市場部、銷售部的同事幫忙，他們往往更在行。
物件導向軟體開發方法概述
總的來說，軟體開發都會經歷一下生命週期 為了提高軟體的開發效率，降低軟體的開發成本，乙個良好的軟體系統應具備以下特點 如何才能使軟體系統具備以上特點呢？加入吧整個軟體系統分解成多個小的子系統，每個子系統之間相對獨立把這些子系統像最積木一樣靈活的組裝起來構成整個大的軟體系統。這樣設計出來的軟體肯定能獲...
自上而下的軟體開發和自下而上的軟體開發
自上而下 top down 開發模式是指從乙個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的 開發任務就完成了。使用這種方式，你需要設計 編寫出所有你需要的但還沒有實現模擬介面 服務 偽 自下而上 bottom up 開發模式是指從乙個應用的最底層開始開發。這...
物件導向設計原則 《敏捷軟體開發》
摘抄自 敏捷軟體開發 原則 方法與實踐 robert c.martin 1 srp 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。職責即為 變化的原因 2 ocp 開放封閉原則 軟體實體 類 模組 函式等 應該是可以擴充套件的，但是不可修改。對於擴充套件是開放的,對於更改是封閉的.關鍵是...