编码人员和美工的配合问题
公司的项目都是基于B/S结构的，绝大多数操作界面都是通过网页的形式展现在用户面前的，页面的美观就成了非常重要的问题。记得去年的这个时候公司迎来了它历史上的第一个专职美工。同时到来的就是程序员与美工的合作问题。
矛盾篇：
公司以前的系统都是由程序员来编写界面的，美观与否先不必说，单从效率上讲就是一个很大的问题。大部分时间都花在了界面的编写上，严重影响了项目的 进展速度。美工到来以后，页面的美观程度和制作速度都有了很大提高，随之而来的程序员与美工的配合问题又成了一个新的问题。其中主要的问题、矛盾有以下几 点：
1． 1. 美工何时参与到项目中来
2． 2. 程序员不懂如何将页面弄得美观，美工也不懂如何向页面中添加代码（即使是使用了Velocity）
3． 3. 程序员和美工是两种完全不同的人，他们关心的事情也完全不同，这就导致两种人对页面代码（html）风格的要求大相径庭——程序员要得是简单易懂，美工要得是美观漂亮
4． 4. 程序员要做的是将数据展现在页面上（使用简单的条件、循环语句），美工要做的是将美丽充满整个屏幕（程序员会叫道：天哪！这么复杂，我怎么用if、else、for来实现）
解决篇：
上面的这几点问题和矛盾从关系上来讲是层层递进的，要一个一个依次解决。先来说说美工何时介入到项目中来，在公司做过的这些项目以及我听说过的项目 看，大致有以下几种：1）先有美工制作静态页面，完成后程序员直接向页面中添加程序代码；2）程序员随时和美工沟通，向美工描述页面需求，随要随做；3） 程序员自己编写测试页面，然后让美工进行美化。
这3种方式可以说是个有利弊。方式1）对程序员来说绝对是个喜讯，它能使程序员最大限度的远离那些烦人的页面编码，提高程序员工作的含金量。同时， 一套完整的页面可以展现全部业务的流程，对程序员开发也起到了规范的作用。但这种方式对美工的要求极高，美工要了解项目的需求，而这一般是达不到的。但可 以让了解需求的人为其讲解，或是描绘出希望的页面的样式。这样虽然可以弥补美工对业务了解的不足，但也确实花掉了很多时间（而且是花掉了比较重要的人物的 时间，因为了解整体业务的一般都是公司的牛人，他们的时间可是一刻千金呀）。方式2）是一个比较折中的方法，这样做无需太多的准备就可开始编码工作，程序 员把握页面内容和样式，向美工详细描述，美工再根据描述设计页面，最后返回给程序员添加代码。这个反馈的过程一般比较迅速，效果也不错，可以达到程序员预 期的效果，适用于项目时间要求比较紧的情况。该方式的问题在于没有一个形象化的完整的流程可供程序员参考，一切掌握在程序员手中，容易造成对需求的贪污和 系统整体风格的不统一。方式3）一般用于对已有项目的美化上，对美工的要求也很高，她们需要具备在html和其他代码混合体的环境下工作的能力。而且修改 的效果一般不是很佳，不到万不得已不推荐使用。
问题2.3.4.虽然表现出来的问题各不相同，但解决的方法却很相似。首先，美工要养成一些程序员编码时惯有的习惯，比如：文件命名要有意义、 html代码要根据层次进行缩进等。其次，页面代码的一些细节也要注意，比如，使用居中或右对齐标签来取代空格，必须使用空格时也要用 “ ”，不使用<p>标签，尽量使用表格等。再次，如果在条件允许的情况下，美工也可以学习一下夹杂在页面中的各种程序代 码，了解其语义和工作原理，这将对与程序员的合作起到很大的帮助的。最后，就是程序员要在向页面文件中添加代码前先对页面代码做一下审核工作，在这里并不 是看美工的页面是否美观，而是看在原有页面代码的基础上是否能够使用简单的条件、循环语句来显示数据（比如，页面布局过于复杂，不能通过简单的循环来显示 所有数据），否则就需要修改页面代码直到能满足要求为止。
做网站后台的流程一般是这样的：
一、网站规划阶段
这个阶段主要是对网站的功能、目标受众、内容、栏目进行规划。这期间会经常性地和有关领导进行沟通。首先，自己一定要对网站的整体规划清清楚 楚，然后要吸收别人的建议。吸收别人的建议的过程，可以认认真真地做，也可以走过场，但是有这个过程以后，别人才不会对你的规划说三道四。
至于领导的意愿，和你的规划靠得上边的，你一定要让领导明白，他们的设想已经在你的规划中被考虑进去了。
项目的大致进度，要在这个阶段结束的时候确定下来。
二、后台模块划分和版面设计
这个阶段，程序员要和美工兵分两路分头行动。
后台模块划分如果做好了，后面的效率会高一些。这个过程不能省。
版面设 计，美工既要考虑网站整体规划，又要考虑大家的建议，尤其是不能忽视领导们的观点（虽然大多数情况下领导的美术细胞少得可怜）。在这个大前提下，再兼顾美 观、合理。一个好的美工，不仅仅能做出漂亮的页面，还要能迎合一下客户或者公司领导的意愿，而且能和程序员进行沟通。
在这个阶段，程序员和项目经理（项目负责人）要拿出一个可操作的模块划分方案，而美工要确定网站的版面框架、美术风格，做出网站首页和二级页面。
实际上，在第一个阶段（网站规划阶段），美工就应该开始思考网站的风格了。在第二个阶段，则需要把比较抽象的初级设想变成具体的页面。基本上，首页定了，整个网站的页面就定了一大半了。
在这个阶段结束的时候，要将项目的进度计划进一步具体化。
三、数据库设计
这项工作很重要。但是程序员应该知道怎么去做。而且数据库设计是和一个人的理论水平、实际经验息息相关的，不是几句话能说明白的。大的、复杂的站点，数据库规划可能要用一周左右的时间，小的、简单的站点，数据库设计也需要2到3天。
在这个阶段，美工最好别闲着，继续完成页面设计。要知道下一个阶段，程序员可就要用到美工的页面了。最好别出现这样的情况：程序员要用到某个页面，而美工还没有把那个页面确定下来。
四、后台程序编码
这个阶段，程序员要紧张工作，会比较辛苦的。
程序员需要遵守的三个原则：
1、团队合作；
2、保证进度；
3、保证质量。
美工这个时候要辅助程序员做页面。这个阶段美工可能比较闲，但是一定要称职。
项目经理该和客户或者领导沟通的时候，一定要沟通。
五、除错、改进、页面美化
这个阶段，不多说了。项目经理和客户、领导的沟通，仍然是很重要的。
经验之谈
我自己摸索下来感觉小山之方式2将来更能使团队发挥好，但需要更科学合理地来分角色，做到各司其职，才能避免陷入作坊式开发。
我就大致描述一下我的项目团队（算上美工5人）在这方面的情况：
首先，介绍角色：
１．项目组长：相当于项目经理吧，主要职责我就不多说了。
2.界面工程师：是用户界面交互方面的专家，决定与用户交互的方式，当然很大程度也影响着界面
3.美工：设计和美化界面
4.高级程序员：设计总体程序结构，制定技术上的规范，并为小组解决各种难题，帮助项目组长分解每日程序员任务
5.程序员：编写代码，实现功能
6.需求人员：与本话题无关，我就不介绍了
7.公关人员：虽然与本话题无关，但我就想在这里突出其对项目组的重要性，所以顺便提一下。至于要攻什么关大家一定都能猜得出来。
8.其他，如测试人员、文档管理人员等(想象能有plmm角色)：都很重要，但也与本话题无关。
工作流程：
1.公关人员和需求人员获得用户需求，并制定需求文档。
需求的正确与否是项目成功的首要关键环节，这个我就不多说了，和本主题相关的就是他们需要获取到用户的各种习惯层次上，主要分为两种思路来整理，一种是之 前用过软件系统的考虑如何延续他们的习惯，另一种是之前没有用过软件系统的考虑如何适应他们原有手工的工作流程，并作出合理化的改进。
2.项目组长和需求人员以及高级程序员共同根据需求制定大体的设计方案，包括总体模块和各个可行性功能。
在这里，项目组长会根据需求人员和高级程序员的意见来合理安排出一个基本雏形，然后去写Project2003（我觉得这个蛮不错）...后面还有反复交 复雏形给用户确认等等我就不介绍了。有一点值得注意的是，项目组长除了需要具备一定的人员管理方法以外，最好还是要懂得技术，这样能够制定出更合理、更准 确的项目进度，也能带动团队工作的士气。个人认为项目经理的技术水准应该在高级程序员之上，不然在这个环节中就只能听取高级程序员的意见了，相信大家如果 遇到个不懂技术的项目经理，而他又指责你技术水准有问题时，一定都会自然而然地产生想K他一把的冲动，这样的团队还能保持好的士气么？技术人毕竟还是需要 以能耐服人来得好。
3.开工，项目组长在高级程序员配合下根据预先计划开始推动项目进展。
这里是关于本主题的主要环节，首先由项目组长和高级程序员在上一环节设计的雏形的基础上按照计划规划架设各模块的基本结构。然后以模块为单位，我这边团队喜欢采用我们称之为狼群战术的方法来逐步蚕食各个模块，每个模块的流程分为如下几个步骤
a.高级程序员详细化拆分该模块的各个界面和功能，包括前台和后台等。需要需求人员给出参考
b.在高级程序员的分配下，界面工程师对当前子模块制定界面用户交互的基本方案，也需要需求人员给参考，美工人员则给出美学方面的建议，并达成一致。在这 里，界面工程师会将决定界面的大致框架，并将界面相应的功能描述成文以用于给程序员，一个子模块界面的雏形在这里已经诞生，生成的程序文件有aspx和 (vb或cs)，建议界面结构最好用表格来设计。
c.美工去做界面，对界面工程师所搭建的界面框架aspx或ascx文件进行处理，如背景、需要配合的图片图标及flash等。在这里环节上，美工已和界 面工程师已经在明确需求人员的指导下达成对界面统一风格的一致。因为界面工程师在之前已经在页面中制定好标记，所以美工可以忽略有脚本标记的地方。而且， 总的来说这一环节上美工主要是预先为界面定义好各种素材。
d.与美工并发执行的是高级程序员与程序员对功能的实现。程序员们在界面工程师的指导下将功能实现，其间包括满足交互功能所需的控件、业务规则层、数据访 问层，等等的实现，所涉及编写的文件则为界面文件(ascx等)和程序文件(vb或cs)。这里需要说明的是在实现功能时程序员只要把满足功能的控件拖到 大致位置就可以，然后就关注功能的实现。而此时美工也在设计该界面，但因为只是设计素材，所以根本不与程序员冲突，在后面的环节中始终以程序员完成的程序 文档为准。
e.程序员完成功能后，转交测试人员进行功能测试。。。
f.基本测试通过后，又回到界面工程师手里，在不改动程序文件(vb或cs)文件的前提下，界面工程师只对界面文件中的各种控件、结构等进行调整。达到满意的效果为止。
g.界面基本已经诞生，只是xx不太文雅，所以这时回到美工手上，给其穿上美工设计的靓装，加上各种图片背景等就ok了
h.补充一下项目组长，贯穿整个过程，负责团队人员之间的协调，监督项目进度，合理分配任务，看谁不干活就。。。
4.所有模块都完工后，就是整体的衔接和测试，然后反复交复用户征求意见，这里参与的是团队所有的人马，一直忙到最后期限为止，然后再延期，直到用户满意。
以上是我所在团队的大致工作流程，大家看了后一定会提出如此分角色人手资源一定不够的问题。确实，通常来说小公司的开发团队就几个人，所以通常很容易做着 做着就陷入作坊式做法，大家角色不明确，各自包办各自的模块，导致之后程序维护非常困难。我上面所述的工作流程中每个环节都明确指出了每个角色的出现场 合，所以我是很强调以角色来分工。但如我前面所提到的，我这边的团队也不过5个人，所以，虽然角色众多，但我们还是可以根据各自的团队实际情况来分担这些 角色，只要记住一个原则，找合适的人去做合适的角色，即担当某一角色的人是对该角色领域感兴趣的人。比如在我的团队中，美工是对艺术美感感兴趣，我团队的 美工是plmm，可惜只是兼职，没太多机会，建议大家有条件就找plmm来担任。需求人员是对整体业务有兴趣的人，我这里的需求人员是办公室头，所以向上 和外界的公关都是由他搞定。还有两个是程序员角色，一个偏向于底层数据库的实现，另一个偏向于逻辑层的实现，而最后我则是很痛苦地担当了项目组长、界面工 程师、高级程序员的角色。之所以这样，也是无奈，因为团队组建才半年不到，两个程序员尚不能胜任更高级的角色，期望其中一个人能尽快胜任界面工程师角色， 那样就能做到更合理化的角色分配，是理想的团队结构。