談談使用者和需求
柳鯤鵬2007-7-27
關鍵字：使用者 需求
簡介：使用者自己也不知道自己需要什麼，也不知道自己的需求。使用者提的意見，可以說絕大多數是沒有意義的；而使用者的需求，必須由你詳細考察使用者的工作過程才能搞清楚。軟體要做好，才有資格聽取使用者意見。別把使用者反映的產品的問題和缺陷當作使用者需求。
在軟體工作中，經常聽到有些人打著使用者的幌子說：使用者希望這樣，使用者才不管你怎麼實現的，你這樣不符合使用者的習慣……似乎他接觸了多少使用者、就了解使用者、還接受了使用者委託替使用者代言一樣。其實這根本就是胡扯！他跟使用者沒有任何關係，他僅僅代表他自己的看法。
什麼是使用者？這個詞實際上比較模糊，比如使用者、試用者、消費者（購買者）、客戶、採購者、潛在消費者等幾種說法。大體上可以分為個人和集體、試用者和消費者兩種情況。而軟體，可為分為專用軟體和通用軟體兩大類。專用軟體，是公司花錢專門定製的。而通用軟體，就是開發乙個產品，面對廣大使用者的。這之間的區別，在於專用軟體是根據使用者要求修改，版本變化較為頻繁；而乙個通用軟體一般不會根據所謂使用者需求臨時出乙個版本。就我們的廣義的看法，凡是使用者的建議、意見，都是所謂的需求。
還要注意的是，使用者本身是乙個泛指。所以可以繞口令的說，你碰到的使用者只是使用者個體，他的意見僅僅是自己的看法，千萬不能武斷的認為這是廣大使用者的心聲。經常可以碰到衝突情況，這個使用者說這樣好，另外乙個使用者則認為這樣不利於其工作。如果你要沒有搞清楚，最後什麼也做不好。
但使用者的意見本身，也是多種多樣的。一類是功能缺失性的，比如跟別的軟體一比，沒某個功能自然覺得亐了；習慣性的，改變原來的做法不適應，於是就要抱怨幾句；改進性的，某些使用者自認自己發現了什麼秘密，悄悄的告訴你（可以說絕大多數都是沒用的）；最後一類是錯誤，你的軟體明明做得很差缺陷很多就自認很好，別人不罵你罵誰？還覺得這是使用者需求？你不丟臉啊？據本人所知，大多數所謂需求都是這種情況——但你為什麼不把產品先做好？僅僅是為了向領導邀功？
本人所在的公司安排了一次下點安裝軟體，不少人回來說使用者抱怨某個功能不好。一下子整個公司急三火四的按照所謂「使用者需求」改了，可再次安裝並沒有讓人滿意，回來的人說「人家要的根本就不是這個東西」。是哪個東西？調查了一番，不了了之，因為沒有人說得清楚。
好了，假設你真的有機會面對使用者了，聆聽使用者的需求了。這時你必須明白，使用者要求不知道自己想要什麼，不清楚自己想做什麼。使用者唯一知道的是，你的軟體，應該讓他很方便的完成工作,除此之外他什麼也不知道，也不清楚。你必須卻了解、體驗他的工作過程，搞明白工作中的各個細節，尤其要追究使用者萌發需求的起因和過程。這時，你僅僅了解了工作，而軟體功能要做成什麼樣子，誰也不知道。你又要自己去分析、設計操作介面和過程，並反覆推敲每個細節的方便性。如果使用者覺得湊合了，這才算把使用者的需求了解清楚了。而這個過程，所謂使用者需求，僅僅是一句話而已，僅僅是使用者的朦朧感覺而已，其他的工作都是你自己的分析。
舉兩個例子。每次windows的功能改進，難道是某個使用者提的意見嗎？從來沒有聽說有這樣聰明的使用者；又如當年office xp出來的時候，改變了以前在乙個word裡面容納所有檔案的方式（mdi），改為每個檔案在工作列上乙個按鈕，剛剛出來的時候「使用者」一片抱怨，結果沒有多久就發現這樣實在好用，一起閉嘴了。
那麼什麼是使用者？使用者是個體，僅僅是表達自己的意見，這不是什麼需求，沒有研究之前你不能當真。
使用者自己也不明白自己的需求是什麼。你面對使用者，必須搞清楚細節。
使用者的意見，是需要仔細分選的。除了缺陷，幾乎所有的意見都沒有價值，因為他們並不清楚自己在說什麼。
軟體要做好，才有資格聽取使用者意見。別把使用者反映的產品的問題和缺陷當作使用者需求。
談談專案和需求
你是否有過你的專案注定要失敗的感覺，也許你現在可以建議結束它，並且為出資人省下一些錢。1.挖掘需求的時候，要找出使用者為何做特定事的原因 而不只是他們目前做這件事的方式。你的開發必須解決他們的商業問題，而不只是滿足他們陳述的需求。2.成為產品的使用者。與使用者一樣工作，一樣思考。我們很容易被吸進 只...
專案管理之需求調研感悟
乙個專案中需求調研的充分與否是專案日後成敗的關鍵要素之一，這一點我想沒有哪位專案經理不認同吧？不過咱說的需求調研可不只是拿張紙記記客戶說什麼就完了，調研顧名思義就是調查和研究客戶的想法，我感覺應從以下幾個步驟入手 1 客戶想要什麼？2 要這幹什麼？3 為什麼這麼想？4 會不會有別的想法？這裡也說乙個...
談談用UML來做需求管理
今天在看 agile software development 讀到附錄中關於uml的介紹，不禁慨嘆 我以前在uml的時候怎麼就那麼的蹩腳呢，特別是在描述需求的時候。我剛剛設計了乙個專案，一開頭就碰到乙個頭疼的問題 需求分析。我想取消我們以前那種繁雜的用文字描述的文件方法，採用uml的圖形化來表示。...