如何在開發過程中『優雅』的改需求

有木有這樣的場景，需求評審完了，已經開發中了（或者已經提測了）~~突然之間需求需要變更，而變更的原因各種各樣(領導們很強勢的加改需求並且立刻馬上要上線、運營喵比較強勢的加改需求、測試發現少一個空狀態或提示等等、產品狗自己當初沒想清楚需求但不改會出問題等等等)。這個時候我們只能硬著頭皮和程序猿哥哥們。。。

開發過程中改需求是很正常的事情，特別是敏捷。就像本汪就在開發過程中改過需求，代碼封版後也改過需求，聽說有人上線後還改過需求。那如何在開發過程中『優雅』的改需求呢？

每次更改需求都需要文檔等形式的記錄

從正式開發到封包到發布上線到後續之間，當中肯定有不止一次的更改需求。一次兩次還好，如果多了，到最後測試的時候，測試就會一臉懵逼「開發怎麼多開發了一個功能，這個是什麼鬼。。。」

所以每次變更(增刪改)不管需求多大都需要在相關需求文檔||原型文檔||功能表||業務流程圖||UI圖等上進行更改，並且知會溝通相關人員(如何溝通會在下面扯一扯)。並且在更改後需要在「Document History」更新一下相關信息：時間、作者、版本、更改內容等。有條件的話可以標註一下這次「增刪改」的內容是在文檔的哪個位置，方便相關人員查找！

說到這裡，建議每一份相關（相關需求文檔||原型文檔||功能表||業務流程圖||UI圖等）都最好有個「Document History」。有這個的好處首選是知道在哪個時間點改了什麼，有據可查，開發測試等等相關人員也知道加了什麼、需要測什麼，產品自己本身驗收、給相關培訓的時候也方便了自己；其次就是可以自己評判自己的當前能力。如果一個小項目的需求在「Document History」里有十幾條記錄，那你也差不多可以洗洗睡吧！(當然也有可能不是產品的問題，是運營或者領導們等的原因) ps：領導們表打我

不管改什麼需求，都需要有一個直接溝通的對象

在改需求後，第一件事就是通知開發改代碼，但是本汪不建議各位產品狗直接通知對應開發就結束了，接下來我具體舉個場景來說說這個有什麼危害。

開發過程中，微信的WWW發現少了一個提示，這個時候跟產品狗說，你這個地方少一個提示，看了看確實是這樣。那。。好吧。。改需求吧，你順便跟ios和Android說一下。第二天後台發現這裡有安全隱患，這個時候繼續叫來產品狗，這裡有安全隱患我建議這樣這樣，最好前台加個校驗這樣。產品狗思考了一波好像是的，不加資金安全會有隱患，就按這樣吧，你改吧，然後這個開發就屁顛屁顛的去改了。然後到了測試的時候，發現了一堆問題，前後台沒有調啊，這個改了我不知道啊，誰叫你改的。。balabala

大家也發現了問題，每次更改去知會的都是不同的人，然後導致的就是後面一系列的問題。所以我建議各位變更後，不一定需要人肉把整個項目組的人都說一遍，只需要找到一個唯一對接人，每次更改都直接與這個對接人溝通,然後由這個對接人去跟開發哥哥們去說。當然這個技術對接人可以是項目經理、測試，甚至可以是某一個開發。

廣而告之

上述兩項搞定後，最好還是以PM需求變更的角度告知下所有人。在群里發一下需求變更的內容以及相關截圖，並且at一下所有人或者幾位核心相關。

如何給開發洗腦，讓開發接受改需求

其實大部分程序猿哥哥還是接受改需求的，畢竟改需求也是一件很正常的事情，但是畢竟改需求錯在我們，所以最好改需求還是對程序猿哥哥說說好話，在精神和物質上犒勞下。比如平時沒事多扯扯談啊，抽抽煙啊等這樣。最好呢在改的時候告訴下開發變更的原因和好處，誰要求改的，這樣開發至少在心理上有那麼一絲絲的慰藉。

其實吧，如果我們站在開發的角度上來講，我們也就能理解為什麼開發這麼討厭改需求了。咱們舉個最簡單的例子：一個用戶到一家餐廳點了一個蛋炒飯(這個就像是原始需求，並且評審通過了)，然後開始打蛋炒飯(開始開發了)，這個時候剛剛打好蛋，用戶對服務員說不要雞蛋用鴨蛋(這個時候就是改需求)。你說這個時候餐廳的工作人員會不冒火嘛~~~所以，不管幹啥都設身處地的站在開發的角度上考慮，就像咱們也會設身處地的站在用戶角度上考慮一樣。

特此說明，以上僅為Omega個人觀點

如有補充或者建議啥的請私聊我哈

原文：

Alpha的公眾號|小白聊產品（ID：AlphaDiscuss）

作者：Alpha（微信：DINGALPHA），一個很污擅長講葷段子的PM狗

PMCAFF：ALPHAWONG

推薦閱讀：