今天我們談到了那些年來設(shè)計師的“微小變化”，以及上下游協(xié)作（設(shè)計師，產(chǎn)品經(jīng)理，開發(fā)，運(yùn)營和維護(hù)等）之間的微妙關(guān)系。

所謂的“小變化”通常出現(xiàn)在設(shè)計師或產(chǎn)品經(jīng)理的口中，其描述如下：

僅更改文本顏色;僅更改圖標(biāo);只是一些微小的變化;非常簡單?

但是對于程序員來說，它通常會有不同的味道：

還需要在這里改變？想在這里經(jīng)營嗎？這個布局完全改變了！人與人之間的信任在哪里？

那么，人與人之間的信任究竟是如此無動于衷呢？還穿什么安全褲！

首先，來自這里的產(chǎn)品人員，如果你一開始不信任開發(fā)人員，你總是想把事情簡單，或者把時間和插入要求，那么開發(fā)人員也會有相應(yīng)的不信任：無論如何，你打算插入你需要什么來估計時間？

從設(shè)計師的角度來看，設(shè)計師的思維往往更自由自由，同樣的設(shè)計稿，在設(shè)計師的眼中是一對畫布讓我揮灑。

當(dāng)然，網(wǎng)頁設(shè)計師仍然熟悉基本的頁面布局實(shí)現(xiàn)，但程序員眼中的結(jié)構(gòu)和邏輯仍然是兩個世界。

因此，設(shè)計師常常覺得我的結(jié)構(gòu)不動，只是在這里添加一個小東西，或者每個元素都調(diào)整到某種位置顏色，因為它符合當(dāng)前的設(shè)計風(fēng)格。結(jié)果是程序員的悲劇：這相當(dāng)于重做！

在完美的開發(fā)過程中，上游和下游的方向非常強(qiáng)大。

產(chǎn)品和交互可以探索（bi）來確定（bi）來確定解決方案，與設(shè)計師的交互，沒有太大的發(fā)展空間。

設(shè)計師的設(shè)計草案，到前端開發(fā)，除了一些特效和實(shí)現(xiàn)細(xì)節(jié)外，基本上就是這么做的。如果前端開發(fā)區(qū)分重構(gòu)和JS，那么JS只能繼續(xù)使用重構(gòu)結(jié)構(gòu)進(jìn)行開發(fā)。

前端和后臺之間的關(guān)系實(shí)際上不是上游和下游。應(yīng)該說是平行的。即使在大多數(shù)情況下，前端也應(yīng)遵循背景規(guī)則。

在此過程的后端，測試學(xué)生必須參與產(chǎn)品文檔，設(shè)計測試用例的整個過程。從產(chǎn)品邏輯，設(shè)計恢復(fù)，兼容性問題，接口自動化測試，安全問題，性能問題等方面考慮。

更不用說還有運(yùn)營商遵循時序變化，優(yōu)化數(shù)據(jù)庫等等。

可以想象，上游的一些看似微小的變化將對下游人員造成蝴蝶效應(yīng)。

因此，除了“理解萬歲”之外我們稱之為口號，實(shí)際上，上游角色應(yīng)該更加了解下游工作，以便更好地推進(jìn)。

例如，產(chǎn)品操作的學(xué)生可以更多地了解交互，為什么它如此執(zhí)著，為什么這個彈出窗口不能如此轟擊？

互動學(xué)生可以看到我的互動形式是否過于嚴(yán)格的設(shè)計，是否可以有更好的演示形式？

設(shè)計師更多地考慮這種變化對頁面結(jié)構(gòu)的影響程度。設(shè)計如何成為一個頁面？

前端同學(xué)想一想，我可以使用模板JS /后臺嗎？我是否有能力考慮各種狀態(tài)和各種擴(kuò)展的變化？

后臺學(xué)生更多地考慮我的界面真的很容易使用？有沒有可以省略的參數(shù)？有沒有不應(yīng)該暴露的信息？界面太臃腫了嗎？該領(lǐng)域的意義是不清楚或不一致？

測試同學(xué)考慮一下，我怎么能這么難？

操作和維護(hù)同學(xué)多考慮一下，我還沒談過，你玩得開心嗎？

嘿，古人云，我住在長江，王住長江，長江是水，懂萬歲。