@姬小光 （騰訊前端工程師）：今天我們聊聊那些年設計師的“小改動”，以及上下游協作（設計師、產品經理、開發、運維等）之間的微妙關係。
那些所謂的“小改動”通常在設計師或產品經理的嘴裡，有以下幾種描述：
- 改改文字顏色而已；
- 換個圖示而已啦；
- 只是一些小改動；
- 很簡單的啦～
可是到了程式設計師這裡，往往就變味兒了：
- 這裡也要改？
- 這裡要運營？
- 這個佈局完全變了啊！
- 人與人之間的信任都哪去了？
那麼，究竟是什麼讓人與人之間的信任變得如此淡泊呢？還穿什麼安全褲！
首先，從產品人員這裡，如果一開始就不信任開發人員，總想把東西往簡單了說，或者排上了時間又插需求，那麼開發人員也會產生相應的不信任：反正你是要插需求的，不多估算點時間怎麼行？
而從設計師的角度，往往設計師的思維更奔放自由一些，同樣的設計稿，在設計師眼裡就是一副完美的畫布任我揮灑。
當然，資深的網頁設計師還是熟悉基本的頁面佈局實現，不過與程式設計師眼裡的結構與邏輯還是兩個世界。
所以往往設計師感覺，我的結構沒怎麼動，只是這裡加了個小東西，或者各個元素都調了些位置顏色，因為要符合現在的設計風格嘛。結果到程式設計師那裡就悲劇了：這相當於重做啊！
在完善的開發流程中，上下游的方向是非常牢固的。
產品與互動可以探（si）討（bi）確定方案，定好的互動到設計師那裡，就沒有太大發揮餘地。
設計師做好的設計稿，到前端開發那裡，除了一些特效與實現細節，基本上就是照做而已。而前端開發如果區分重構和 JS，那麼 JS 基本也只能拿著重構寫好的結構繼續開發。
前端跟後臺的關係倒不像是真正的上下游，應該說是並行的，甚至大部分時候前端要按照後臺的規矩來玩。
而測試同學，在這個流程的最後端，卻要從產品文件開始介入整個流程，設計測試用例。從產品邏輯，設計還原，相容性問題，介面自動化測試，安全問題，效能問題等都要關注。
更別提還有運維哥要跟著改定時任務，優化 DB 等等了。
那麼可想而知上游的一些看似微小的變化，會給下游的人員造成多大的蝴蝶效應。
所以，除了我們喊成口號的“理解萬歲”之外，其實上游的角色應該更多的去了解下游的工作，才能更好的推進下去。
比如產品運營同學可以多瞭解一下互動為什要這麼執著，這個彈窗為什麼不能這麼彈？
互動同學可以看看我的互動形式是否太過限制設計，能否有更好的展現形式？
設計師多想想，我這個改動到底會對頁面結構有多大影響，這個設計到底是如何變成頁面的？
前端同學多想想，我做的模板 JS/後臺 能不能用？我是否有考慮到各種狀態的變化，各種擴充套件的能力？
後臺的同學多考慮一下我這個介面真的好用嗎？有沒有哪些引數可以省略？有沒有那些資訊不該暴露？是否介面過於臃腫？是否欄位表意不清晰或各處不一致？
測試同學多想想，我 TM 怎麼這麼苦逼？
運維同學多想想，我 TM 還沒說話呢，你們也好意思吐槽？
哎，古人云，我住長江頭，君住長江尾，滾滾長江都是水，理解萬歲吧。