我對IT專案需求發掘的一些思考

2021-08-10 20:56:36 字數 1318 閱讀 7204

需求是it專案開始階段重要的環節,準確的發掘客戶真實的需求(requirement discovery)是專案成功的關鍵。idg 的調查顯示60% 的專案失敗原因是需求階段的失誤,或者是需求階段產生連鎖效果造成的。但是我們看到,很多it專案時沒有需求發掘這乙個步驟的。需求是業務部門提出的,it部門作為接收方,只是做到需求分析設計。

·        制定需求管理發掘計畫

·        需求採集

·        需求分析

·        需求驗證、審核

·        需求驗收

·        需求變更管理

專案開始前,我們都會有乙個專案範圍,之後基於這個範圍開展工作。很多人認為這個專案範圍會是固定的,需要嚴格遵守的。但是因為需求發掘這一工作流程的加入,專案的最初範圍會因為需求發掘的成果而發生修正,改變。要知道傳統的專案需求管理方式普遍存在需求不斷增加,專案範圍不斷擴大的情況。而通過需求挖掘可以有效的避免這一點。

專案範圍與需求挖掘是乙個互動影響的關係,而不是乙個wate***ll流程一樣的單項流動過程。專案範圍提供指導,需求挖掘發現需求再反過來影響範圍。最終通過專案發掘的整個流程,需求得到了全面的優化,整理。

整個需求挖掘流程中,需求採集涉及的部門多,牽扯的關鍵人物(stakeholder)多,處理起來有很多障礙,在這裡提出一些我認為有幫助的方法,希望幫助大家的工作。

1.      需求採集會議是需求採集中被廣泛使用的方式,作為需求分析師,自己建立一套自己的控制需求採集會議的方法。這樣的方法有很多,之後我會仔細介紹。但是重要的一點是這些方法一定要保證乙個有紀律性的,有規律的需求採集會議。

2.      採集需求是,使用視覺化,容易理解的方式描述需求,這樣可以提高交流效率。我建議直接使用use case的建模方式,文字描述作為輔助。

3.      之所以採用視覺化建模,因為它直觀,易理解,所以在會議上就可以快速達成意見共識。於是我們就可以直接在會議上進行預審,會後也可以快速產生文件,進行分析,審核工作。

4.      採集的需求一定要讓業務部門驗收簽字,這樣可以防止隨意的變更,也可以讓業務部門對需求採集有責任感,從而認真對待。

不少人認為需求挖掘是乙個可有可無的步驟,而且這個步驟會產生很大的費用。對這個問題,iag做個詳細的調查,他們的研究大量的客戶和超過1000個專案, 已經發現需求質量的提高大大降低系統開發和實施的時間和成本。這是因為沒有需求挖掘的專案往往伴隨著專案進行中的大量的需求變更,每個人都知道這是的需求變更會產生大量的費用。iag的調查報告顯示,it專案的平均返工率達到30%。伴隨著成本的提高,很多隱性的負面因素所產生的消極後果更是無法衡量的,比如專案的延期、甚至失敗,客戶滿意度的降低,使用者的反饋不佳等。綜合考慮需求挖掘的費用遠遠低於沒有這個過程的情況。

對Python shell的一些思考

對python shell的一些思考 就兩次指令碼處理的編碼練習而言,我感覺如果使用python去寫指令碼來處理日常事務的話,相對於shell是一件比較麻煩的事情,因為我可以使用shell在花費更少的時間內,比較熟練地使用awk sed和grep這些常用的命令在非常簡短的指令碼語句內,完成pytho...

對迷茫的一些思考

最近依然迷茫不安,從3月份開始嘗試去找工作,現在已經4月底,依然沒有著落。不是沒有好機會,而是自己能力不足,抓不住機會,於是自己很慌亂,發現不會或不擅長的東西,拼命在補,同時也在後悔為什麼當初沒有好好努力。然後也明白了一些道理。人們總說學習永遠不晚,其實是會晚的,會錯過很多時機,但時機是不會再次到來...

對程式設計的一些思考

1.程式 是程式設計思想的體現 我想程式設計人員在設計程式之初,肯定會有一番思考。思考主要是程式設計的目的,然後是實現目的的方法,最後才是 的實現。所以,程式 是程式設計思想的體現。分析 的啟示 我們分析程式 時,可以在看 之前,想想這個 要幹什麼事,然後再去看 就容易多了。程式設計的啟示 先思考程...