协作=各司其职+各尽其能

相信很多人看过《夺宝奇兵》三部曲，估计也有不少人看过它的花絮。花絮的片长比正片还要长，第一次我记得看了很长时间才看完。花絮采用记录的方式详细描述了三部曲的制作过程，涵盖了视觉效果，影响效果，特技制作等等多个方面。
制作花絮花了很多时间采访各个方面的头头们，描述了他们所承担的职责，以及在制作过程中所遇到的困难，克服困难所采用的手段。当然也少不了斯皮尔伯格对制作的详细描绘。在我看来，这是一部团队协作的Live Tutorial。我把他推荐给了很多朋友，建议PM或是Team Leader好好看看。
很多时候我都会脱离或者是逃离IT领域去找办法解决我所遇到的问题。这些问题多数集中在人的认识上，更确切的说是分歧上。夸张地说，在这个领域没有哪一种说法是绝对错误的，似乎是完全对立的两面能够共存。电影中的英雄快刀斩乱麻的解决烦恼异常的问题永远只能出现在电影中。而我采用得最多的方法都是折中。这种折中并不是充当和事佬，在争论双方说都退一步绝对是工作失职。
在一个项目（中等规模，成员14人）刚开始的时候我就遇到了一个难题：项目组成员对于采用XP还是RUP争论不休。那个时候我还不太了解XP，相对来说RUP了解得多一点。多数成员都有至少两年以上的经验，双方各执一词，互不相让。我仔细观察了之后发现坚持RUP的都在以前的项目中有应用经验，而坚持XP的都没有Real World经验，只是他们有过类似于Hello World的了解，但似乎他们热情更高一些。如何说服大家并取得一致对我来说简直太难了。我后来想了一个非常折中的办法--三问法。
由于对RUP了解多一些，我倾向于RUP，但没有表露。召集大家开会时，讨论了这样三个问题：
1，采用软件过程是为了什么？----增进交流促进协作
2，XP和RUP各自的优劣。----前者强调生产力，后者强调连续性
3，对于我们的适用性。----不管本身对或错，我们需要对我们有用的
讨论之后意见就比较一致，需要合适的文档，采用RUP，但要改进为适合我们的方法。相对来说取得了不错的成效，到项目结束时我总结出了所谓的“三问法”。从这以后，考虑问题的时候我都会问上三个问题，被戏称为三条。
选择了软件过程，其实就基本确定了参与者的职责。UP（不是RUP）在这一点上做得很好，详细描述了参与角色的职责，强调团队内的分工。社会的发展导致分工的必然，软件过程也在经历这种演进而且在不断细化。非常直观的角色是开发团队中的几类角色，包括美工，页面编辑，程序员，质保，DBA，SA，BA等等。每一个人的职责都很明确。这就是各司其职，我是不希望程序员去做DBA的事情的（所以我采用iBatis而非Hibernate）。
俗话说“冤有头，债有主”，团队开发中这一点尤其重要。最怕的就是任务不明确，出了问题找不到责任人。没有问题与问题都比较容易解决永远是不可企及的妄想。
虽然有了很好的分工，但如果某个家伙吊儿郎当出不了活，那也是一件令人恼火的事情。曾经一个家伙非常开心的允诺3天改写一段C代码并且符合我们新的框架结果花了三个星期，幸好不是主干类工作项。造成影响波及范围不大，否则我的劣迹史上又要添加一笔。
很多时候，若一个工作项的时间超过3周，往后的时间内进展如何都只能听天由命。我遇到的是这样的，那个时候每个人手上都有一个新的工作项，非常激发他的热情，同时也导致他想绝情地抛弃尚未完成的工作项。
每一次，我都黔驴技穷般告诫大家自己的职责必须尽自己最大努力完成，至少不要带给自己痛苦。因为，我的原则是，任何一个工作项都只由一个人负责，除非他离职。这多少带有一些强制性，也不是非常科学，但这是出于无奈。后来我从开始就说要尽自己最大努力，也尽量把单项工作划分在3周以内（好难），试图提高大家的积极性，但好像收效不大，现在仍然很苦闷这一点。
其实，各尽所能是需要我们所有参与者自己施压的。每个人都应该有一个奋斗的目标，这些目标应该是自己制定自己完成的。工作上接受到的一些任务很大可能与这些目标有冲突，但工作毕竟是不可抛弃的，至少对于大多数人是这样，最主要的就在于解决这种矛盾关系。嘿嘿，永远要抓住主要矛盾。

路漫漫其修远兮，吾将上下而求索。