改需求之路:设计师的一小步,程序员的一大步

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

gaixuqiu

今天我们聊聊那些年设计师的“小改动”,以及上下游协作(设计师、产品经理、开发、运维等)之间的微妙关系。

那些所谓的“小改动”通常在设计师或产品经理的嘴里,有以下几种描述:

  1. 改改文字颜色而已;
  2. 换个图标而已啦;
  3. 只是一些小改动;
  4. 很简单的啦~

可是到了程序员这里,往往就变味儿了:

  1. 这里也要改?
  2. 这里要运营?
  3. 这个布局完全变了啊!
  4. 人与人之间的信任都哪去了?

那么,究竟是什么让人与人之间的信任变得如此淡泊呢?还穿什么安全裤!

首先,从产品人员这里,如果一开始就不信任开发人员,总想把东西往简单了说,或者排上了时间又插需求,那么开发人员也会产生相应的不信任:反正你是要插需求的,不多估算点时间怎么行?

而从设计师的角度,往往设计师的思维更奔放自由一些,同样的设计稿,在设计师眼里就是一副完美的画布任我挥洒。

当然,资深的网页设计师还是熟悉基本的页面布局实现,不过与程序员眼里的结构与逻辑还是两个世界。

所以往往设计师感觉,我的结构没怎么动,只是这里加了个小东西,或者各个元素都调了些位置颜色,因为要符合现在的设计风格嘛。结果到程序员那里就悲剧了:这相当于重做啊!

zj20151224

在完善的开发流程中,上下游的方向是非常牢固的。

产品与交互可以探(si)讨(bi)确定方案,定好的交互到设计师那里,就没有太大发挥余地。

设计师做好的设计稿,到前端开发那里,除了一些特效与实现细节,基本上就是照做而已。而前端开发如果区分重构和 JS,那么 JS 基本也只能拿着重构写好的结构继续开发。

前端跟后台的关系倒不像是真正的上下游,应该说是并行的,甚至大部分时候前端要按照后台的规矩来玩。

而测试同学,在这个流程的最后端,却要从产品文档开始介入整个流程,设计测试用例。从产品逻辑,设计还原,兼容性问题,接口自动化测试,安全问题,性能问题等都要关注。

更别提还有运维哥要跟着改定时任务,优化 DB 等等了。

那么可想而知上游的一些看似微小的变化,会给下游的人员造成多大的蝴蝶效应。

所以,除了我们喊成口号的“理解万岁”之外,其实上游的角色应该更多的去了解下游的工作,才能更好的推进下去。

比如产品运营同学可以多了解一下交互为什要这么执着,这个弹窗为什么不能这么弹?

交互同学可以看看我的交互形式是否太过限制设计,能否有更好的展现形式?

设计师多想想,我这个改动到底会对页面结构有多大影响,这个设计到底是如何变成页面的?

前端同学多想想,我做的模板 JS/后台 能不能用?我是否有考虑到各种状态的变化,各种扩展的能力?

后台的同学多考虑一下我这个接口真的好用吗?有没有哪些参数可以省略?有没有那些信息不该暴露?是否接口过于臃肿?是否字段表意不清晰或各处不一致?

测试同学多想想,我 TM 怎么这么苦逼?

运维同学多想想,我 TM 还没说话呢,你们也好意思吐槽?

哎,古人云,我住长江头,君住长江尾,滚滚长江都是水,理解万岁吧。

 

作者:姬小光,《精彩绝伦的CSS》译者,腾讯前端开发工程师

原文地址:http://www.uisdc.com/influence-of-requirement-change

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中