用戶懂業務但不懂軟件，甚至于對于整個業務結構單個用戶也不完全清楚，相反隨著項目的進行開發者反而會更加了解商務邏輯與未來的趨勢。不過開發者眼中的系統邏輯總是過于完善和理想，這必將導致設計與開發常常走向極端，尤其是面對頭腦簡單或膽小的用戶時更加糟糕。比如用戶處于較高的領導層時，他通常不關心細節只是想要盡快看到結果，所以當你問要不要考慮XXX時他總是會說不用考慮，其實他是懶得解答你各種分支情況。相反如果用戶是一個最低層的領導時，他擔心將來承擔一定責任便會非常留意系統的擴展，因此你在尋問以后會不會有某種業務變動及延伸時，他總是會說“是”唯恐漏掉任何東西。那么最終結果是什么呢？前者有了變化還是會通知你進行相應修改，而后者聽取上級意見后也同樣會通知你系統太復雜不好用。于是程序員總是處在一個弱勢的地位，其實多數項目的加班不過是一種毫無意義的徒勞或重復，工作總是不理想，面對如此客戶態度可想而知，于是相應的連鎖反應像多米諾牌一樣相互觸發。這樣的壓力之下就會有兩種極端，一是給出一個裸體般的系統雛形，要什么加什么，提什么改什么，最終需求爆炸無法控制；另一種則是給出一個徹底參數化的系統，什么都讓用戶配置，甚至包括一些邏輯在內，如此使得系統異常復雜且配置內容龐大難于維護，結果用戶和開發人員都迷失在其中。
記得老一輩人說過我們應當要實事求是，現在真是深有體會，一勞永逸或徹底解決問題的想法在軟件開發中太可怕了，而走極端則根是致命的。軟件開發尤其是做項目，不可以總是太過考慮擴展與靈活，否則只能是一步步走地慢性自殺。對于客戶來講功能強大需要建立在易用的基礎上，特別是對于目前我們國內的領導，他們開始會認同強大的功能，可一旦實施就必然抱怨嫌麻煩。在系統實施之前，要有完整的全方位的文檔報告，什么多級的權限控制，什么強勁的安全措施，什么流行的技術內容，什么未來的擴展預測，什么多皮膚的界面，什么并發處理等等能上得都上，還要搞制度化的管理層次和級別，一個字系統要“酷”，向上級匯報時的口號是：不求最好但求最大。當系統實施正式上線之后情況就不同了，首先要取消制度，什么登錄，什么安全設置，什么審核限定，什么警告提示等等能去的都去掉，還要把所有的操作移交給下面人，一個字就是要“簡”，對開發者反饋時強調：不求最強但求最簡。這樣一個項目做下來怎么也瘋幾個年輕程序員，老一點的早麻木了，你還別抱怨，這就是職業特點。所以面對需求一定要冷靜，一定要慎重，千萬別太把用戶的話全放在心上，畢竟你的工程你做主，用技術術語和開發周期來敷衍一下還是很有必要的。
也許有人不理解為什么極端靈活反而不好，道理很清楚就是太接近專業了，但用戶并不專業。就拿多皮膚來說，有幾個客戶在系統正式運行后還整天調樣子，何況沒有幾個用戶有這能力。有人覺得適應用戶的需求變化確用不著重編譯代碼是很酷的事，但很多情況是值不值得為一個幾年后才可能變得東西做個界面來維護參數。還有個關鍵的問題，當參數太多時，你根本就找不到要改得那個，找到時也許已經忘了如何改，而為他們寫幫助文檔又是多么怕的事。當軟件做得極端靈活時它的參數配置本身就可能已經成為了一種腳本語言，用程序語言經過一系列得開發卻得到另一種語言，想想就是一種多么可笑的事。但實際上不管你如何靈活也無法適應所有變化，因為程序語言本身就有特定的范圍。很多組件和控件好用正是因為它們有自己的領域和限制，使得我們節省了精力。所以，有時硬性地忽略或限定一些情況是相當有益得，萬能鑰匙可以打開很多鎖但絕大多數人還是寧愿帶著甚至上百把的普通鑰匙。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
