程序员应知——团队精神

大家都知道，现在的软件开发已经不再是20年前个人英雄主义的时代，一个超级程序员就能够搞定一切的情况已经很少存在了。更多的情况是我们都是以团队的形式进行系统的设计和开发，因此，团队精神也变得越来越重要。

    早在我刚刚毕业要踏入到软件开发这个行业的时候，就在自己的简历里面写到：具有很强的团队精神。然而，说句实话，当时对这个词的理解真的不是那么透彻，只是觉得人缘好，和别人合得来，就叫做有团队精神。然而，随着工作的年头越来越多，经历过各种不同的团队，也带领过不同的团队，渐渐地，对于“团队精神”的体会也越来越深，也越来越觉得并非那么简单。

    那么到底什么是团队精神呢，我觉得它包括了下面这些特点：

荣辱与共
交流分享
精诚协作
尊重理解
    下面让我分别结合自己多年来的工作经历谈下自己的理解，与大家共享，同时也说说自己理想中的团队的样子。

 

荣辱与共

    作为一个团队中的成员，就要把整个团队的荣辱放在第一位，这似乎是集体主义精神的体现，与当前更为流行的个人为中心的思想有些格格不入，但是，只有把整个团队的利益放在首位，团队才能够发展和进步。而团队的发展和进步必定会给其中的每个成员带来好处。

    在这里我要说个很典型的情况，在团队中一般都会有开发人员和质量管理人员（也就是我们常说的测试人员），一般来说这两种角色都是冤家。前者非常怕后者测试的时候测出无数的问题，而后者经常会经常抱怨说“你自己测没测试啊”。似乎二者之间总是有着不可调和的矛盾。

    想要解决这个问题，其实很简单，就是要明确荣辱与共这条原则，开发人员的目的是想要高效高质的开发出程序，这首先就要对自己提高要求，如果开发出来的程序质量不高，那么必然会返工修改，似乎当时是节省了自己的时间，尽快地把程序提交上去了，但实际上，自己后来还需要修改，节省的时间还要再找回来，另一方面，还需要测试人员指出低级的问题，（那些问题只要再稍微细心一些就能够避免），也会浪费测试人员的时间，结果对于团队来说，就花费了两份时间。如果能够想到为团队节省时间的话，也就会自觉地提高自己程序的质量了。

    而对于质量管理人员来说，首先当然要仔细地测试，不可敷衍了事，那样的确可以节省自己的时间，而且容易和开发人员搞好关系，但是必定会导致程序质量的下降。而对于客户来说，质量才是程序的生命线。其次，不可以因为自己发现很多缺陷就沾沾自喜，的确这意味着作为质量管理人员，工作做得很到位，但是我们的目的是什么呢？并非是要找到更多的缺陷，而是要想办法提高系统整体上的质量。我想我们大可以将缺陷总结分类，然后将自己的分析结果提交给整个团队，指出在哪些地方比较容易犯错误，那样不仅整个团队的开发质量得到了提高，也节省了自己以后工作的时间，只不过是不会总是找到那么多的缺陷了。

 

交流分享

    交流在任何工作中都是非常重要的，人和人之间只有充分交流，才能够更好地工作。这些交流不能仅仅限于开发人员之间，团队之中每个人之间都应该充分的交流，否则就会在信息的传达过程中出现理解上的偏差。比方说，如果上游工程（需求分析、概要设计）的负责人不和下游工程（详细设计、编码、测试）的人员充分交流，那么很可能会得到最终用户这样的评价：你们所做的东西不是我要的。这就是由于信息在传达的过程中发生了偏差，失之毫厘谬以千里，导致了最终客户对团队的恶评。

    团队的成员应该成为朋友。也许这在现在的职场之中，很难得到认同，甚至还听到有人说过，不要把同事当成朋友，但是我不以为然，毕竟我们很多的时间都是与同事一起度过的，很多东西需要和同事一起承担、一起分享。如果不是朋友的话，没有最起码的信任，怎么做事儿呢？的确，有些同事会不值得做朋友，那么就应该去找到值得做朋友的人，或者在组建团队的时候就要慎重地挑选所有的成员，尽量让大家都成为朋友，那样才更有利于工作的开展。

    分享意味着什么呢？我觉得它意味着共同进步，知识要分享，经验要分享，好吃的，好玩儿的都要分享。这也应该是大家成为真正的朋友的前提吧。尤其是知识和经验的分享，对于组建学习型的团队非常重要。而最有效的形式，就是在固定的期间内举办技术交流会，团队的所有人尽可能地参加，大家可以把自己工作学习生活中所发现、所学到的知识分享出来，这样不仅仅有利于大家共同提高，也有利于解决工作中的各种问题。而这也是我一直在致力推行的一种方式，尽管最近有些障碍，呵呵。

 

