如何做好需求變更?

4 評論 17297 瀏覽 65 收藏 6 分鐘

毫無節制的需求變更,影響的不僅僅是項目成本,更是會影響整個團隊的士氣。本篇總結一下,我們應該以怎樣的姿態和方法來應對需求變更。

思維觀念

  1. 需求變更是必然的、可控的、有益的。
  2. 一切的需求變更都是為了讓項目更加完善。
  3. 客戶所有的變更都是有原因的,我們要積極地滿足其背后的需求,而不是機械地滿足其表面的要求。
  4. 一個完整的產品研發流程中各部分的占比大概是這樣的:50%做需求,30%做開發,20%做測試。
  5. 需求變更控制的目的不是控制變更的發生,而是對變更進行科學的管理,要確保變更有序地進行,最大限度地控制需求變更給軟件質量造成的負面影響。
  6. 需求分析人員和客戶的關系不應該僅僅是記錄人員和需求提供者,他們的關系應該更多的是戰略合作伙伴關系。

原因分析

需求變更的出現主要是因為在項目的需求確定階段,用戶往往不能確切地定義自己需要什么。

用戶常常以為自己清楚,但實際上他們提出的需求只是依據當前的工作所需,而采用的新設備、新技術通常會改變他們的工作方式;或者要開發的系統對用戶來說也是個未知數,他們以前沒有過相關的使用經驗。

隨著開發工作的不斷進展,系統開始展現功能的雛形,用戶對系統的了解也逐步深入。于是,他們可能會想到各種新的功能和特色,或對以前提出的要求進行改動。

他們了解得越多,新的要求也就越多,需求變更因此不可避免地一次又一次出現。

應對措施

  1. 項目前期盡量清晰地確定需求范圍和需求基線并與客戶共同確認。
  2. 設計靈活的軟件架構,以能夠對變化的需求進行快速響應。
  3. 對變更的需求進行優先排序,分批實現。對于零星變更,集中研究、批量處理。
  4. 妥善保存變更產生的相關文檔。
  5. 制訂簡單、有效的變更控制流程。

流程規范

  1. 變更申請:如果用戶需要變更需求,則填寫《需求變更申請》,經客戶方和服務方共同確認后,發送內容給項目組需求負責人;
  2. 變更分析:《需求變更申請》的項目組接收者,錄入此變更請求到《問題跟蹤清單》,分析并標識“問題類型”;
  3. 變更決策:項目經理和相關人員進行內部變更評估、審核,決定哪些變更無法修改并說明原因,哪些變更需要修改和什么時候修改;
  4. 變更實施:審核通過的《需求變更申請》,確定開發時間和納入的版本,制定開發計劃;
  5. 變更驗收:對于需求變更而進行的版本更新,需交付相應的《版本更新說明》。

注意事項

需求的變更要經過出資者的認可,這樣才會對需求的變更有成本的概念,能夠慎重地對待需求的變更。

小的需求變更也要經過正規的需求管理流程,否則會積少成多。在實踐中,人們往往不愿意為小的需求變更去執行正規的需求管理過程, 認為降低了開發效率,浪費了時間。但正是由于這種觀念才使需求逐漸變為不可控,最終導致項目的失敗。

精確的需求與范圍定義并不會阻止需求的變更。并非對需求定義得越細,就越能避免需求的漸變,這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的,并非需求寫細了,它就不會變化了。

注意溝通的技巧。實際情況是用戶、開發者都認識到了上面的幾點問題,但是由于需求的變更可能來自客戶方,也可能來自開發方,因此,作為需求管理者,項目經理需要采用各種溝通技巧來使項目的各方各得其所。

需求一定要與投入有聯系,如果需求變更的成本由開發方來承擔,則項目需求的變更就成為必然了。所以,在項目的開始,無論是開發方還是出資方都要明確這一條:需求變,軟件開發的投入也要變。

 

作者:曉莊同學? ? 公眾號:曉莊同學產品筆記

本文由 @曉莊同學 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

專欄作家

曉莊同學;公眾號:曉莊同學產品筆記,人人都是產品經理專欄作家。互聯網老兵,各大平臺專欄作者。

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫得真好!感謝

    回復
  2. 同感。接項目做的真的是深有感觸呀。很多客戶方認為自己出了錢,時不時變更一點需求。此時產品經理若不嚴格按照需求變更流程去把控,非常容易需求失控,項目延期甚至失敗呀!一定要讓客戶有成本和時間的概念和考量?。?!

    來自廣東 回復
    1. 兩年前的文章,也能給我來個評論,不容易啊。。。

      來自河南 回復
  3. 歡迎關注微信公眾號:曉莊同學產品筆記
    與我一起結伴同學~

    來自河南 回復