橫看成嶺側成峰

http://blog.csdn.net/fjssharpsword/article/details/2753777

 

放大軟體的職能和概念對於軟體尤其是大型系統的需求管理是極其不智的，可歎的是有些軟體廠商誇大軟體功能或玩轉若干概念，目的是為了贏得客戶的青睞，而這後果也就造成了惡性循環和劣幣驅逐良幣現象的發生。軟體的職能受制於硬體性能，也回歸到一點：軟體最終還需要依賴於機器去執行指令；儘管軟體經過軟體工程、演算法等加工可以對機器性能和智慧放大到機器所能承受的極限，但機器終究無法與人類目前所要求想符合。實際上，在人類科技發展過程中，因為實際需求去設計開發了某種工具，然後工具的使用又促使我們在實際應用中去改良工具及其使用工具的方式方法，這種相互作用和辨證統一關係同樣也體現在人類與電腦上。

 

電腦是一種工具，但怎麼理解電腦呢？懂電腦，是否意味著你懂硬體、懂軟體、懂網路、懂各類應用軟體的操作、懂系統集成、懂人工智慧、懂計算數學嗎？電腦和IT等同嗎？這些概念沒有去一一辨析的必要，但肯定要理解任何一套軟體和人一樣都只能服務於其特定職能範圍內。正如客戶認為從事軟體業的人應該懂與IT相關的任何事，客戶對軟體的需求往往也陷入軟體無所不能的看法，可以完全替代或説明客戶在工作中解決大部分問題，這對需求管理帶來致命性問題。但又不能否認需求變更的必要，因為隨著客戶見到更多有形軟體的運行並結合本身實際工作，肯定會提出更深入的需求，對於需求變更在軟體工程領域有很多過程來滿足。可怕的是這些需求超越了軟體或機器作為一種工具的本身職能。

 

不可否認只有超越極限的要求才能促進技術革命性跳躍，如web2.0創新性，但也依賴於硬體的跨越。本文這裡談的需求管理側重於兩點：每個軟體有自己職能範圍不能無限制要求其擴大職能；軟體僅是工具，工具只能部分替代或説明人的工作。而這兩點統歸一點就在於：如何有效進行需求管理，抑制需求的無限擴大化。下面有兩個例子，其中一個是轉載的，另一個是筆者親身經歷的需求調研並在需求管理中遇到的。

 

============================轉載例子-開始======================================

 

某日，老師在課堂上想考考學生們的智商，就問一個男孩:“樹上有十隻鳥，開槍打死一隻，還剩幾隻？”

 

男孩反問:“是無聲槍麼？”

 

“不是。”

 

“槍聲有多大？”

 

“80~100分貝。”

 

“那就是說會震的耳朵疼？”

 

“是。”

 

“在這個城市裡打鳥犯不犯法？”

 

“不犯。”

 

“您確定那只鳥真的被打死啦？”

 

“確定。”老師已經不耐煩了，”拜託，你告訴我還剩幾隻就行了，OK？”

 

“OK。鳥裡有沒有聾子？”

 

“沒有。”

 

“有沒有關在籠子裡的？”

“沒有。”

 

“邊上還有沒有其他的樹，樹上還有沒有其他鳥？”

 

“沒有。”

 

“方圓十裡呢？”

 

“就這麼一棵樹!”

 

“有沒有殘疾或餓的飛不動的鳥？”

 

“沒有，都身體倍棒。”

 

“算不算懷孕肚子裡的小鳥？”

 

“都是公的。”

 

“都不可能懷孕？”

 

“………，決不可能。”

 

“打鳥的人眼裡有沒有花？保證是十隻？”

 

“沒有花，就十隻。”

 

老師腦門上的汗已經流下來了，下課鈴響起，但男孩仍繼續問:“有沒有傻的不怕死的？”

 

“都怕死。”

 

“有沒有因為情侶被打中，自己留下來的？”

 

“笨蛋，之前不是說都是公的嘛!”

 

“同志可不可以啊!”

 

“………，性取向都很正常!”

 

“會不會一槍打死兩隻？”

 

“不會。”

 

“一槍打死三隻呢？”

 

“不會。”

 

“四隻呢？”

 

“更不會!”

 

“五隻呢？”

 

“絕對不會!!!”

 

“那六隻總有可能吧？”

 

“除非你他媽的是豬生的才有可能!”

 

“…好吧，那麼所有的鳥都可以自由活動麼？”

 

“完全可以。”

 

“它們受到驚嚇起飛時會不會驚慌失措而互相撞上？”

 

“不會，每只鳥都裝有衛星導航系統，而且可以自動飛行。”

 

“恩，如果您的回答沒有騙人，”學生滿懷信心的回答，“打死的鳥要是掛在樹上沒掉下來，那麼就剩一隻，如果掉下來，就一隻不剩。”

 

老師當即倒!

 

============================轉載例子-結束======================================

 

這個笑話，不少人會認為小朋友是需求調研的最佳人選，而本文轉載的文章也正是以這樣出發點分析軟體失敗的因素正在於需求不明確，客戶對需求的變更等等。筆者對於需求調研有深刻的理解，調研的目的就在於深入瞭解客戶的業務和工作並收集資料，如小孩般打破砂鍋的方式一定程度上是比較到位的調研方式，考慮到問題的方方面面，與客戶確認各個具體可能性，這避免後期需求管理中客戶更多的糾纏，同時又避免想當然的作法。在需求調研中，往往摘取片面的客戶資訊然後用技術的角度去考慮實現，想當然地認為應該是這樣，卻與客戶實際或總體上客戶需求並不協調。

 

