需求變更，讓每一個技術人頭疼的問題，應該以怎么樣的態度來面對需求變更，是今天要討論的話題。

為什么技術人討厭需求變更？

一個典型的互聯網產品項目的流程是：

（1）調研，產品經理設計需求；

（2）產品經理和技術進行需求評審；

（3）技術進行方案設計；

（4）技術進行編碼實現；

（5）技術進行功能聯調；

（6）技術進行提測，開始進行測試；

（7）若干輪測試與BUG修復，達到準上線狀態；

（8）發布沙箱環境，進行最后一輪沙箱測試，達到準發布狀態；

（9）將產品系統發布到線上；

不管使用敏捷看板，還是傳統瀑布式項目管理方法，就單個項目來看，這流程是串行的。

畫外音：如果夠敏捷，產品、測試、研發等角色是流水線的。

可以看到，產品方案是在項目流程的最上游，產品方案確定后，技術同學會按照2-3-4...-7-8-9等步驟將產品發布上線。

試想，現在項目流程進行到了第x個步驟，產品經理突然說，產品方案要變化，這意味著什么呢？

這可能意味著一系列工作要推到重來：

（9）線上發布白干了，產品要回滾；

（8）沙箱發布白干了，沙箱要回滾；

（6-7）若干輪測試白干了；

（5）聯調白干了；

（4）代碼白寫了；

（3）技術方案白設計了；

（2）需求要重新評審；

（3）技術方案重新設計；

（4）代碼重新開發

（5）系統重新聯調；

（6-7）重新提測，迭代測試；

（8）重新發布沙箱；

（9）重新發布線上；

產品經理們，嘗試著體會一下技術們的心里感受，就知道為什么技術這么痛恨“需求變更”了。

看到這里，一定有產品經理嘀咕“有這么夸張么，只變了10%的需求，需要全部重來么，技術同學也太矯情了”。有必要全部重來么？能不能省去聯調、提測、測試的幾個環節？

很多人把產品設計比喻成建設高樓大廈，產品經理是大廈設計師，技術是工程師。大廈快建成了，設計師突然說，圖紙要修改10%，工程師要不要重來？還是說省去幾個環節？

那么，需求變更了，技術同學要不要懟回去？

在一家互聯網公司，產品技術是很難分割的一個整體，他們雖有分工，各有側重，但歸根結底其最終目標是一致的：為達成公司業務目標共同努力。

為了這個共同的業務目標，產品經理的工作思路與邏輯應該是：

“在資源有限的情況下，做什么產品、工具、后臺、運營活動，對業務目標的達成最有幫助，就最先做什么”。

然而，有些產品經理的工作思路與邏輯卻是：

“想一出是一出，拍腦袋決策，憑直覺決策”：

• 登錄這里改一下，能夠提高轉化率

• 詳情頁這里改一下，能夠提高留存率

• 過節發個紅包，能夠拉新，能夠提高活躍度

無窮多的需求上線后，無非是這幾個結果：

• 產品成功了，哇，天才的構想

• 產品效果不好，噓，技術們在忙著做后面的需求，也不會有人注意到

• 有人想起來要復盤，可以用“互聯網產品，還不允許試錯啦”搪塞過去

在“人人都是產品經理”的時代，有多少沒有調研，沒有分析，憑借直覺的產品經理，拍腦袋出來的需求，讓一大幫技術專家為之操勞花好幾月去實現。

畫外音：這句話是對產品經理的侮辱，還是？產品經理的門檻很高，專業要求很高的。

不僅如此，項目半途，有多少需求是因為產品經理“之前沒有想清楚”變更了需求，讓“幾百人日”的研發投入付之東流。

即使有些非常資深，非常厲害的產品經理，但人數一多，每個產品經理都想要業績，在研發資源有限的情況下，為了爭搶資源：

• 我這提了N個需求，總得排期一個吧

• 競品有了這個功能，我們也必須有一個

• 老板說了，這個功能必須在節前上線

畫外音：

（1）既然負責這個產品模塊，必須提對應的需求呀；

（2）劣幣驅逐良幣；

一將無能，累死三軍。

所以，這不是一個簡單的“需求變更，要不要懟回去”的問題，甚至不是一個“需求提過來，要不要承接”的問題：

• 產品技術作為一個整體，共同為公司的業務目標服務

畫外音：有些公司甚至有“技術不允許拒絕需求，不允許拒絕需求變更”的畸形文化。

• 產品作為技術側的上游，需要系統性思考問題，而不是拍腦袋提需求

• 技術側作為產品側的下游，不能只是一味的接需求，要幫助他們想清楚，少為業務埋坑

技術側能夠如何幫助產品，讓他們把需求提得更靠譜呢？

至少，“過節發個紅包”這類需求評審時，多問這么一些問題：

• 哪些產品指標，和業務的最終目標相關

畫外音，假設有：新客，轉化，留存，下單等。

• 這些產品指標中，哪些是主要矛盾

畫外音：假設是新客。

• 對于這個產品指標，做哪些事情可以改善

畫外音：假設有12345五件事。

• 對于這五件事，哪件事投入產出比最高

畫外音：假設真的是“過節發個紅包”這個活動。

• 對于這個活動，活動方案有幾種優缺點是什么，為什么最終選擇了這一種，活動邏輯是怎么樣的，活動效果有沒有預估，有沒有埋點，活動結果怎么評估...

畫外音：啥？活動只有一種方案？

事先問的問題越多，討論得越充分，需求就越靠譜，需求變更的幾率就越小，埋坑的幾率就越小。

總結：

• 產品技術作為一個整體，共同為公司的業務目標服務

• 產品經理要系統性思考問題

• 技術要幫助產品經理系統性思考問題

有技術的同學說，我天天在做需求，沒時間想這些問題，沒時間和產品經理討論這些問題，怎么辦？

你MB，你活該天天加班。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的需求又变了，要不要怼回去？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。