已經確定的設計，功能開發測試完了都已經上線了，覺得不滿意，要重新設計開發，在互聯網公司是普遍現象嗎？

01-04

我是一名前端工程師，來新公司已經3個月，發現工作中存在一個問題，一個功能開發測試完畢上線了，領導又覺得不滿意（當初領導已經審核確定了的），讓修改設計圖，意味著我又得重新弄一遍，程序和測試也得走一遍，這種事已不是一兩次發生了，提了意見，我的leader也無奈，他提過，領導不接受。我想問的是，大多數互聯網公司都這樣嗎？還是這家公司領導層的問題？

流程不規範，這個事情要靠leader去推進，如果推進不了，那就拜拜吧。

所謂的流程，對於你們來說，最重要的是：

1. 不完整的需求不做。

2. 改動的需求可以做，但是請按照時間排期。

3. 開發開始做需求前，需要確認需求，至少有兩次評審，一次需求評審，二次交互評審。所有評審開發提出的問題都要有解決方案。

4. 開始開發前，設計稿交互稿出來前，方案需要得到老闆的認可，否則不做。

正常。

我們換個角度，用產品思維去分析一下這個問題是不是更好一些？

首先，如果不考慮領導已經審核通過然後又要求推到重來的問題，現在這個功能你和lead覺得okay嗎？領導提出的新的設計方案是不是更好一些？如果大家都覺得新方案更好一些，那麼就改，回頭再反思為什麼前面為什麼沒有想到這個更好的方案。如果你和你的lead覺得領導提的新方案不如原來的方案，能不能先跟領導溝通一下兩個方案的優劣問題？

第二，為什麼領導沒有在上線前甚至置頂設計方案時提出重新設計？而是上線後才提出來？這中間是不是有溝通方面的問題。按照一般的流程完成交互設計和高保真設計後，應該就能完整的模擬線上的功能和體驗。

不管是領導、lead和開發人員，如果大家都站在產品的角度去考慮一下這個問題，我覺得至少雙方不會出現抵觸的情緒，說到底產品和開發人員不是對老闆個人負責，而是對產品負責。如果老闆視這一切而不顧，蠻橫不講理，那麼這個問題跟需求變更什麼的沒有什麼關係了。

互聯網產品，特別是C端產品，說實話不上線誰也不知道這個功能會有什麼樣的用戶反應，作為產品和研發人員，唯一能做的就是快速試錯，快速響應。

如果就需求變化來講，有變化太正常了，能不能理解就看你怎麼去看這件事情，如果你的目標是把工作做完，那肯定很難理解，但如果你的目標和老闆一樣，是把工作做好，肯定會覺得很正常。

對於你描述的這種情況，其實有抱怨很正常，如果領導提前體驗，有問題及時提出就不會讓下面的人有這麼多埋怨了。

很多時候讓人懊惱的不是需求變更頻繁，而是需求變更的方式很難讓人接受，所以這就有必要引入敏捷流程，項目透明化，最小化驗證，如果有變更也不會走太遠的彎路。

你反正是按月拿工資的，又不是按項目拿提成的，你管他怎麼改。上線時間是他的，他愛怎麼折騰怎麼折騰。

曾經我也很討厭需求變更，現在想起來，覺得討厭的沒什麼道理。

首先這個情況很正常。

然後說點題外話，關於程序員對這種事情的面對方法。

如果你是追求磨練技術，其實這對你來說沒什麼差別，你就算不做這個項目，還是要要做其他項目，無論做哪個項目，領導都安排好工期，所以說只要不是加班返工，真的對你來說沒有區別，而且如果經常發生這種情況，以後你開發的時候就得思考了，怎麼把代碼寫的不是那麼死。

如果你是追求技術的同時，還想做出點有成就感的產品，那你確實可以考慮換一家公司（情況允許的情況下）。

以前我也是這種現象的猛烈噴子。

自從自己開始負責產品後發現不同產品的明確度不同，有可能要做出來才發現體驗不對。有的時候是過程中需求發生比較大的變化，例如受到外界產品的影響，明確的知道之前的設計有缺陷。這樣的情形數不勝數。

當然這也和產品和設計的水準直接相關。但是相信我，即便是喬布斯，以他的品味和遠見也一定是改無數次。

總之，只要是為了最終的產品夠出色，並且給了合理的時間，或者時間太緊但有合理補償的，我認為夠職業化的童鞋都還是要認真做完的。畢竟請你來從沒說就是要一次成型否則可以不做的是吧。如果太脆弱糾結於流程，可能不適合在產品靈活變化快速的公司工作，可以考慮換去比較穩定傳統的公司。

最後從技術的角度，多學一下設計模式，習慣組件化。熟了以後還真是不怕你改。而且經驗足夠多以後，他要改什麼，會怎麼改，你其實早就預料到了，早早的留下伏筆，下班去看電影都不是事兒。

看了一圈回答，你們這是慣的他們呀

大多數互聯網公司都這樣嗎？

大多數不正規的項目才是這樣的

還是這家公司領導層的問題？

肯定有一部分原因

你能接受未來的媳婦在結婚典禮上說,要再考慮考慮才嫁給你嗎？

太正常不過了

我們遇到過離上線還有4小時，大老闆大手一揮，這個不行，改掉~

離發布還有兩天，這個版不對，重新切~