如果把小朋友作為系統分析人員去做調研，可以定位為：把簡單問題複雜化，但卻是必要的，絕對是橫看成嶺了，綿延但可實現。如果把這個笑話中的小朋友看作是客戶，客戶無休止地對一個需求的各種可能進行擴大化提問，那麼絕對是把側看成峰了，太陡峭了，寒！下面是筆者親歷的與客戶需求互動過程。

 

=========================自設例子-開始=========================================

 

需求確認環節，需求分析人員：對於角色這部分，你確信只要一種，並且具有所有權限就可以嗎？

 

客戶：也不清楚，系統能給我用來發短信就行。

 

分析人員：所有功能都給一種角色，沒有其他角色的要求嗎？如有些角色進來只能發送短信不能提取報表。

 

客戶：這個目前還不知道，現在只要滿足能發送短信就可以了！那到時候能不能讓我自己設置角色並分配可操作功能的許可權呢？

 

分析人員：可以啊！那你的需求就是建立可配置角色和許可權！

 

客戶：是，那能不能導入角色和許可權啊？比如有一批使用者現在要讓他們用系統，我不想一個一個配，直接導入！

 

分析人員：可以，不過要按照我們設定格式來編寫然後導入！

 

客戶：那能不能匯出你們格式，然後我按照格式輸入？另外我想如果資料太多，尤其是如果分不同用戶組別的，能不能把報表合併後再導入？

 

分析人員：你的意思不同組別的人把按照格式中名單給系統，系統能合併一起，然後再由你一次導入嗎？

 

客戶：是，我總不能一個組別導一次，另外以後要是修改的話，批量導入時也是一個組別導入一次不是很麻煩嗎？

 

分析人員：這個？？可以吧，不過還是需要你把各組的報表導入我們才能合併，如果系統不能獲取這些報表是很難合併的。

 

客戶：系統應該會自己找吧？

 

分析人員：那這樣，你在本地建一個獨立資料夾，然後把報表都放進去，然後你只要給系統資料夾位址，系統就自動合併然後導入到系統中。

 

客戶：可以，那麼許可權上能不能有些人給報表查詢？有些人給報表提取呢？

 

分析人員：就是說有些角色可以進行報表查詢，有些角色可以進行報表提取嗎？

 

客戶：是！

 

分析人員：那你配置這些角色就可以，系統中我們把報表提取和報表查詢分為兩種不同功能操作許可權就可以了！

 

客戶：要我配置角色啊！能不能固定這些角色，我給這個人這種角色就行了？

 

分析人員：可是你剛才的意思是角色可配置，如果這樣，那麼請你給出那些角色是要固定以及可操作的功能許可權？

 

客戶：我現在也不知道啊！就不能不用我配置就指定某人可不可以用這些功能嗎？

 

分析人員：分配好角色後然後還可以修改具體個人許可權，你指的是用我們內部預先固化好的角色，然後你可以修改個人許可權而不用重新配置角色，對嗎？

 

客戶：應該是的！

 

分析人員：這個不好控制！因為角色是從屬的，如果個人可以設置其許可權，那角色就沒意義了！直接為個人分配許可權就可以！

 

客戶：那就直接給個人分配許可權！

 

分析人員：那還要支持導入嗎？如果可以為個人修改許可權，導入不具有意義，因為具體到個人了！

 

客戶：還是要導入，如果用戶多呢？

 

僵局中……，分析人員暗中哭泣！

 

=========================自設例子-結束=========================================

 

這段對話暴露中客戶對需求的兩個意向：減輕其工作，盡可能讓軟體來實現；需求帶有想當然，認為這樣就是能實現！這個例子此處的對話多少有筆者類比意思，但當時情景的對話主要內容在這裡是真實重現。客戶一般對於其業務範圍內的軟體需求有種模糊的認識，剛開始一般都是朦朧，一旦軟體分析人員害怕到時候需求變更而進行詳細調研時，客戶會越想越多，然後開始漫無目的地擴大需求，對軟體的功能提出非軟體本身或非該系統本身能實現或應當實現的範疇。

 

軟體的需求首先就是要界定這一套軟體的邊界，就是這個系統能完成什麼不能完成什麼不去完成什麼？無限制擴大軟體的功能範疇對於軟體需求管理是災難性的。當前為了客戶是上帝這樣一個理念，軟體越做越大，附帶的軟體小工具越來越龐大，也幸虧軟體工程的推出，使得軟體可以不斷膨脹。

 

面對客戶對需求的無限擴大化需求的趨勢，該當如何為之呢？換到當前呼叫中心的軟體發展和維護環境中，明顯面臨兩方面的需求無限化問題：內部系統內部使用者；呼叫中心整體方案外包用戶。為了贏得客戶，在不能對客戶說“不”的前提下，去界定系統邊界並做好需求管理，筆者確實頭痛！對此，筆者認為軟體分析人員應該有一下幾個把握：

 

軟體邊界還是要定，並且與客戶明確；

 

需求管理中，儘量引導客戶去思考系統核心功能；

 

設計上，重點把握支持可能性需求變更的思路。

 

實際上，在與客戶交流中，有些對軟體熟悉一點的人經常會表達一種他提出的需求變更很容易實現的觀點，這很可怕，對軟體發展人員來說是毀滅性的！任何一個需求變更，都可能引起連鎖性的修改甚至結構性的變動，但客戶不會意識到這點。橫看成嶺側成峰，用在此處最恰當了。因此筆者對於系統分析人員的需求管理能力非常看重，並著力于從開發到設計再到分析，到了分析階段就要帶著技術視角去思考同時又不能含技術成分去做需求，看似矛盾在實際軟體需求分析中是很實在的。