在UED里，前端同学需要处理的需求比较多，早些时候，前端这里的开发流程还是比较模糊的，UED以外的同学也不清楚这边的工作具体是怎样进行的，所以难免会有需求插队的情况发生，打乱了大家的计划，因此今年Q3的时候，在与SCM团队同学的共同努力下，形成了一个前端的ASSETS发布流程。

这个流程主要针对ASSETS发布的需求做了一些约定，制定了相关的几个时间点，包括审核需求、提交代码、daily测试、预发测试、正式发布到线上确认的时间。

ASSETS流程简述

需求审核

在提需求之前，需求方一般都会先找PM或者相应产品线的前端咨询一下，如果可行的话就会在周四之前将需求提到平台上，到了周四的时候，前端会结合自身的工作情况，将平台上的需求接收并纳入自己的日程中，预估完成时间、发布时间以及相关的发布简述。

编码开发

周四需求评估完以后，就会按计划开始处理需求，将涉及ASSETS发布的需求优先处理，不涉及ASSETS的放在靠后的时间处理，一般这段时间是从周四到下一周的周二。SCM会在每周四开一个新的ASSETS分枝供前端在下一周开发使用。

提交代码，合并到daily测试以及预发测试

如果有涉及到与后台开发相关的需求，前端的同学会在周一就把代码提交，这一天会有一次合并代码，方便后台开发来测试。其他的同学一般最晚会在周二下班之前把代码提交，在周二，会有多次合并代码到daily的操作，每次操作完后，SCM的同学会在前端的群里通知到大家，方便大家测试。

周三早上，SCM的同学会将代码发布到预发环境，此时就可以在HOST中绑定IP，换用线上的地址来测试。

正式发布

周四上午，SCM的同学确认后，将没有问题的代码发布上线。

流程的作用

在团队不断成长的过程中，处理的需求数量也在增长，需要考虑到开发的效率、产品的质量以及团队协作间的配合等因素，这个流程能为我们解决很多相关的问题：

督促需求方做好相关的规划

有些时候，一些需求的细节还没完全确定，但需求方总希望能将他想到的各种细节都实现出来，然后再挑选其中一种做为他的方案，所以需求的变更会有些频繁，然而这样的成本有些高，一切应该在计划后再去实现，而非反其道而行。现在需求方会在提需求之前，会花时间地去考虑他们的需求，将尽可能多的情况都想清楚，做好必要的沟通工作，权衡各种利弊之后，再给出一个比较成形的方案。

保证需求安排的有序性

在一个大的团队中，不同部门的同学在一起合作，因为沟通及一些特殊情况，效率或多或少会受到一些影响，良好的规划能有助于提高开发的效率。

通过每周的需求审核，安排好下一周的日程，由于需求的优先级和先后顺序都已排定，工作的条理性会更加清晰，需求插队的现象也有明显减少。当然我们也有紧急流程，但是它仅限于处理线上bug以及一些经过多方确认的紧急需求，有其自己的适用范围。

统一测试，归避风险

之前的日常处理中，可能会遇到这样的情况：甲、乙两个同学分别需要处理两个日常需求，他们的需要改动到的代码会有重合的部分，如果他们并不知道这个情况，那么在他们本地的单独测试中，一切都是OK的，然而当发布到线上去时，发现出了bug或者一方的改动没有同步到线上，查原因后发现是提交的代码相互覆盖了。

现在要处理的需求数量越来越多，为了避免上述情况，新流程实行以后，大家会统一来做多次测试，这样就更容易发现bug，可以大大降低协作开发而产生的风险。

流程本身就是一把双刃剑，有利有弊。一方面，它使我们的需求变得有序，使前端能够在处理一个需求时，不会频繁被其他插队的需求打断。并且因为发布有时间点的设定，所以测试工作会更加严谨，这有助于提升代码的质量。因此对于我们来讲，流程带来的好处是显而易见的；但另一方面，它额外地增加了做事的成本，涉及ASSETS发布的需求，就像赶某班火车一样，错过了就只能等下一班，所以也给需求方带来了许多不便，有待改进，不过这可以通过长期的合作而慢慢被弱化，双方达成了一种默契以后，情况会好很多，现在这样的情况已经比较少了。

尽管在流程使用之初，会带来诸多不便，但是从长远来看，流程有助于使一个团队形成统一的工作方式和态度，将繁杂的事情化整为零，有条理地去处理它们。因为流程，每一个人的责任感都会增强，对风险考虑得会更多一些，这一切都会使产品有质的提升。而我们所有与这个流程有关的人，都会不断地去推动流程改进的工作，这其中还有很多需要思考的：

* 如何将我们的流程推广到整个公司，让大家都能了解我们的流程，这样在未来需要合作时，需求方需要注意些什么，相关的时间点以及开周时间的预估等，他们就会心中有数。
* ASSETS的发布还不够灵活，如果把和应用相关的ASSETS独立划分出去与应用一起发布，这样剩下的需要发布的东西就会少很多。或者是按产品线来设计发布流程，根据实际情况来发布。
* 如何来简化流程上的一些细节，在保持效率的同时，降低实际操作中的成本。
* 每周二是一个特别的时间点，为了赶在这最后时间提交代码，之前的开发会有些紧张，这种情况也有待改善，比如未来可以一周有两次发布。

