今天我們聊聊那些年設(shè)計(jì)師的“小改動(dòng)”，以及上下游協(xié)作（設(shè)計(jì)師、產(chǎn)品經(jīng)理、開(kāi)發(fā)、運(yùn)維等）之間的微妙關(guān)系。

那些所謂的“小改動(dòng)”通常在設(shè)計(jì)師或產(chǎn)品經(jīng)理的嘴里，有以下幾種描述：

可是到了程序員這里，往往就變味兒了：

那么，究竟是什么讓人與人之間的信任變得如此淡泊呢？還穿什么安全褲！

先，從產(chǎn)品人員這里，如果一開(kāi)始就不信任開(kāi)發(fā)人員，總想把東西往簡(jiǎn)單了說(shuō)，或者排上了時(shí)間又插需求，那么開(kāi)發(fā)人員也會(huì)產(chǎn)生相應(yīng)的不信任：反正你是要插需求的，不多估算點(diǎn)時(shí)間怎么行？

而從設(shè)計(jì)師的角度，往往設(shè)計(jì)師的思維更奔放自由一些，同樣的設(shè)計(jì)稿，在設(shè)計(jì)師眼里就是一副的畫(huà)布任我揮灑。

當(dāng)然，的網(wǎng)頁(yè)設(shè)計(jì)師還是熟悉基本的頁(yè)面布局實(shí)現(xiàn)，不過(guò)與程序員眼里的結(jié)構(gòu)與邏輯還是兩個(gè)世界。

所以往往設(shè)計(jì)師感覺(jué)，我的結(jié)構(gòu)沒(méi)怎么動(dòng)，只是這里加了個(gè)小東西，或者各個(gè)元素都調(diào)了些位置顏色，因?yàn)橐犀F(xiàn)在的設(shè)計(jì)風(fēng)格嘛。結(jié)果到程序員那里就悲劇了：這相當(dāng)于重做?。?/p>

在完善的開(kāi)發(fā)流程中，上下游的方向是非常牢固的。

產(chǎn)品與交互可以探（si）討（bi）確定方案，定好的交互到設(shè)計(jì)師那里，就沒(méi)有太大發(fā)揮余地。

設(shè)計(jì)師做好的設(shè)計(jì)稿，到前端開(kāi)發(fā)那里，除了一些特效與實(shí)現(xiàn)細(xì)節(jié)，基本上就是照做而已。而前端開(kāi)發(fā)如果區(qū)分重構(gòu)和JS，那么JS基本也只能拿著重構(gòu)寫(xiě)好的結(jié)構(gòu)繼續(xù)開(kāi)發(fā)。

前端跟后臺(tái)的關(guān)系倒不像是真正的上下游，應(yīng)該說(shuō)是并行的，甚至大部分時(shí)候前端要按照后臺(tái)的規(guī)矩來(lái)玩。

而測(cè)試同學(xué)，在這個(gè)流程的后端，卻要從產(chǎn)品文檔開(kāi)始介入整個(gè)流程，設(shè)計(jì)測(cè)試用例。從產(chǎn)品邏輯，設(shè)計(jì)還原，兼容性問(wèn)題，接口自動(dòng)化測(cè)試，安全問(wèn)題，性能問(wèn)題等都要關(guān)注。

更別提還有運(yùn)維哥要跟著改定時(shí)任務(wù)，優(yōu)化DB等等了。

那么可想而知上游的一些看似微小的變化，會(huì)給下游的人員造成多大的蝴蝶效應(yīng)。

所以，除了我們喊成口號(hào)的“理解萬(wàn)歲”之外，其實(shí)上游的角色應(yīng)該更多的去了解下游的工作，才能更好的推進(jìn)下去。

比如產(chǎn)品運(yùn)營(yíng)同學(xué)可以多了解一下交互為什要這么執(zhí)著，這個(gè)彈窗為什么不能這么彈？

交互同學(xué)可以看看我的交互形式是否太過(guò)限制設(shè)計(jì)，能否有更好的展現(xiàn)形式？

設(shè)計(jì)師多想想，我這個(gè)改動(dòng)到底會(huì)對(duì)頁(yè)面結(jié)構(gòu)有多大影響，這個(gè)設(shè)計(jì)到底是如何變成頁(yè)面的？

前端同學(xué)多想想，我做的模板 JS/后臺(tái) 能不能用？我是否有考慮到各種狀態(tài)的變化，各種擴(kuò)展的能力？

后臺(tái)的同學(xué)多考慮一下我這個(gè)接口真的好用嗎？有沒(méi)有哪些參數(shù)可以省略？有沒(méi)有那些信息不該暴露？是否接口過(guò)于臃腫？是否字段表意不清晰或各處不一致？

測(cè)試同學(xué)多想想，我TM怎么這么苦逼？

運(yùn)維同學(xué)多想想，我TM還沒(méi)說(shuō)話呢，你們也好意思吐槽？

哎，古人云，我住長(zhǎng)江頭，君住長(zhǎng)江尾，滾滾長(zhǎng)江都是水，理解萬(wàn)歲吧。