（原载于MC@Argo）

Part 3. 逆境 —— Team 团队

七月份刚开始，我在项目T中的模块已做得七七八八。有一天傍晚新任经理K走过来问我，想不想去做北京的一个项目C，将会先到北京参加十天的Oracle ERP培训，然后再回来客户C的广东分公司工作，也可能去别的地方出差三个月。当时我正为项目T的进度而悲观中，一听能够换一个环境，还能出差去北京，对于一个从来未出过省的我来说，真是一个不错的机会，于是爽快地答应了。剩下的功夫就是把手上的模块交接一下，问一下师兄们出差要准备什么，然后就按计划周一飞去北京——然后噩梦就开始了。

同行的还有两个培训生和一位比我们大一届的同事R。我们都没出差经验，不过R认识一些以前出过差的同事，所以我们都听他指挥了。可听他解释之后，才发现出差并不是想象中那么美好的事：1. 除了机票是公司帮我们订好之外，其他的费用都得自己先垫着，怎么报销还要问北京的负责人；2. 如果有人跟你说要出差一个月，那就是很可能出差三个月，如果说让你出差三个月，那么就是半年到一年；3. 而且听说分配广东的名额只有一个，R是得到经理同意他留广东才来的，因为他要读在职研。听完之后我直冒冷汗，幸好来之前听人家建议拿了2k多现金出来，本来积蓄也不多，又没有信用卡，在北京这十天都不知要不要露宿街头；最可怕的还是第二点，我听的时候还将信将疑，我本来只是想出短差来参加培训增长见识，没心理准备更没金钱准备出差那么久啊。。。最让我惊讶的是，为什么经理K在我们出发之前一点也没交代过我们要做什么？只是简单地说了去北京找项目经理，一切让他来安排。

踏上北京的土地，一路看着周围的景色，一方面怀着好奇的心理去了解这个首都城市，一方面忐忑不安地坐着的士来到了北京项目组的办公室。我们遵照指示找到了项目经理，他进行了简单的自我介绍和项目简介之后，就让我们去一个会议室里参加培训——原来培训已经开始了？！时间是下午的五点多，据说原计划就是周一开始培训，还有北京上海的同事参加，我们已经落下一天的课程了！——而且我们连最切身的住宿和报销问题都还未解决。。。然后主讲人说为了给我们补回白天的内容，带我们吃过晚饭后再加班讲两小时！结果我们抱着行李拖着疲惫的身体精神完全不在状态地听了两个小时——终于可以找地方休息了！幸好晚饭下班前去问了一下北京的HR同事我们要住哪里，不过问她报销的事情，她却怎么都说不清楚，让我们跟项目经理说好了再找她。

如果有接触过Oracle ERP的人，都知道这个系统不是一般的复杂。首先是组件繁多，配置项多，而且跟业务的相关性很大，培训十天是根本不可能讲得透彻，更不用指望像我们这些没接触过商业系统，也不了解财务物流知识的人在这十天内听得懂。于是主讲人就只演示每一个流程操作步骤而忽略背后复杂的业务逻辑，我们则是每天超高负荷地囫囵吞枣，顺便每天找HR跟进一下报销的情况。眼看十天讲不完，我们就加班培训。到了第二个星期，我们早已身心疲累了，一方面是离乡别井的思念，另一方面是强大的工作压力（而很大程度是由于对许多事情没心理准备所致）。然后有一天我意外地接到了一个来自广州ODC的电话，是经理K打过来的，问我是不是在北京犯了错误，为什么北京的项目经理会向K的上级投诉我们的员工工作马虎，而且势利眼总是讲钱？

我一听简直惊诧莫名，怎么我们每天在疲于奔命地参加培训，居然有人会无端端直接找大老板投诉给黑锅我们背？而且那个投诉我们的人就在会议室外面十几米范围以内——他却从来没有正面跟我们提过任何意见！所谓的工作马虎，就是跟不上那囫囵吞枣的课程，所谓势利眼，就是我们每天跟进一下报销的情况，我可是冒着露宿街头的风险来坚持培训的啊！这是我第一次有被人背叛的感觉，就像忽然间发现我们原来不是在同一条船上一样。结果最后经理K说为我们求情让我们留在项目组里，可是那时我已无心恋战，那边的项目经理也“正巧”不想用我，大家一拍两散。后来听说那项目经理只做了一半就走了，再后来我的报销款项经过了半年才打到我账上。办事效率可真高。

Alistair Cockburn认为，软件开发是一个创造和沟通的合作游戏（“a cooperative game of invention and communication”）。

一个项目的成功与团队的沟通合作分不开。有许多项目中的问题其实是由于沟通不足导致的，比如说经理K没有给我们充分说明项目的情况，比如说北京的同事没有告诉我们清晰的项目计划（而且他们的计划总是延期），没有告诉我们清晰的办事流程，比如说项目经理没有向我们正面公开地表达他的想法，才导致了这次的矛盾出现，还有许许多多我在其他项目中耳闻目见的情况。对于跨地域的团队，地理和文化上的沟通障碍更大，如果再涉及管理层政治的话，那项目的情况将会更加不堪设想。

人与人之间的沟通本来就是不完整的，有许多隐性知识是无法通过语言传播的。有效的沟通是建立在共享经验（share experience）的基础之上的，他把这些经验称为“touch points”，一个在后来加入会议的人，必须得到足够的touch points，才可以了解会议中大家谈论的内容。在项目开发的过程中加人手的原理也是一样的。所以我们不能期望别人一定理解你所说的东西，更不应期望他知道你没说的东西，我们只能管理这种沟通的不完全性，让信息尽可能完整地表达。

以前一直以为在这件事上我真的犯下了很严重的错误，整个ODC的声誉都因我而受损害了，以致于常常自责。后来我才意识到，这根本是管理层之间的问题以及该项目混乱不堪的管理问题——难怪他们出差总是一个月变三个月，三个月变一年。团队什么时候最高效率？当然是在一个团队有向心力的时候。这要求所有成员都明白这个团队的使命，大家都向着同一个目标共同努力。团队成员应该得到尊重，成员之间是互相友好的，能够主动提出和接受一切对项目有益的意见。像我在北京所见，混乱的安排，含糊的沟通，危险的进度，根本没有合作可言。后来我问过留在那个项目里的两个培训生，两个都说做得很不开心，还好我早离开了。

回来之后我参加了另一个香港的小项目，R同事也有份，他是我们这个四人开发小组的组长，这个项目是另一个部门托我们做的，那个部门的联系人W（其实就是系统分析员）相当nice，跟我们沟通一直很融洽。R做到次年二月份就跳槽了，在这个合适的时机我顶上了他的位置，跟香港的同事沟通，我们的合作非常愉快。她依赖我们的技术知识，我们依赖她跟客户的沟通，我们之间总是非常信任，很多时还给对方提些建设性的意见。这个项目我们做了大半年，一直到次年的六月份，虽然用的技术都很简单，还是我做的过程中自己摸索的，不过倒是给了我全面锻炼的机会，这是我完成的第一个真实的项目。项目结束后，W和我成为了好朋友，一直到现在都保持着联系。

而在这一个阶段性结束的时刻，我又再开始思考自己往后的路该怎么走的问题了。