精诚协作

    想要达到这一点，首先就不要“事不关己，高高挂起”。尽管有些事儿不是我们份内的事情，但是团队的事情，我们都应该有责任尽自己所能去做。有人会说，做得多，错就多，帮别人修改了程序，当这个程序出问题的时候，就会怪罪到自己的头上。这种情况的确存在，我也遇到过多次，但是我更珍惜的是在这个过程中和其他团队成员的交流以及所学习到的知识。任何事儿都不可能是完美的，都具有两面性。而且这样做非常有利于形成真正意义上的团队，当出现问题的时候，我们帮助过别人，当我们自己出现问题的时候，也就会有人帮我们。

    也有人会说，让一个人做别人的工作，修改自己不熟悉的程序，风险会比较高，很可能会出现其他的问题。的确这种情况也存在，因此在涉及到业务领域知识的时候要谨慎，复核一下也是非常必要的。而对于纯技术的问题，就不存在这种问题了，一个项目中的程序都应该是风格统一的，程序员彼此之间应该可以互相阅读和修改程序。

    另外，协作要体现在整个团队之中，需求分析人员、设计人员、开发人员、测试人员之间都要协作。在做自己的工作的时候，都要为别人着想，考虑如何才能够更有利于让别人也顺利开展工作。

 

尊重理解

    人都有长处，都有短处。这是肯定的，没有谁能够是完美的，何况生活中不仅仅是工作，还有很多其它的事情也会对工作造成影响。因此在发现别人犯错的时候，应该去理解，并且以对事不对人的态度去解决问题。

    比方说，测试人员发现开发人员程序中出现了很多缺陷，那么不应该去指责，而是应该记录下来，然后和开发人员一起分析，提醒他以后不要出现类似的错误。

    再比方说，当开发人员发现设计人员的设计出现了问题，那么就应该去商量，找到更好的解决方案。

    再比方说，设计人员发现最终的程序与自己的本意有出入，也应该去沟通，而不是强硬地要求别人重新编写代码，而应该找到为什么会出现这样的问题，从而去避免以后理解上出现歧义。

    多一份尊重，多一份理解，才能够更好地沟通，才能够更好地协作。

 

    我想，如果做到了上面的四点，我们应该建立起一个比较优秀的团队，然后接下来要做的就是保持团队的稳定，并且在一个又一个的项目的磨练中不断地增进团队的凝聚力和向心力，并且越来越好地根据每个人的能力来分配工作，做到人尽其用，这样团队的工作效率会越来越高，完成任务的质量也会越来越好。

    创建一个理想的团队，需要很长的时间，需要团队成员彼此之间不断地磨合、理解和包容，所以，在创建团队之前，要确保团队成员的稳定性，同时，对于人员的增减，都要慎之又慎，必须是完全理解和赞成团队文化，并且能够为团队做出贡献的人，才会加入到团队中来。

    上面所述的团队非常理想化，想要真正实现会很困难，而且保持下去更困难，我们要做的也不是一口吃个胖子，一下子就建立一个超级团队，而是要在创建团队的时候就有自己的原则，并且根据这些原则不断地对团队进行改善和建设。

 

p.s. 这篇文章在我的草稿箱里面待了很长一段时间，一直在对其中的内容考虑来考虑去，生怕误导了大家。不过“丑媳妇早晚要见公婆的”，所以还是在修订了之后，拿出来与大家分享，大家有什么意见，只管提出，希望和大家一起讨论，:)

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/lingyun2005/archive/2010/08/09/5797890.aspx