终于有时间静心想了一下W3CTech的交流话题，觉得还是写一点好，之前裕波同学发来话题的时候，不断觉得这是一个太泛泛的话题，但是后来又思考了一下，这的确是一个值得去讨论的话题：前端工程师究竟如何去与其他岗位协同作业？

首先，这个话题应该从高中低三个层次去切入，由于所谓的协同作业在不同的公司不同的环境，甚至不同的部门都是有差异的，并不是说公司或者部门有高低之分就要分三个层次去探讨，而是我觉得它们之间实在有很大的差异。

低级协作我认为在小型的团队较多，它的角色划分很简单客户（OR 老板）、设计、前端、后台开发，在这个流水线里，前端需求与三方的接触，需求清楚客户提过来的页面互动需求，需求知道设计师的设计意图，需求考虑后台开发的实现接口，这是比较传统的协作方式，或者也有人叫线性的协作，而其实即便是这种陈旧的流水线式作业里，前端仍旧无法高效的任务，具体表现为与客户的沟通不畅，前端工程师切入的是专业的代码级的点，而客户往往关注的最终的效果，与设计师的分离或者脱节，诸如前端抱怨设计对浏览器的无知，或者设计埋怨前端无法完满还原他们的作品，以及不了解后台架构忽略了页面在动态情况下的实现，或者后台开发直接插手前台代码，等等。在这种协作模式里，前端是一个处于弱势的职业角色，而也正由于如此，许多小型公司都基本忽视了这个职位，甚至是设计和前端一人担当，我觉得要在这种模式里，协作效率的提升完全取决与前端的团体能力，如你能用深入简出的话语跟客户去沟通，你能在设计师抱怨的时候跟他讲清楚为何不能实现，你能预留出动态代码的实现DEMO等等，甚至是你涉猎广泛可以跟设计师谈设计构成可以跟后台开发谈后台架构，但是总之，我觉得在这种模式里效率很难得到保证。

中级协作，相应的这种模式下角色划分更为细致，如有产品经理介入，有交互设计以及UE参与等等，最关键的是前端参与进项目流程，他从项目初始就跟进，从专业的角度来协同各个岗位做好这件事。许多的专业web team大体都会这么去配置，在这种模式下前端需求的是比较强的专业影响力，从项目开始时就有一个比较清晰的路线图，在跟进过程中跟每个环节的涉及的人去打交道，把能够促进这件事完满完成的东西加入到环节中去，如去跟产品经理一同讨论最理想的产品架构，跟设计师讨论设计中的细节和交互的实现，跟后台开发讨论代码层级的优化等，在这种模式下效率的提升应该来自比较完善的参与机制，如前端在什么节点介入，介入的深度等等，我认为前端在开始就要介入项目，但不一定要很深入，这样可以充分了解项目背景，前期应该是与相关岗位的人员一同，共同制定一个大纲，当枝节理顺时就可以进入设计环节，在设计环节里跟设计一同确定细节的东西，在产出页面前应该与后台开发就接口做一个提前接入，如给定接口模式之类，最后才是产出页面，当然这还没有完，后面还有测试评估以及不断的版本迭代。

中级协作看似挺完满，但是还是有些遗憾，如这种协作照旧是需求前端工程师的较强的团体能力，无法模式化，我觉得更高级的协作应该是引入前端架构师的角色，关于前端架构师的职能，我觉得简而言之，他就是一个专门去做这些协作任务的人，以下是援用kejun对前端架构师的职业描述：

1. 他需求制定一套跟上下游环节更高效配合的技术方案。具体说有改进模板（视图层）的开发方式，团队内部开发方式，维护和测试方式等。

2. 他要把关各种技术的实施方案。哪种好，哪种有风险，哪种还不成熟，哪种成本高。需求“把握问题的关键，平衡设计”的能力。

3. 他要自动联合相关部门，从功用、易用性、安全性等方面提升产品的价值和竞争力。

4. 他要正确选择适合产品的框架和库（或设计这样的框架和库），建立建全规范体系。保证代码风格的分歧性（处理开发效率的问题）。

5. 他要有前瞻性。引入先进的前端技术落地到具体的产品中。

6. 他要担任团队成员的甄选。

7. 他要能做PPT，向高层布道。

说的比较具体，如果一个团队存在这么一个角色，那么与其他岗位的协作将会是统一和模式化的，前端工程师在架构师的框架里可以更好的发挥本人的专业技能，当然这是比较理想的形状，我觉得在如今的情况下，在团队中可以培养一些前端工程师的架构思想，尝试制定一些协作框架，好的制度永远胜过集体的强大，只要建立高效的协作机制，才能保证在各种良莠不齐的团队中协作的高效。