今天我们聊聊那些年设计师的“小改动”，以及上下游协作（设计师、产品经理、开发、运维等）之间的微妙关系。
那些所谓的“小改动”通常在设计师或产品经理的嘴里，有以下几种描述：
- 改改文字颜色而已；
- 换个图标而已啦；
- 只是一些小改动；
- 很简单的啦～
可是到了程序员这里，往往就变味儿了：
- 这里也要改？
- 这里要运营？
- 这个布局完全变了啊！
- 人与人之间的信任都哪去了？
那么，究竟是什么让人与人之间的信任变得如此淡泊呢？还穿什么安全裤！
首先，从产品人员这里，如果一开始就不信任开发人员，总想把东西往简单了说，或者排上了时间又插需求，那么开发人员也会产生相应的不信任：反正你是要插需求的，不多估算点时间怎么行？
而从设计师的角度，往往设计师的思维更奔放自由一些，同样的设计稿，在设计师眼里就是一副完美的画布任我挥洒。
当然，资深的网页设计师还是熟悉基本的页面布局实现，不过与程序员眼里的结构与逻辑还是两个世界。
所以往往设计师感觉，我的结构没怎么动，只是这里加了个小东西，或者各个元素都调了些位置颜色，因为要符合现在的设计风格嘛。结果到程序员那里就悲剧了：这相当于重做啊！
在完善的开发流程中，上下游的方向是非常牢固的。
产品与交互可以探（si）讨（bi）确定方案，定好的交互到设计师那里，就没有太大发挥余地。
设计师做好的设计稿，到前端开发那里，除了一些特效与实现细节，基本上就是照做而已。而前端开发如果区分重构和 JS，那么 JS 基本也只能拿着重构写好的结构继续开发。
前端跟后台的关系倒不像是真正的上下游，应该说是并行的，甚至大部分时候前端要按照后台的规矩来玩。
而测试同学，在这个流程的最后端，却要从产品文档开始介入整个流程，设计测试用例。从产品逻辑，设计还原，兼容性问题，接口自动化测试，安全问题，性能问题等都要关注。
更别提还有运维哥要跟着改定时任务，优化 DB 等等了。
那么可想而知上游的一些看似微小的变化，会给下游的人员造成多大的蝴蝶效应。
所以，除了我们喊成口号的“理解万岁”之外，其实上游的角色应该更多的去了解下游的工作，才能更好的推进下去。
比如产品运营同学可以多了解一下交互为什要这么执着，这个弹窗为什么不能这么弹？
交互同学可以看看我的交互形式是否太过限制设计，能否有更好的展现形式？
设计师多想想，我这个改动到底会对页面结构有多大影响，这个设计到底是如何变成页面的？
前端同学多想想，我做的模板 JS/后台 能不能用？我是否有考虑到各种状态的变化，各种扩展的能力？
后台的同学多考虑一下我这个接口真的好用吗？有没有哪些参数可以省略？有没有那些信息不该暴露？是否接口过于臃肿？是否字段表意不清晰或各处不一致？
测试同学多想想，我 TM 怎么这么苦逼？
运维同学多想想，我 TM 还没说话呢，你们也好意思吐槽？
哎，古人云，我住长江头，君住长江尾，滚滚长江都是水，理解万岁吧。
作者：姬小光，《精彩绝伦的CSS》译者，腾讯前端开发工程师
原文地址：http://www.uisdc.com/influence-of-requirement-change
I 相关 / Other
源码介绍HTML5响应式简洁企业织梦整站网站模板程序采用的响应式自适应布局设计，页面设计简洁大气，设计包含
我使用了左右镜像的Sierpinski triangle，每层减去上方一小块，再用符号点缀。可生成不同层数的「圣诞树」，
Windows下搭建ReactNativeAndroid开发环境详解
最近看到React Native好像好厉害的样子，好奇心驱使之下体验了一下并将在Window下搭建React Natvie Android
好设计是创新的、有功能性的、帮助产品被使用者理解；也是谦虚的、耐久的、与环境共生的。良仓设计大赏旨在
我们已经从SVN 切换到Git很多年了，现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git,