【DevCloud · 敏捷智庫】如何避免重要需求遺漏？

避免重要需求遺漏的思路

避免重要需求遺漏，首先我們需要反問一句?——?為什么這些緊急重要的需求無法更早預見？同樣的，我們需要了解：

具體是哪些外界原因？這些原因是否有共性，有的話，那就針對性處理；

增加的需求有無共性特點？有的話，可以針對性處理；

臨時增加有多臨時？我們是否有提高或改善響應能力的空間，如果我們可以更快調整和響應，使得這些臨時需求對我們產生不了什么影響，那么這個問題也就不再是問題了；

既然是常態(tài)，為何我們的流程沒有做出調整去應對？是調整過流程或工作方式，還是無法解決問題，還是說不知道該怎么調整流程或工作方式去適應？

具體操作方法

具體操作，可以按照事前、事中、事后各個階段來采取不同的措施處理。

一、事中的處理

根據具體情況不同，在發(fā)現(xiàn)需求遺漏的當時，可以采取如下一些做法：

重要需求遺漏，不緊急：既然不緊急，按照常規(guī)做法增加進去即可，但如果經常出現(xiàn)遺漏，就要考慮是否是需求分析和規(guī)劃的實踐做法有問題，才會導致問題持續(xù)出現(xiàn)，這種情況，應強化需求結構化管理，從全局出發(fā)進行思考和規(guī)劃，避免因為思考的片面化和局部性導致的遺漏；

重要需求遺漏，緊急：既然是又重要又緊急的需求，那么必然就得調整當前開發(fā)工作的順序，把這個遺漏的重要緊急需求排進去，把工作安排下去；然后就要考慮從需求的優(yōu)先級和需求的結構化管理兩個方面入手復盤，并切實改進，避免類似情況再次發(fā)生；

需求遺漏：如果是不太重要的需求遺漏，按照常規(guī)做法處理即可；可以根據其緊急程度和影響，決定是否調整工作順序讓這個需求插隊；如果這種情況反復出現(xiàn)，那建議可以考慮進行復盤，從需求結構化管理的角度進行分析，并商討改進措施；

二、事后的處理

事后其實就是復盤，復盤的關鍵是要基于盤來推演和分析，這個盤就是事前制定的模型和規(guī)范。是我們有模型有規(guī)范，但執(zhí)行出了問題？還是說這幾個需求情況特殊，模型比較簡單沒有覆蓋到這些特殊情況？還是說模型和規(guī)范都沒問題，就是人員能力不足，導致判斷偏差大？只有找到正確的根因，才能夠真正有效的解決問題，所以我們不復盤則已，要復盤就務必要認真嚴格地進行復盤。

怎么復盤？復盤也是有方法有套路的，業(yè)界也有相關書籍可供我們參考借鑒。例如溫伯格在《成為技術領導者》中提出的MOI模型就可以用作復盤的一種思路。

M：激勵（Motivation），是不是人們沒有動力去做這件事情？

O：組織（Organization），是不是無組織無紀律、一片混亂，人們不知道自己或別人該做什么？

I：想法或創(chuàng)意（Idea/Innovation），是不是缺少如何解決這些問題的點子或創(chuàng)意，不知道有什么辦法解決這個問題？

復盤時要注意，受限于能力或經驗以及出問題次數(shù)多少的影響，我們可能無法得出一個準確的結論和必然有效的解決方案。此時一方面需要秉持持續(xù)改進的心態(tài)，我們可以先落實當前已經比較明確的改進措施，后續(xù)再觀察效果，持續(xù)復盤、持續(xù)改進即可。另一方面我們也可以先采取一些臨時措施。

預留時間：比如，如果確實很難分析清楚為什么總是會遺漏需求，無法進行非常有針對性的處理時，也可以采取較為模糊應對的方式。可以拉取過去一段時間的工作記錄，評估這段時間每個迭代的突發(fā)需求所消耗的工作量投入，可以取個平均值，然后在后續(xù)進行迭代工作安排的時候，固定的預留出一定量的時間，用于應對極有可能會出現(xiàn)的突發(fā)需求。

需求拆細：當出現(xiàn)突發(fā)需求，導致我們需要調整工作順序時，很有可能會因為需求顆粒度大以至于騰挪余地有限，而難以避免突發(fā)需求帶來的影響，因而還應該盡可能地采取拆細需求的方式，將顆粒度比較大的需求拆分為較小顆粒度的需求，可以增加調整需求工作順序時的靈活性；

要確定到底要預留多少時間，可以利用DevCloud的Epic-Feature-Story結構，把突發(fā)需求匯集在一起，便于統(tǒng)計。例如創(chuàng)建一個特殊的Epic“突發(fā)需求”，下一級是為每個迭代創(chuàng)建的Feature，用來承載各個迭代里面具體的那些突發(fā)需求（體現(xiàn)為Story），并做好工時的記錄，迭代結束后，就可以來計算出現(xiàn)了多少個突發(fā)需求、投入了多少工作量了。

也可以采用“模塊”字段來輔助記錄和統(tǒng)計突發(fā)需求的數(shù)據。例如，新建一個模塊，取名“突發(fā)需求”，所有突發(fā)需求都標注為這個模塊，那么后續(xù)就可以基于模塊進行篩選或查看報表等方式來統(tǒng)計突發(fā)需求所消耗的工作量了。

三、事前的處理

事前的處理放到最后來介紹，是因為之所以會出現(xiàn)問題一般都是因為事前沒有做好，但已經出現(xiàn)了問題就需要在當時盡快處理，所以先介紹了事中的處理。但當我們處理完問題也完成了事后復盤，就需要考慮未來的事前，盡可能的避免問題發(fā)生。

簡單來講，事前的話，就是要做好需求的結構化管理和需求的優(yōu)先級管理，以及做好相關規(guī)范的宣導、人員的動員和能力的培養(yǎng)，這樣就能夠有效的避免或減小突發(fā)需求帶來的影響了。

參考附錄

相關書籍

杰拉爾德·溫伯格：《成為技術領導者》

邱昭良：《復盤+：把經驗轉化為能力》

軟件開發(fā) 敏捷開發(fā) 項目管理

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。