上文讲到过分工不合适的原因，这次想和大家探讨一下我的一些关于如何解决问题的想法：

　　1. “架构＋设计＋研究”的分工
　　简单地说，就是架构组负责底层建设和方向引领𓆉，设计组负责设计和实现，研究组负责（部分的）用户研究和可用性测试。详细介绍可查ও看以前写的《说说互联网公司内设计师的分工》。这种分工能够解决上述的大部分问题。

　　此外，正如jean.ma所说，在项目内的分工，应遵循“按模块而非角色”的方式来进行（这点我在《说说互联网公司内设计师的分工》也说过），就是不同的设计师负责产品不同的部分，然后由一名总设计师来统꧋筹兼🦄顾。

　　2. 知识管理、文档管理和版本控制
　　专门设立一台服务器，使用开源工具（比如Drup꧟al），将所有的项目相关文档都进行集中的统一存放和管理，使任何事情有据可查，减少沟通成本，消灭“产出物发给了A部门，忘了发B部门”，或是某💮人说“我找不到你发的Demo了再发一次”的问题。

　　如果你的部门使用Dreamweaver作为设计和开发工具，那⭕就更💃好了！让架构组把最新的Dreamweaver模板和代码片断上传到服务器上，然后每个人打开Dreamweaver时第一件事情就是更新本地模板和代码片断（DW早就有此功能），这样不仅协同起来效率很高，而且质量可控性很好。可以说，这在一定程度上实现了开发使用Eclipse+SVN进行协同工作的效果。

　　至于版本控制，一方面，给每一份产出指定一个唯一且明确的版本号，所有项目组成员交流时以版本号而不是“最新”一𒅌词为准，消ꦯ灭歧义和不确定性。

　　另一方面，如果你使用CVS或SVN进行版本控制，一定要把我们设计或开发的版本（也就是使用CVSও或SVN进行版本控制的版本，以下简称trunk版）和给项目组演示的版本（采取手工方式进行版本💦控制，以下简称milestone版）分开，这样不仅可以加快我们的开发效率，更重要之处在于减少许多沟通成本。

　　比如，假设你上午9点通知业务部门及开发部门，说某项目的Demo已经做好，访问服务器即可查看，一般情❀况下你并不能保证所有人都在接到你的通知后立即查看 Demo，很可能有的人是在9：30分看到，有的在10：00看到，甚至有的在第二天才看到。这期间你很可能会根据业务部门或是开发部门的反馈对Demo 进行了修改（哪怕是小修小补），那么这样一来，大家讨论的基础 - 统一的版本就不复ꦯ存在了。

　　我们可以借鉴程序员的做法，将trunk和m🍒ilestone分开：平时在trunk上提交各类修改，如果需要展示给他人，则另外拷贝一份milestone版本（或新打一个分支，但此时意义不大）。比如你调试和预览的地址为 //ued꧑-server/demo/project-a/ ，当需要展示时，将project-a目录复制一份到 //ued-server/demo/project-a/milestones/1 ，并以此作为第一个milestone。项目组成员在沟通时，都以milestone为基础。

　　3. 把视图（view）交给它本来的主人－前端开发（甚至设计师）－去处理
　　由于模板里常常混杂着HTML和程序语言（暂且以PHP为例），而这两种东西又分别来自于UED和开发两个部门，因此无论是编写还是调试模板，都要牵涉前端开发和程序员的精力。工作职责模糊不清，权责也很🔯难界定。关系好的程序员曾私底下和我报怨说“如果连HTML/CSS/Javascript这些东西我们都写了，还要UED的人干吗”，虽然🎃HTML/CSS/Javascript我都是尽可能完整产出，并且这句话也有其偏颇之处，但我仍对此深觉惭愧。

　　“模型（model）－视图（view）－控制器（controller）”架构的重要目的之一，就是把视图尽可能与逻辑和数据分开。当以模板的形式把视图分出来以后，为了尽可能地降低模板的复杂性、又同时保持模板具有一定的逻辑和数据处理能力，让不那么熟悉程序的人也能够控制如何显示，人们才开发了各种模板语言，比如PHP中的Smarty和Java中的Velocity。也就是说，这种极度简化的模板语言就是专门给设计人员提供的，它甚至不会比Javascript更复杂ജ！

　　当把视图部分的工作完全交给UED后，开发和UED的合作可以以这样的方式进行：1）UED提供原型；2）开发按照原型提供所需𒅌的逻辑和数据（通常是一大堆if...🍌else...和$username等变量）；3）如果有必要，可以要开发按原型来写一个不考虑内容及样式的模板，模板里包含了所有必须的逻辑和数据；4）UED将逻辑、数据和各种前端代码编写进模板。

　　这个方案我曾和系分及程序员讨论过几次，我们🦄都认为它是可行的。出于可维护的角度考虑，他们其实也愿意将模板的编写工作交给UED。

　　此༺方案的优点是显而易见的：开发和UED终于可以真正地各司其职，大家权责明确，从项目管理的角度来说，UED的工作时间计算也更为准确，以前那种“UED协助调试模板，花了大量时间却没有被记录进项目”的情况不会出现。

　　缺点当然也不是没有，在方案实施初期，UED一定会有ಞ阵痛，尤其是对那些从没🐎有接触过后台编程的设计师。

　　4. 强调工具和规范的重要性，而非某个人的聪明才智
　　天涯上前段时间流行一篇名为《做单》的小说，里面有一句话印象很深：

　　“外企更像是一个集团军……民营企业都像是个游击队或者是特种部队……集团军最大的特点就是随便换掉某个人或者某几个🍸人对整个军队没有任何影响，游击队就不能承受这种变化。

　　国内的企业面临最大的问题就是从游击队向集团军的转变中，因为人意识的转变跟不上，而导致转型失败……一个民营企业要想做大，必须经历这种从游击队向✨集团军ﷺ的转变。”

　　关于规范说得够多了，还是说说工具吧。

　　从团队的角度来说，工具主要的目的就是最💮大限度地统一和标准化产出物，提𓃲升团队的工作效率和质量。因此以下提及的工具都是与这个目的相关：

　　Dreamweaver。它内建Templates和Code snippets功能，并支持从服务器上同步，如果整个部门都使用Dreamweaver的话，那么大家的Templates和Code snippets就全是规范的；
框架。无须赘言，好的框架可以让你3分钟做完原本需要10分钟的事情，并且产出物（典型如代码）高度规范；
文档库。比如前文提到的VelocityDoc，有了这东西，设计师可以在短时间内了解整个网站的模板，包括模板整体的结构、每个模板的作者、功用、所引用的CSS/Javascript，以及它所属的layout和所包含的control/element等等。对于新同事来说，文档是最好的老师；
封装。努力地将常用的东西封装成模块，避免重复劳动，同时也能降低对设计师的技能要求。比如说对于表单界面，交互设计师根据不同的错误情况，需要制作出不同的原型，费时费力，还容易出错，如果封装一下，设计师只按照一定格式提供错误提示的内容就好了，剩下的什么都不用管，全交给系统自动处理。
上面讲得有点太干巴巴了，这里有一个06年做的东西－代码助手－算是上述思想的一个集中体现吧。

　　关于分工的话题暂且到此为止吧，这么枯燥冗长的内容不知有多少人可以坚持读完，呵呵。

　　原文：//heartstringz✅.net/blog/posts/view/why-noꦺ-division-in-web-design-2