聽講座后對需求管理的感悟_需求管理的体会

作者：weixin_40725706 | 2024-02-06 18:26:10

踩

需求管理的体会

3月1日去了聽了火龍果組織的有關需求開發與管理的講座，老師講的很精彩，也給了我很多啟發。

1. 關于需求開發：不得不承認，做了幾個項目的需求分析員，其實際工作只是需求的管理，并未牽扯到需求開發，或者說深層次的需求開發。Spec是企劃已經做好了的，而我的工作之一就是仔細研讀和分析，對一些細節問題，與企劃探討并明確，這只能說是需求開發的皮毛。

2. 需求管理：我平時所做的工作及流程和老師講的大致相同。

1）得到最初的spec，然后經過測試人員與開發人員的共同討論分析，找到規格中不明確和不合理的地方，與企劃溝通確認并修改。這個步驟中有幾個關鍵點是要注意，一是規格一定要得到開發人員的承諾，否則spec做的再完美，開發人員無法實現，或無法按時完成，會給這個項目帶來不必要的麻煩。二是修改后的規格一定要得到客戶的最終確認才可開始進行開發。

2）將已完成spec轉化為需求追蹤表及需求說明書，并對其做評審，檢查需求項是否覆蓋完全；定義是否明確，沒有二義性；每個需求項之間的關聯是否正確及完全等。

3）檢查測試程序及開發部分是否將需求覆蓋完全

4）需求變更的問題：需求管理主要的工作就在這里，十分重要。需求無時無刻不在變化，這就需要我們掌握一個版本變更的時機，如果稍有變化，就要開會評審，執行變更，會耽誤我們很多的時間。我覺得老師說的就很好，應該根據項目實際的生命周期來確定時機：如果項目是瀑布式的，則必須及時的變更及評審。如果是迭代式的開發，則完全可以等到項目的結束的時候再做這些動作。

還有就是根據需求變化的大小，影響來決定評審的形式。我們在項目初期的時候，就應該將需求分成兩部分，關鍵需求（影響功能完成的），非關鍵需求（一些類似UI的部分）。如果是關鍵需求，就一定要開會進行正式評審，如果是一些非關鍵性需求，則可以累積到一定到數目后再進行正式評審。

另外還有一些在實際工作中需要注意的問題：比如正式評審的形式。在項目十分緊張的情況下，我們是否一定要開會才可以正式評審？我認為不應該拘泥于形式。需求管理員可以先以mail的形式將要變更的需求項發布出來，然后請各負責人評估，并回復可能的影響。如果影響不大，各方面又都沒有什么異議，那么mail的形式就完全可以完成正式評審。這樣做既節省了時間，有保留了變更記錄，何樂而不為呢。（當然這只是個人看法，還有待大家的進一步討論）

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/weixin_40725706/article/detail/63885