模板
教程
環境
性能
功能
管理
項目調研經驗談
1.把二期項目當作一個新項目來做調研，避免需求細節遺漏。在調研的初期我們曾經有過疑慮，這是一個二期的項目，那么調研的內容是否只針對二期的新需求，對需求內容二期和一期一致的部分就不必調研了?
經過討論我們還是決定把二期項目當作一個新項目來做調研，即使二期和一期需求內容一致，我們也在調研會上討論，并記錄在調研筆記及以后的需求文檔上。這樣的好處是最大限度地避免了需求細節的遺漏。在現場調研時，發現有不少地方原來以為是二期不必修改的，經過討論后發現還是需要修改。（往往危險的需求描述就在于“這部分做的和某個系統或某個版本的舊系統一樣就可以了”）
2.調研團隊參加所有子系統的調研會議，可以相互補充避免需求遺漏。這個項目規模比較大，根據業務的類型不同，分成了6個子系統，各個子系統的業務信息互有接口。我們安排每個人至少負責一個子系統的需求，但是在調研時，只要可能，我們都盡量讓每個人都參與所有系統的調研會議。對項目經理和技術經理則進一步要求了解所有系統的業務需求。這樣做的好處是，對于子系統之間的業務關系，調研團隊都可以有全面的了解，對業務的理解比較透徹全面，并且還可以相互補充遺漏。
3.多人調研，在會議后應該立刻回顧整理統一的會議筆記，消除歧義，避免遺漏。在開調研會時，全體與會人員都各自記自己的會議筆記，會后沒有強調當天整理會議筆記（會議進度很緊，每天開會到晚上8、9點鐘）。這導致以后閱讀會議筆記發現一些描述很簡單理解上有歧義的內容，或者同一份需求在幾個筆記上記錄的內容細節上有差異，事后難以追溯正確的信息。給編寫需求文檔帶來了一些困難，需要再次討論需求。
4.需求文檔編寫完成后，在開發階段也應該做檢查和更新，避免文檔錯誤對開發的誤導。我們在完成大量的需求文檔編寫工作后，在開發階段有部分文檔沒有做內容檢查和及時更新。后期測試時才發現少數需求內容的矛盾和錯誤，導致需要重新修改。
建議：
1、如果在編寫需求文檔后，開發階段應該做一邊閱讀需求文檔，一邊做需求文檔的檢查，對于保證需求質量效果會更好。
2、應該指定人負責需求追蹤和更新，在開發階段、測試階段要保持和用戶的需求溝通，這不是一個可有可無的簡單工作，很重要，并且會占用責任人50%的工作時間。
5.企業業務管理信息系統的需求調研方法：我認為對調研的組織安排是非常重要的，好的調研安排雖然未必產生質量高的需求，但是一個不遵循調研規律的調研活動，必然是低效的。下面是H項目調研組采取的調研流程，供參考：
1、第一步不是立刻和用戶當面討論需求細節，而是要業務關鍵用戶編寫初步的需求報告，提供給開發團隊閱讀分析。需求報告的內容是，對業務流程的描述，對業務需求的描述。需求報告的質量往往和關鍵用戶的投入多少有較大關系，經常在沒有面對面溝通時，關鍵用戶未必能對這份報告投入很多的時間和精力。但這是當面調研的基礎，一定要做，有粗糙疏漏的地方可以再現場調研時再細化。這可以再調研前就和用戶溝通，讓用戶編寫。
調研概要情況：X項目需求調研開始于2006-3-23結束于2006-6-15，內容包括現場需求調研4個人月和分析需求編寫需求文檔6個人月。參與調研的包括項目經理、技術經理和兩個開發骨干，編寫需求規格說明書字數95.4萬。
1.把二期項目當作一個新項目來做調研，避免需求細節遺漏。在調研的初期我們曾經有過疑慮，這是一個二期的項目，那么調研的內容是否只針對二期的新需求，對需求內容二期和一期一致的部分就不必調研了?
經過討論我們還是決定把二期項目當作一個新項目來做調研，即使二期和一期需求內容一致，我們也在調研會上討論，并記錄在調研筆記及以后的需求文檔上。這樣的好處是最大限度地避免了需求細節的遺漏。在現場調研時，發現有不少地方原來以為是二期不必修改的，經過討論后發現還是需要修改。（往往危險的需求描述就在于“這部分做的和某個系統或某個版本的舊系統一樣就可以了”）
2.調研團隊參加所有子系統的調研會議，可以相互補充避免需求遺漏。這個項目規模比較大，根據業務的類型不同，分成了6個子系統，各個子系統的業務信息互有接口。我們安排每個人至少負責一個子系統的需求，但是在調研時，只要可能，我們都盡量讓每個人都參與所有系統的調研會議。對項目經理和技術經理則進一步要求了解所有系統的業務需求。這樣做的好處是，對于子系統之間的業務關系，調研團隊都可以有全面的了解，對業務的理解比較透徹全面，并且還可以相互補充遺漏。
3.多人調研，在會議后應該立刻回顧整理統一的會議筆記，消除歧義，避免遺漏。在開調研會時，全體與會人員都各自記自己的會議筆記，會后沒有強調當天整理會議筆記（會議進度很緊，每天開會到晚上8、9點鐘）。這導致以后閱讀會議筆記發現一些描述很簡單理解上有歧義的內容，或者同一份需求在幾個筆記上記錄的內容細節上有差異，事后難以追溯正確的信息。給編寫需求文檔帶來了一些困難，需要再次討論需求。
4.需求文檔編寫完成后，在開發階段也應該做檢查和更新，避免文檔錯誤對開發的誤導。我們在完成大量的需求文檔編寫工作后，在開發階段有部分文檔沒有做內容檢查和及時更新。后期測試時才發現少數需求內容的矛盾和錯誤，導致需要重新修改。
建議：
1、如果在編寫需求文檔后，開發階段應該做一邊閱讀需求文檔，一邊做需求文檔的檢查，對于保證需求質量效果會更好。
2、應該指定人負責需求追蹤和更新，在開發階段、測試階段要保持和用戶的需求溝通，這不是一個可有可無的簡單工作，很重要，并且會占用責任人50%的工作時間。
5.企業業務管理信息系統的需求調研方法：我認為對調研的組織安排是非常重要的，好的調研安排雖然未必產生質量高的需求，但是一個不遵循調研規律的調研活動，必然是低效的。下面是H項目調研組采取的調研流程，供參考：
1、第一步不是立刻和用戶當面討論需求細節，而是要業務關鍵用戶編寫初步的需求報告，提供給開發團隊閱讀分析。需求報告的內容是，對業務流程的描述，對業務需求的描述。需求報告的質量往往和關鍵用戶的投入多少有較大關系，經常在沒有面對面溝通時，關鍵用戶未必能對這份報告投入很多的時間和精力。但這是當面調研的基礎，一定要做，有粗糙疏漏的地方可以再現場調研時再細化。這可以再調研前就和用戶溝通，讓用戶編寫。
