隨著企業管理個性化、差別化的發展趨勢，管理軟體的定製化是乙個不可阻擋的趨勢。但對於軟體公司來說，定製軟體是成本最高、開發難度最大的軟體生產形式。一方面是客戶的需求，一方面是公司的成本，軟體企業如何兼顧這兩個方面呢？
定製軟體最容易採取的方法就是客戶怎麼說，我就怎麼做，不思考、不分析，依樣畫葫蘆。但是當你將軟體做好了交給客戶的時候，客戶說，我要的不是這樣，或者我還有其它要求，或者我當時說錯了，等等。你怎麼辦？你這時需要修改軟體。已經設計好的軟體可能要做很大的修改，否則你可能就滿足不了客戶的需求。而且這種修改還不好再跟客戶加收費用，客戶也不會同意給你加費用。甚至客戶還會追究你延誤了合同規定的交付日期。在這個時候客戶一般不會把責任攬到自己身上。
面對可能出現的這種情況，專案經理在軟體的使用者需求調研時，必須帶著思考的頭腦去調研。對於客戶提出的每個需求都需要真正分析，弄清這種需求的來龍去脈，判斷是否合理，以及這種需求將來可能變更的大體方向。
然後利用自己的專業知識和行業經驗，說服客戶盡量使用行業內通用的流程與處理方法，同時要理解客戶個性化的合理性，這樣才能避免將客戶一時考慮不周到的需求作為聖旨去設計程式。
對於比較強勢的客戶，在無法說服的時候，要將程式設計成通過簡單的配置就能在客戶現在的需求與將來可能的變化之間進行切換。因為客戶也是由乙個個的個人所組成，也有的人比較犟，不願意或沒有耐心聽取別人的意見，這時當然不能和客戶去爭辯，只能設計多種方案，通過管理員許可權進行切換。
還有些企業比較大，人比較多，在需求調研的時候不可能調研到所有的人，但參加調研的人對流程等的了解可能不夠全面，如果這時專案經理沒有經過充分思考就動手設計程式，可能設計好的程式在試用階段又要做很大的修改。
還有一種情況就是由於客戶不是計算機專業的人士，不善於用計算機語言去描述業務，或者調研人員在傾聽的時候漏掉了乙個細節，或者在交流的時候客戶和調研人員自說自話，造成客戶以為專案經理理解自己的觀點，專案經理以為客戶接受了自己的觀點。最後草草定案，也是造成程式和客戶要求產生較大差異的乙個重要原因。
我們不能將我們調研時沒有獲取全面準確的資訊當作是客戶的責任，因為客戶往往不是行家，客戶把我們的軟體公司當作專家的，是希望我們給他們提供一種他們想不到的解決方案的，因此我們就有責任使我們的定製軟體滿足任何客戶需求。
研究客戶需求的合理性，設計客戶各種可能的需求變更，表面上看是浪費了時間，但實際上是「磨刀不誤砍柴工」，到最後反而節約了時間，最起碼將軟體需要的時間由最初的不可控到開始的可以**。
如果軟體公司不能深刻理解客戶需求，或者沒有滿足客戶需求的多樣性、易變性，造成了軟體公司吃了很多辛苦，反覆修改軟體，最後勉強完成了專案，但客戶還不滿意，吃力不討好，將本來可以長期合作的專案做成了一竿子買賣，最後吃虧的還是軟體公司。
如果軟體公司不能理解客戶的需求，或者不具備對這個行業和這個業務的內在規律的了解，就需要去認真的學習，要學到真本事，學到可以活學活用的真本事，然後再開始做。否則，我認為，軟體公司可能不做這個業務更合算。軟體公司必須要有所為有所不為，要明白自己不是萬能的。要不然不僅僅是在這個專案中掙不到錢，而且有可能從此失去了這個客戶，甚至失去這個行業的准入權。
sql 樹形的靈活性
由於上面的方法，在函式中傳入表的名字，這樣每乙個有父子關係的表都必須有乙個函式，因為表名不一樣。我設想是不是可以把表名傳進去。於是就有了下面的寫法。quote create function dbo.getsubtreeinfo2 manager id as varchar 32 待管理的節點，從哪...
Ruby語法的靈活性？
對於ruby的語法不是很熟悉，遇到乙個問題，現在還沒有明白怎麼回事，先記下來，也許以後等用的熟練的就明白了 乙個form有兩個field，對應資料庫表中的兩個字段 code code 資料表 code create table users 提交到action後，分別通過兩種寫法，user name的...
設計原則 平衡簡單性與靈活性
分清設計的簡單性與靈活性有時並不容易，讓我們從乙個簡單的例子開始這一話題。假設我們需要編寫乙個函式，實現將 home.example.net user other.example.net 這樣格式的字串變為 home.example.net user other.example.net 即去除其中花...