昨天参加了webrebuild，碰到了很多熟人，也听到了克军关于LSM的分享，包括克军在内，会上很多人怒斥前端开发糟糕的现状和不规范的流程，而且提出很多新颖的团队合作流程，都感觉这些流程太过新颖以至于有些理想化，因为他们忽视了流程中的最关键的因素，人。
这让我想起YUI团队的协作方式，yui的一个build到下一个build之间的流程是模糊的，甚至感觉有些混乱，但有一点是清晰的，两个 milestone之间，任何两个人的合作关系是清晰高效的。也就是说，每个工程师清楚的知道他的前驱在干什么，也清楚的知道他的后继需要他做什么……因为，即使每个人的具体工作不同，但知识总是交叉相错的，工程师懂设计和架构，架构师懂设计和需求，设计师懂需求和开发，在这样一个高水平的人组成的团队中，再罐以复杂的流程约束反而会降低生产率。
因此，回过头来思考一下我们的初衷，不论如何改变流程、如何招人，目的只有一个，提高生产率。那么在人的能力水平没有提高的前提下，一味更改流程是没有用的。这就类似58年的大跃进，GCD试图带着一帮农民搞大跃进，就真的跃进了吗？封建制度一定是在土地霸权产生后出现的，资本主义也一定是在资本家萌芽之后发展起来的，人不改变，而将精力放在制度和流程上？无异于本末倒置，拔苗助长。
看我们的现状，企业往往为了降低成本，招了一群烂本科生进来，不懂信息架构、不懂设计、不懂工程化、对计算机基础学科的理解一瓶子不满半瓶子咣当，甚者仅仅会写一些HTML、CSS和JS……对由这些人组成的团队期望YUI团队的高质量的生产，这是五十步笑百步。在实际情况中，团队成员之间知识结构无交叉所带来的问题远远大于流程的问题。
在看看webrebuild里克军的设想，工程师和设计师同时去follow产品，我认为这个提法没有问题，但是这种流程的可操作性取决于一个大前提，就是产品经理能否产出一个高质量的PRD、PRD是否包含足够工程化的语言和足够丰富准确的内容，在工程师和设计师分别follow的时候不会产生歧义，而且可以合格的做一个设计师和工程师的答疑文档？实际情况是产品经理完全没有能力做到这一点，PRD粗制滥造、不反复修改需求就已经烧高香了。设计师和工程师遇到需求不明确的地方唯有使命的召唤，诉诸面对面的沟通，面对面的沟通看似效率高，其实很多临场的决断都是欠推敲的，会给产品埋下很多不必要的隐患。
ok,说了这么多，问题的关键在于人才的培养，使用健全的培训制度不断为成员输血，提高每个人的知识面和能力。我们不能捡了西瓜丢了芝麻。
另外，我们似乎有一种“流程优化”情结。我觉得完全过虑了。流程是完全可以用工具进行优化的。比如在yahoo，前端代码css、js、img文件要压缩上线，需要首先将js和css代码压缩一份，并将源码check in到svn中，再将其传到一个跳板机上（安全考虑、工作机是无法直接登录cdn服务器的），再传到cdn上。每次上线都会重复这个流程，其实这个流程完全可以用自动化工具搞定，同样提高效率，就没必要再去优化这个流程了。
工欲善其事，必先利其器。
其实使用工具辅助流程优化是一个提高生产率的思路。这里说的工具应当是一个抽象的概念，比如DPL可以是工具（至少他类似于工具书），组件库也是工具，UI设计指南和文档都是工具，我们要做的，就是去构建这样一个高质量的工具箱。
就像Yahoo DPL带给我们的谆谆教诲：构建DPL耗时耗人耗力，但一旦完成，后续开发效率会有飞速的提高！
以上YY，切勿当真…