组建一个稳定团队的重要性

    曾经，流水线式的工作流程在生产行业大行其道，许多公司也非常推崇，在项目开发中也尝试推行，尤其是“任何人都不是不可或缺的一部分，只是流水线上的一环”这样的思想非常流行，总是觉得人是随时可以取代的，不在意团队的稳定性。

    这么多年下来，发现在项目开发过程中，流水线式的工作流是完全不适合的。流水线的工作流，适合的是“由多个相对独立的重复性工作组合”的流程，不管这个流程多么复杂、每个工作的技术含量多么高，只要是满足重复性、相对独立的条件，就能非常适应。而项目开发，则不具备这样的条件。

    先说假设项目开发适应流水线，就必须各个之功能分解的非常详细，定义的非常明确，这样才能满足随时可以调配人员来开发的程度。在达到这样的目标之前，必然有大量的人力、物力来负责项目的分解、跟踪等等，以便满足人员流动带来的项目持续问题。这其中的复杂程度，与一般项目要求的“短平快”是非常矛盾的。或许，在某些大公司重要产品的开发上，可以满足，但对于许多项目来说，这显然是不可能的。

    项目开发的过程中，实际上能重复利用的是“以往的经验总结”。这些，又是非常不明确的，没法定性量化的。所以，一个好的团队必然十分重要。一个好的团队，队员之间的价值观、性格、能力，相互之间是认可的，也是有互补的，往往会产生1+1>2的效果。毕竟，在项目开发中，开发人员的效率，对周围的环境、氛围等，要求还是比较高的。好的氛围，必然产生高的效率，反正，必然会受影响。而且，团队内部之间的能力互补、习惯、默契等等，这些都是无形的，但又是影响非常大的因素。

    开发人员进行的工作，看起来像是重复性劳动，实际上，每次都需要进行处理，不能视之为简单重复劳动。一个合作不是很默契的团队，可能每个人的技术水平、能力很高，但合作起来别别扭扭的，对整个项目的进展都不会有好处。这就是，为什么临时搭的“草台班子”干项目，总是出这样那样的问题的原因。不是团队内的人员不想出问题，在各种想不到的原因下，导致合作出现了问题。出现了问题后，这样的团队往往不能及时解决、纠正，反而导致积少成多，最终问题不可收拾。

    项目中的技术人员，不能和流水线上的工人一样看待，虽然看起来两者的工作有些相似，但开发人员，在每个任务环节中都投入了不同程度的“脑力”，而不是简单的体力投入。这就间接的导致了，取代这个人，不只是要取代他从事“体力”敲出的代码，还有继承他在敲击代码时投入的“脑力思想”。这就是为什么危害别人的代码，会非常的累，尤其是不熟悉的项目，这是因为你不光是需要了解这些代码“干了什么”，还需要明白代码背后的思想“为什么要这么干”。

    所以，一个稳定的团队，在项目开发过程中，会无形中解决很多很多的问题，提高非常大的工作效率，这从明面上的人员配置、能力高低、工资水平等等的，是看不出来的。不要迷信“我们团队有超级大牛”这样的话。项目的成败，往往不是技术大牛能解决的。成功的项目有各种因素，但是失败的项目，必然会有一个不成功的团队。

    纵观全世界各行各业，只有是“知识性”的脑力投入劳动，干的好的都是某个或者某些团队，哪怕这个团队是以谁为主的。不会是因为某人的技术牛，拉一帮人，就是一个合格的团队了。

    必须承认的是，在脑力劳动中，投入的是“思想”，所以团队协作时，有一致的价值观、统一的认识、相似的解决方式，都能够很好的协调整个团队。一个稳定的团队，标志也基本上就是。就像篮球界，一说活塞，那就是防守型团队，这就是标志。有了这个，一个只攻不防、独占球权的人，哪怕是巨星，也不适合这个团队。哪怕是强行拉进了队伍，团队的成绩也不见的能提供，除非围绕巨星重建。

    不要盲目的崇拜那些技术牛人，一个团队是很重要的，千万不要忽略团队的作用。

    当听到那种“我有NN多人，随时能组建一个团队”或者“招××人，组建##个团队”这样的话，好像菜市场买菜一样容易就把团队建立起来了，我就“呵呵”。