横看成岭侧成峰
橫看成嶺側成峰
放大軟件的職能和概念對于軟件尤其是大型系統的需求管理是極其不智的，可嘆的是有些軟件廠商夸大軟件功能或玩轉若干概念，目的是為了贏得客戶的青睞，而這后果也就造成了惡性循環和劣幣驅逐良幣現象的發生。軟件的職能受制于硬件性能，也回歸到一點：軟件最終還需要依賴于機器去執行指令；盡管軟件經過軟件工程、算法等加工可以對機器性能和智能放大到機器所能承受的極限，但機器終究無法與人類目前所要求想符合。實際上，在人類科技發展過程中，因為實際需求去設計開發了某種工具，然后工具的使用又促使我們在實際應用中去改良工具及其使用工具的方式方法，這種相互作用和辨證統一關系同樣也體現在人類與計算機上。
計算機是一種工具，但怎么理解計算機呢？懂計算機，是否意味著你懂硬件、懂軟件、懂網絡、懂各類應用軟件的操作、懂系統集成、懂人工智能、懂計算數學嗎？計算機和IT等同嗎？這些概念沒有去一一辨析的必要，但肯定要理解任何一套軟件和人一樣都只能服務于其特定職能范圍內。正如客戶認為從事軟件業的人應該懂與IT相關的任何事，客戶對軟件的需求往往也陷入軟件無所不能的看法，可以完全替代或幫助客戶在工作中解決大部分問題，這對需求管理帶來致命性問題。但又不能否認需求變更的必要，因為隨著客戶見到更多有形軟件的運行并結合本身實際工作，肯定會提出更深入的需求，對于需求變更在軟件工程領域有很多過程來滿足。可怕的是這些需求超越了軟件或機器作為一種工具的本身職能。
不可否認只有超越極限的要求才能促進技術革命性跳躍，如web2.0創新性，但也依賴于硬件的跨越。本文這里談的需求管理側重于兩點：每個軟件有自己職能范圍不能無限制要求其擴大職能；軟件僅是工具，工具只能部分替代或幫助人的工作。而這兩點統歸一點就在于：如何有效進行需求管理，抑制需求的無限擴大化。下面有兩個例子，其中一個是轉載的，另一個是筆者親身經歷的需求調研并在需求管理中遇到的。
============================轉載例子-開始======================================
某日，老師在課堂上想考考學生們的智商，就問一個男孩:“樹上有十只鳥，開槍打死一只，還剩幾只？”
男孩反問:“是無聲槍么？”
“不是。”
“槍聲有多大？”
“80~100分貝。”
“那就是說會震的耳朵疼？”
“是。”
“在這個城市里打鳥犯不犯法？”
“不犯。”
“您確定那只鳥真的被打死啦？”
“確定。”老師已經不耐煩了，”拜托，你告訴我還剩幾只就行了，OK？”
“OK。鳥里有沒有聾子？”
“沒有。”
“有沒有關在籠子里的？”
“沒有。”
“邊上還有沒有其他的樹，樹上還有沒有其他鳥？”
“沒有。”
“方圓十里呢？”
“就這么一棵樹!”
“有沒有殘疾或餓的飛不動的鳥？”
“沒有，都身體倍棒。”
“算不算懷孕肚子里的小鳥？”
“都是公的。”
“都不可能懷孕？”
“………，決不可能。”
“打鳥的人眼里有沒有花？保證是十只？”
“沒有花，就十只。”
老師腦門上的汗已經流下來了，下課鈴響起，但男孩仍繼續問:“有沒有傻的不怕死的？”
“都怕死。”
“有沒有因為情侶被打中，自己留下來的？”
“笨蛋，之前不是說都是公的嘛!”
“同志可不可以啊!”
“………，性取向都很正常!”
“會不會一槍打死兩只？”
“不會。”
“一槍打死三只呢？”
“不會。”
“四只呢？”
“更不會!”
“五只呢？”
“絕對不會!!!”
“那六只總有可能吧？”
“除非你他媽的是豬生的才有可能!”
“…好吧，那么所有的鳥都可以自由活動么？”
“完全可以。”
“它們受到驚嚇起飛時會不會驚慌失措而互相撞上？”
“不會，每只鳥都裝有衛星導航系統，而且可以自動飛行。”
“恩，如果您的回答沒有騙人，”學生滿懷信心的回答，“打死的鳥要是掛在樹上沒掉下來，那么就剩一只，如果掉下來，就一只不剩。”
老師當即倒!
============================轉載例子-結束======================================
這個笑話，不少人會認為小朋友是需求調研的最佳人選，而本文轉載的文章也正是以這樣出發點分析軟件失敗的因素正在于需求不明確，客戶對需求的變更等等。筆者對于需求調研有深刻的理解，調研的目的就在于深入了解客戶的業務和工作并收集資料，如小孩般打破砂鍋的方式一定程度上是比較到位的調研方式，考慮到問題的方方面面，與客戶確認各個具體可能性，這避免后期需求管理中客戶更多的糾纏，同時又避免想當然的作法。在需求調研中，往往摘取片面的客戶信息然后用技術的角度去考慮實現，想當然地認為應該是這樣，卻與客戶實際或總體上客戶需求并不協調。
如果把小朋友作為系統分析人員去做調研，可以定位為：把簡單問題復雜化，但卻是必要的，絕對是橫看成嶺了，綿延但可實現。如果把這個笑話中的小朋友看作是客戶，客戶無休止地對一個需求的各種可能進行擴大化提問，那么絕對是把側看成峰了，太陡峭了，寒！下面是筆者親歷的與客戶需求互動過程。
=========================自設例子-開始=========================================
需求確認環節，需求分析人員：對于角色這部分，你確信只要一種，并且具有所有權限就可以嗎？
客戶：也不清楚，系統能給我用來發短信就行。
分析人員：所有功能都給一種角色，沒有其他角色的要求嗎？如有些角色進來只能發送短信不能提取報表。
客戶：這個目前還不知道，現在只要滿足能發送短信就可以了！那到時候能不能讓我自己設置角色并分配可操作功能的權限呢？
分析人員：可以啊！那你的需求就是建立可配置角色和權限！
客戶：是，那能不能導入角色和權限啊？比如有一批用戶現在要讓他們用系統，我不想一個一個配，直接導入！
分析人員：可以，不過要按照我們設定格式來編寫然后導入！
客戶：那能不能導出你們格式，然后我按照格式輸入？另外我想如果數據太多，尤其是如果分不同用戶組別的，能不能把報表合并后再導入？
分析人員：你的意思不同組別的人把按照格式中名單給系統，系統能合并一起，然后再由你一次導入嗎？
客戶：是，我總不能一個組別導一次，另外以后要是修改的話，批量導入時也是一個組別導入一次不是很麻煩嗎？
分析人員：這個？？可以吧，不過還是需要你把各組的報表導入我們才能合并，如果系統不能獲取這些報表是很難合并的。
客戶：系統應該會自己找吧？
分析人員：那這樣，你在本地建一個獨立文件夾，然后把報表都放進去，然后你只要給系統文件夾地址，系統就自動合并然后導入到系統中。
客戶：可以，那么權限上能不能有些人給報表查詢？有些人給報表提取呢？
分析人員：就是說有些角色可以進行報表查詢，有些角色可以進行報表提取嗎？
客戶：是！
分析人員：那你配置這些角色就可以，系統中我們把報表提取和報表查詢分為兩種不同功能操作權限就可以了！
客戶：要我配置角色啊！能不能固定這些角色，我給這個人這種角色就行了？
分析人員：可是你剛才的意思是角色可配置，如果這樣，那么請你給出那些角色是要固定以及可操作的功能權限？
客戶：我現在也不知道啊！就不能不用我配置就指定某人可不可以用這些功能嗎？
分析人員：分配好角色后然后還可以修改具體個人權限，你指的是用我們內部預先固化好的角色，然后你可以修改個人權限而不用重新配置角色，對嗎？
客戶：應該是的！
分析人員：這個不好控制！因為角色是從屬的，如果個人可以設置其權限，那角色就沒意義了！直接為個人分配權限就可以！
客戶：那就直接給個人分配權限！
分析人員：那還要支持導入嗎？如果可以為個人修改權限，導入不具有意義，因為具體到個人了！
客戶：還是要導入，如果用戶多呢？
僵局中……，分析人員暗中哭泣！
=========================自設例子-結束=========================================
這段對話暴露中客戶對需求的兩個意向：減輕其工作，盡可能讓軟件來實現；需求帶有想當然，認為這樣就是能實現！這個例子此處的對話多少有筆者模擬意思，但當時情景的對話主要內容在這里是真實重現。客戶一般對于其業務范圍內的軟件需求有種模糊的認識，剛開始一般都是朦朧，一旦軟件分析人員害怕到時候需求變更而進行詳細調研時，客戶會越想越多，然后開始漫無目的地擴大需求，對軟件的功能提出非軟件本身或非該系統本身能實現或應當實現的范疇。
軟件的需求首先就是要界定這一套軟件的邊界，就是這個系統能完成什么不能完成什么不去完成什么？無限制擴大軟件的功能范疇對于軟件需求管理是災難性的。當前為了客戶是上帝這樣一個理念，軟件越做越大，附帶的軟件小工具越來越龐大，也幸虧軟件工程的推出，使得軟件可以不斷膨脹。
面對客戶對需求的無限擴大化需求的趨勢，該當如何為之呢？換到當前呼叫中心的軟件開發和維護環境中，明顯面臨兩方面的需求無限化問題：內部系統內部用戶；呼叫中心整體方案外包用戶。為了贏得客戶，在不能對客戶說“不”的前提下，去界定系統邊界并做好需求管理，筆者確實頭痛！對此，筆者認為軟件分析人員應該有一下幾個把握：
軟件邊界還是要定，并且與客戶明確；
需求管理中，盡量引導客戶去思考系統核心功能；
設計上，重點把握支持可能性需求變更的思路。
實際上，在與客戶交流中，有些對軟件熟悉一點的人經常會表達一種他提出的需求變更很容易實現的觀點，這很可怕，對軟件開發人員來說是毀滅性的！任何一個需求變更，都可能引起連鎖性的修改甚至結構性的變動，但客戶不會意識到這點。橫看成嶺側成峰，用在此處最恰當了。因此筆者對于系統分析人員的需求管理能力非常看重，并著力于從開發到設計再到分析，到了分析階段就要帶著技術視角去思考同時又不能含技術成分去做需求，看似矛盾在實際軟件需求分析中是很實在的。
? ??????????????????????????2008年8月1日 星期五
總結
- 上一篇： 软件作坊模式工件应用论
- 下一篇： 老气横秋