收集更有效的專案需求資訊 （轉）
Rick O’Brien是安大略的Business Data Solutions的所有者。這是他第一次為TechRepublic寫文章。
幾年以前，一位商業財產管理公司的經理要求我把一些Microsoft Word製作的租賃檔案自動複製到WordPerfect 5.1，而WordPerfect 5.1在他的公司裡已經使用了很長的時間了。當我建議我們安排一次和終端使用者的會見來了解他們的想法和意見的時候，他說沒有必要。新的macros必須“完全和舊的那個一樣”地工作。
我還是在等待和這位經理的約見的時候同辦公室的員工進行了非正式的交流。他們都在問為什麼他們必須要學習新的軟體只為了做和以前完全一樣的事。
我儘可能禮貌地拒絕了這個工作。得不到終端使用者的支援和協作，新的自動文件專案在開始之前就註定要失敗。
使用者的參與在專案的需求收集階段是沒有價值的。使用者的想法和意見在設計和編碼階段能夠提供有價值的幫助。如果應用是基於工作流模型，並且在開發過程中得到使用者的幫助，使用者培訓就會容易得多。最後，使用者的接受能夠幫助保證完成的應用獲得成功。
你可以採用很多方法在應用開發階段收集使用者的意見：調查（通常是針對大型組織）；在站工作流觀察；一對一的使用者會見；集中團體、多使用者會議；或者綜合並靈活使用把上面所有的方法。
我將專注於一對一的使用者會見，以及如何從你和會見者會見的寶貴時間中獲得最大的價值。
收集使用者意見
在小型組織中，你可能能夠有時間和每個將要使用新應用的終端使用者接觸。在大型的組織中，這樣的想法是不切實際的，你將會滿足於接觸一個使用者的橫截面作為代表。在這兩種情況下，時間對於你和那些員工來說都是很寶貴的，所以你必須提高資料收集的質量。
做好準備
會見不是一場談話；它有自己的結構。調查使用的是“是/否”以及多項選擇，而會見更加開放，而且必須由一系列準備好的、深刻的問題組成的。準備好一個問題列表將使你能夠給使用者展示出取得的進展，比如：“我們已經開始幹了；只是還有兩個問題。”準備好一個問題列表，並根據這個列表發問將讓你能夠把比較困難的問題放在會見的後面進行。
對於使用者來說，會見可能是場痛苦的經歷，所以讓他們覺得自在是你需要解決的重要問題之一。一次，在我和一個有很少計算機技能的使用者會見中，她忽然脫口而出：“為什麼你要問我所有的這些問題，為什麼？”我向她保證說她的反饋非常有價值，它將被用來修改新的軟體以滿足她的需要。
誰是專家？
一種讓使用者在會見過程中感到自在的方法是：在會見過程中忘掉你自己，並且承認他們是他們所從事的工作中的各項任務和程式的專家。你在那裡是向他們學習的--而不是出於其他的目的。你將使用他們的經驗和建議來設計應用軟體，而這些應用軟體將幫助他們工作得更輕鬆，並提高工作效率。使用者不僅僅對他們目前的任務瞭解得非常清楚，當出現問題的時候，他們還能夠告訴你。有效的方法是，你可以這樣問他們：“我怎樣才能讓你的工作變得更加輕鬆/安全/容易？”
作為一個開發者，很容易陷入的一個陷阱就是按照開發者自己的主觀意識設計某個應用。我在早期的會見中總是問一些空洞的問題，比如螢幕應該是什麼顏色的，或者使用者覺得OK按鈕應該放在哪裡，或者選單裡應該包含哪些專案，等等。軟體設計應該圍繞著使用這個軟體的使用者需要完成的任務；否則，軟體就成為提高工作效率的障礙，而它自己也成為一種負擔。
恐懼的因素
這種情況可能你沒有遇到過，但是很多使用者可能會害怕他們在會見時給你的答案會導致他們被“電腦取代”，或者暴露出他們缺少計算機技能的事實，這可能會危機到他們的工作。你要向被你會見的人保證這並不是考驗他們，但是他們的反饋會幫助把這個新的或者是修改的應用盡可能地做得使用者友好一些，而且能夠憑直覺進行學習。提醒他們說他們的公司必須跟上競爭的形勢或者在競爭中領先才能夠生存下去。分享他們的知識和經驗能夠幫助他們的“團隊”贏得勝利。
但是在這裡要小心。你不能夠簡單地告訴被會見的人他們不會失去工作。新的應用可能會成為結構重組的一部分，而這樣的重組可能會最終導致有人丟掉工作。你不要讓自己告訴那些最後可能丟掉工作的人他們沒有什麼可擔心的。相反，你應該告訴被會見的人在軟體設計工作中付出努力的人會使他們自己成為新員工的專業培訓者和導師。
開放些
和調查的那種把答案簡單限定成是/否的問題不同，會見的問題應該是開放的，並且鼓勵使用者透過舉例子或者做假設來說明他們的想法。如果你想評估一下某人對於電腦的喜歡程度，諸如“你是否擁有一臺家庭電腦？”之類的問題只會帶來“是”或者“否”的回答。
更富於啟發性的問題應該是：“你什麼時候使用電腦--在家，工作中，在學校，或者在公共或者商業裝置上--你通常用它來幹什麼？”沒有電腦的使用者可能在圖書館，學校或者其他地方經常使用電腦。如果大部分使用者都說他們經常上網，你應該把你的介面設計得更加類似瀏覽器的風格。
沉默是金，用心傾聽吧
在一次平常的交談中，很可能會在一陣沉默之後開始投入。一次會見不是一次平常的交談。你的工作是在被會見的人講話的時候傾聽他/她的意見。
如果你問一個問題，然後接下來是一陣沉默，這可能意味著會見者正在仔細考慮答案。讓被會見的人首先打破沉默，如果他們喜歡，讓他們以後再回答。在等待回答的時候，注意你的身體語言和麵部表情。放鬆點，這樣也能夠幫助被會見的人放鬆。在思考問題的時候，人們經常向上看或者轉向某一邊。在他們陳述他們的答案的時候不要盯著他們。讓你自己看看你的會見記錄或者準備下一個問題。
有時候我會遇到一些會見人，他們在一陣長長的沉默之後，表示他們被某個問題難住了，或者他們不能給出某個答案。你只要簡單地告訴他們你將在以後再回到這個問題上來。有時候對於後一個問題的答案會幫助回答前一個問題。
避免誘導性的問題
在計劃和提出你的問題時，要避免“誘導性”的問題，這樣的問題會暗示出你期望得到什麼樣的答案。試試這樣的問題：“你認為在目前的資料錄入系統中最困難的問題是什麼？”，不要問：“目前的資料錄入系統很難使用，是這樣嗎？”這樣的問題。被會見的人會隱藏他們的本意，而給出一些他們認為你希望聽到的答案。
如果收集需求是為了替換一個陳舊的資料庫應用，而這個應用又恰巧是我自己設計的時候，我很難讓使用者能夠對舊系統提出建設性的批評。他們知道那個系統是我設計的，因此他們覺得似乎必須為它說一些好話，他們認為我在那裡是為了保護我早期的工作。使用者必須明白所有的軟體都有一個生命週期，而且最終當使用者需求有了變化或者發展的時候，都會被新的系統所取代。
如果你的任務是改進一個現有的系統，確保使用者們理解你需要知道如何保護現有軟體的好的功能，同時去掉或者改進一些不是太好的功能。
我錯過了什麼嗎？
在會見要結束之前，確認一下你記錄下的答案，檢查一下是否有先前漏掉的問題。“當我問###，你的回答是###。我的理解正確嗎？”在這個檢查過程之後，不要忘記可能是最重要的一個問題：“我有沒有遺漏掉什麼你想補充的內容嗎？”[@more@]
幾年以前，一位商業財產管理公司的經理要求我把一些Microsoft Word製作的租賃檔案自動複製到WordPerfect 5.1，而WordPerfect 5.1在他的公司裡已經使用了很長的時間了。當我建議我們安排一次和終端使用者的會見來了解他們的想法和意見的時候，他說沒有必要。新的macros必須“完全和舊的那個一樣”地工作。
我還是在等待和這位經理的約見的時候同辦公室的員工進行了非正式的交流。他們都在問為什麼他們必須要學習新的軟體只為了做和以前完全一樣的事。
我儘可能禮貌地拒絕了這個工作。得不到終端使用者的支援和協作，新的自動文件專案在開始之前就註定要失敗。
使用者的參與在專案的需求收集階段是沒有價值的。使用者的想法和意見在設計和編碼階段能夠提供有價值的幫助。如果應用是基於工作流模型，並且在開發過程中得到使用者的幫助，使用者培訓就會容易得多。最後，使用者的接受能夠幫助保證完成的應用獲得成功。
你可以採用很多方法在應用開發階段收集使用者的意見：調查（通常是針對大型組織）；在站工作流觀察；一對一的使用者會見；集中團體、多使用者會議；或者綜合並靈活使用把上面所有的方法。
我將專注於一對一的使用者會見，以及如何從你和會見者會見的寶貴時間中獲得最大的價值。
收集使用者意見
在小型組織中，你可能能夠有時間和每個將要使用新應用的終端使用者接觸。在大型的組織中，這樣的想法是不切實際的，你將會滿足於接觸一個使用者的橫截面作為代表。在這兩種情況下，時間對於你和那些員工來說都是很寶貴的，所以你必須提高資料收集的質量。
做好準備
會見不是一場談話；它有自己的結構。調查使用的是“是/否”以及多項選擇，而會見更加開放，而且必須由一系列準備好的、深刻的問題組成的。準備好一個問題列表將使你能夠給使用者展示出取得的進展，比如：“我們已經開始幹了；只是還有兩個問題。”準備好一個問題列表，並根據這個列表發問將讓你能夠把比較困難的問題放在會見的後面進行。
對於使用者來說，會見可能是場痛苦的經歷，所以讓他們覺得自在是你需要解決的重要問題之一。一次，在我和一個有很少計算機技能的使用者會見中，她忽然脫口而出：“為什麼你要問我所有的這些問題，為什麼？”我向她保證說她的反饋非常有價值，它將被用來修改新的軟體以滿足她的需要。
誰是專家？
一種讓使用者在會見過程中感到自在的方法是：在會見過程中忘掉你自己，並且承認他們是他們所從事的工作中的各項任務和程式的專家。你在那裡是向他們學習的--而不是出於其他的目的。你將使用他們的經驗和建議來設計應用軟體，而這些應用軟體將幫助他們工作得更輕鬆，並提高工作效率。使用者不僅僅對他們目前的任務瞭解得非常清楚，當出現問題的時候，他們還能夠告訴你。有效的方法是，你可以這樣問他們：“我怎樣才能讓你的工作變得更加輕鬆/安全/容易？”
作為一個開發者，很容易陷入的一個陷阱就是按照開發者自己的主觀意識設計某個應用。我在早期的會見中總是問一些空洞的問題，比如螢幕應該是什麼顏色的，或者使用者覺得OK按鈕應該放在哪裡，或者選單裡應該包含哪些專案，等等。軟體設計應該圍繞著使用這個軟體的使用者需要完成的任務；否則，軟體就成為提高工作效率的障礙，而它自己也成為一種負擔。
恐懼的因素
這種情況可能你沒有遇到過，但是很多使用者可能會害怕他們在會見時給你的答案會導致他們被“電腦取代”，或者暴露出他們缺少計算機技能的事實，這可能會危機到他們的工作。你要向被你會見的人保證這並不是考驗他們，但是他們的反饋會幫助把這個新的或者是修改的應用盡可能地做得使用者友好一些，而且能夠憑直覺進行學習。提醒他們說他們的公司必須跟上競爭的形勢或者在競爭中領先才能夠生存下去。分享他們的知識和經驗能夠幫助他們的“團隊”贏得勝利。
但是在這裡要小心。你不能夠簡單地告訴被會見的人他們不會失去工作。新的應用可能會成為結構重組的一部分，而這樣的重組可能會最終導致有人丟掉工作。你不要讓自己告訴那些最後可能丟掉工作的人他們沒有什麼可擔心的。相反，你應該告訴被會見的人在軟體設計工作中付出努力的人會使他們自己成為新員工的專業培訓者和導師。
開放些
和調查的那種把答案簡單限定成是/否的問題不同，會見的問題應該是開放的，並且鼓勵使用者透過舉例子或者做假設來說明他們的想法。如果你想評估一下某人對於電腦的喜歡程度，諸如“你是否擁有一臺家庭電腦？”之類的問題只會帶來“是”或者“否”的回答。
更富於啟發性的問題應該是：“你什麼時候使用電腦--在家，工作中，在學校，或者在公共或者商業裝置上--你通常用它來幹什麼？”沒有電腦的使用者可能在圖書館，學校或者其他地方經常使用電腦。如果大部分使用者都說他們經常上網，你應該把你的介面設計得更加類似瀏覽器的風格。
沉默是金，用心傾聽吧
在一次平常的交談中，很可能會在一陣沉默之後開始投入。一次會見不是一次平常的交談。你的工作是在被會見的人講話的時候傾聽他/她的意見。
如果你問一個問題，然後接下來是一陣沉默，這可能意味著會見者正在仔細考慮答案。讓被會見的人首先打破沉默，如果他們喜歡，讓他們以後再回答。在等待回答的時候，注意你的身體語言和麵部表情。放鬆點，這樣也能夠幫助被會見的人放鬆。在思考問題的時候，人們經常向上看或者轉向某一邊。在他們陳述他們的答案的時候不要盯著他們。讓你自己看看你的會見記錄或者準備下一個問題。
有時候我會遇到一些會見人，他們在一陣長長的沉默之後，表示他們被某個問題難住了，或者他們不能給出某個答案。你只要簡單地告訴他們你將在以後再回到這個問題上來。有時候對於後一個問題的答案會幫助回答前一個問題。
避免誘導性的問題
在計劃和提出你的問題時，要避免“誘導性”的問題，這樣的問題會暗示出你期望得到什麼樣的答案。試試這樣的問題：“你認為在目前的資料錄入系統中最困難的問題是什麼？”，不要問：“目前的資料錄入系統很難使用，是這樣嗎？”這樣的問題。被會見的人會隱藏他們的本意，而給出一些他們認為你希望聽到的答案。
如果收集需求是為了替換一個陳舊的資料庫應用，而這個應用又恰巧是我自己設計的時候，我很難讓使用者能夠對舊系統提出建設性的批評。他們知道那個系統是我設計的，因此他們覺得似乎必須為它說一些好話，他們認為我在那裡是為了保護我早期的工作。使用者必須明白所有的軟體都有一個生命週期，而且最終當使用者需求有了變化或者發展的時候，都會被新的系統所取代。
如果你的任務是改進一個現有的系統，確保使用者們理解你需要知道如何保護現有軟體的好的功能，同時去掉或者改進一些不是太好的功能。
我錯過了什麼嗎？
在會見要結束之前，確認一下你記錄下的答案，檢查一下是否有先前漏掉的問題。“當我問###，你的回答是###。我的理解正確嗎？”在這個檢查過程之後，不要忘記可能是最重要的一個問題：“我有沒有遺漏掉什麼你想補充的內容嗎？”[@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839396/viewspace-937773/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Node專案之需求收集平臺
- 有效的專案管理(轉)專案管理
- 專案經理如何應對專案需求變更？
- 專案需求變更得不到有效控制所帶來的後果（轉）
- 專案管理的有效執行（轉）專案管理
- 專案辦公室——有效管理專案的金鑰匙（轉）
- 需求變更，敏捷專案應如何做？敏捷
- 專案管理中的需求變更分析和解決之道專案管理
- 讓專案管理更有效 （轉）專案管理
- 讓專案管理更有效(轉)專案管理
- 構建有效的專案團隊（轉）
- 如何進行有效的專案控制(轉)
- 如何有效的控制專案的進度(轉)
- 如何確定專案的工作需求(轉)
- 導致專案需求蔓延的原因 應對專案蔓延的資訊化手段
- 在開發專案中進行有效的專案管理（轉）專案管理
- 專案經理該如何面對頻繁的需求變更?
- Web專案經理手冊之需求變更管理Web
- 淺談如何實行有效的專案管理(轉)專案管理
- 專案管理團隊建設的有效工具（轉）專案管理
- 沒有合格的專案經理就不會有有效的專案管理（轉）專案管理
- 【分享貼】需求變更、專案延誤，專案經理應該如何應對？
- 專案中如何更好的控制客戶需求(轉)
- 需求可以變 但專案不能亂(轉)
- 軟體專案需求分析總結（轉）
- 【轉】AIX snap資訊的收集步驟AI
- 專案範圍變更管理（轉）
- 軟體專案需求分析的20條法則（轉）
- 快速軟體開發專案中的有效溝通（轉）
- 專案管理過程之變更控制（轉）專案管理
- 專案管理過程之變更控制 （轉）專案管理
- iOS好專案收集iOS
- 專案總結【收集】
- 需求調研分析中的專案干係人概念（轉）
- 資訊系統專案的售前管理（轉）
- 資訊化專案的成功源泉：交付+成本（轉）
- 資訊化專案監理的內容（轉）
- 如何有效控制專案成本？