流程不是生来就完美，但从现在它带给我们的好处来看，遵循并使用它，对我们的开发会起到很大的帮助作用。我们对待它的态度，决定了它对我们会有怎样的反馈，如果觉得它不合适了，就发出自己的声音，想办法去改进它，不要只是被动地等待。

———————————-

部分名词解释：

daily环境：UED的一个日常测试环境
预发环境：外网IP，需绑定访问，供内部使用测试
ASSETS：脚本和样式存放的目录
SCM：软件管理配置
PM：项目经理

二 产品原型
主要执行人员：UI、UE、需求部门
需沟通人员：程序部、销售部
在产品原型方面,主要指的是黑白稿或线稿，除了颜色基本采用黑白的形式，最终出的产品原型将会和实际产品没区别。这个环节会拟定出产品页面的宽度,广告的形式,导航基本样式,各内容的区域的表现形式等…
当经过可行性评估阶段后,产品经理的思路和自己也基本达成共识，接下来将进行原型设计，我将主要分为三个步骤来实现：
1) 　纸稿

一般情况下结构图都是采用word文档描绘，我选择笔和纸的方式，主要还是比较方便、易修改，有任何突发的思路只需要擦一下，就可以直接在已有的基础上进行调整，由于之前的讨论没有实物参照，在这个环节你一定会发现更多有趣的问题。
2)　线稿、黑白稿

当纸稿确定后，则由UI或UE使用做绘图工具来描绘黑白稿(我主要使用Photoshop来进行这个步骤，跟据个人习惯不同，大家的方式也有所区别，比如淘宝UED Team及Baidu UE更多的则采用线稿的形式)。也许是做UI的原因，我习惯还是采用黑白稿，方便界面设计，在结构上也会精确到像素,比如:导航高度40px.头条采用20px黑体,图片规格:104×85px,页面的各区域的留白为5px…等等，只有这样才会发现更多细节上的问题，当然到界面设计的同时你也会尝到更多的甜头。
3) 原型

完成以上的二个步骤后,产品的基本功能,结构,规范都已经大致成型.这时你可以叫上程序部、销售部及需求部门产品经理，在白板上对着黑白稿做最终的讨论。经过二次、三次调整，最终定下完整的产品原型。
另外，值得提的一点是，在产品原型未确定前,千万别急着去做界面设计,因为之前的讨论主要会通过白板、Word或纸稿。在原型未确定前，有很多潜在的问题 表现不是很直白，比如：”窄了、窄了，完了，新闻列表只能放八个字”、”广告放不下了”、”数据提不出来，目前没这个接口…”。如果提前进入界面设计的环 节,一但有问题，就意味着重新又需要找产品经理、技术部、销售进行再次沟通，这个步骤是很烦琐的,也会让人很郁闷的。
三 产品界面设计
主要执行人员：UI、UE、需求部门
需沟通人员：UID、SEO
目前产品的雏形已基至的本成型，虽然还没华丽的外衣，但凹凸有至身型已隐约可见。下一步将进入界面设计阶段.设计师们也将再次体会到黑白稿给他带来的各种便利.
1) UI
我的习惯是,主要针对首页进行风格设计，并出3-4套界面,最终挑选出2套左右提交给需求部门,同时也会指出自己最满意一套，和需求部门进行二,三次碰撞后,最终拿出定稿。

2) UE
UE则开始针对原型进行操作上的优化调整,召集用户并组织头脑风暴,收集到相关意见后，由UE整理出交互及用户体验方面改善意见,并反馈给UI及需求部门。比如:”这个文字需要加下划线”、”按钮上不要加样式,反而没有点击的欲望了…”。
3) UID
UID即开始着手准备制作方面相关文档.并提出实现方面的意见.等待效果图最终确定后,则开始相关代码的编制(CSS+DIV、AJAX、Java)。
4) SEO
SEO则根据原型提出搜索引擎优化的意见,为制作阶段代码优化做准备.
这个阶段一定要保证与需求部门沟通到位,当产品界面最终定稿后,建议再组织一次讨论,这次用户面对着是实实在在的产品,所感受会和之前有所不同.对产品效果上来说,这次的讨论也会有不少收获。
四 界面设计规范及功能实现
主要执行人员：UI、UE、程序、SEO
需沟通人员：UE、销售
1) 设计规范
考虑到在动态实现方面,光凭效果图很难直接的给予表现，这时需要配合使用说明文档及设计规范规范来做辅助。比如按钮及文字链在触发前后的样式,文字间距…。如下图：

2) 代码及程序开发
由UID进行页面的代码开发（CSS+DIV），并需严格参考SEO理出的相关规范，针对一些AJAX的动态效果还需要程序部人员协助完成，当静态HTML完成后即由技术人员进行程序嵌套，并实现预期的功能。
这个阶段由UI、UE全程跟踪，保证HTML和设计稿最大限度相似前提下，对已实现的功能进行测试，并出交互设计改善文档，提交给技术人员。
五 产品上线
主要执行人员：需求部门
需沟通人员：UI、UE、程序、销售
这个阶段主要是内容的添加，主要由相关频道编辑完成，对于软性广告位这块还需要和销售进行协调。完成内容添加后，由需求部门、UI、UE进行核查，在保证和内容、功能完整后，进行整体上线。
六 分析报告及优化方案
主要执行人员：UE
需沟通人员：UE、UID、程序、需求部门、 销售
产品上线后，由UE进行数据及意见的收集，在二周后出相关改善文档，协调各部门进行优化的工作。