需求又變了，要不要怼回去？

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

為什麼技術人讨厭需求變更？

一個典型的網際網路産品項目的流程是：

（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，你活該天天加班。

本文轉自“架構師之路”公衆号，58沈劍提供。