上文讲到过分工不合适的原因，这次想和大家探讨一下我的一些关于如何解决问题的想法：
1. “架构＋设计＋研究”的分工
简单地说，就是架构组负责底层建设和方向引领，设计组负责设计和实现，研究组负责（部分的）用户研究和可用性测试。详细介绍可查看以前写的《说说互联网公司内设计师的分工》。这种分工能够解决上述的大部分问题。
此外，正如jean.ma所说，在项目内的分工，应遵循“按模块而非角色”的方式来进行（这点我在《说说互联网公司内设计师的分工》也说过），就是不同的设计师负责产品不同的部分，然后由一名总设计师来统筹兼顾。
2. 知识管理、文档管理和版本控制
专门设立一台服务器，使用开源工具（比如Drupal），将所有的项目相关文档都进行集中的统一存放和管理，使任何事情有据可查，减少沟通成本，消灭“产出物发给了A部门，忘了发B部门”，或是某人说“我找不到你发的Demo了再发一次”的问题。
如果你的部门使用Dreamweaver作为设计和开发工具，那就更好了！让架构组把最新的Dreamweaver模板和代码片断上传到服务器上，然后每个人打开Dreamweaver时第一件事情就是更新本地模板和代码片断（DW早就有此功能），这样不仅协同起来效率很高，而且质量可控性很好。可以说，这在一定程度上实现了开发使用Eclipse+SVN进行协同工作的效果。
至于版本控制，一方面，给每一份产出指定一个唯一且明确的版本号，所有项目组成员交流时以版本号而不是“最新”一词为准，消灭歧义和不确定性。
另一方面，如果你使用CVS或SVN进行版本控制，一定要把我们设计或开发的版本（也就是使用CVS或SVN进行版本控制的版本，以下简称 trunk版）和给项目组演示的版本（采取手工方式进行版本控制，以下简称milestone版）分开，这样不仅可以加快我们的开发效率，更重要之处在于减少许多沟通成本。
比如，假设你上午9点通知业务部门及开发部门，说某项目的Demo已经做好，访问服务器即可查看，一般情况下你并不能保证所有人都在接到你的通知后立即查看 Demo，很可能有的人是在9：30分看到，有的在10：00看到，甚至有的在第二天才看到。这期间你很可能会根据业务部门或是开发部门的反馈对Demo 进行了修改（哪怕是小修小补），那么这样一来，大家讨论的基础 - 统一的版本就不复存在了。
我们可以借鉴程序员的做法，将trunk和milestone分开：平时在trunk上提交各类修改，如果需要展示给他人，则另外拷贝一份 milestone版本（或新打一个分支，但此时意义不大）。比如你调试和预览的地址为 http://ued-server/demo/project-a/ ，当需要展示时，将project-a目录复制一份到 http://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年做的东西－代码助手－算是上述思想的一个集中体现吧。
关于分工的话题暂且到此为止吧，这么枯燥冗长的内容不知有多少人可以坚持读完，呵呵。
