团队建设：一个团队从无到有再到高效的管理方
东东导读：一个公司聘用一个经理，他的目的很简单也很明确，就是Drive business results, 达到一个或者一系列的商业目的。作为一个经理，你需要做的事情，就是围绕这个核心展开工作，做那些能够使得一个团队共同达到预期的商业目的。
团队管理对于People manager 而言是仁者见仁智者见智。经过多年的带队工作，我总结出一些经验和教训。
一个公司聘用一个经理，他的目的很简单也很明确，就是Drive business results, 达到一个或者一系列的商业目的。作为一个经理，你需要做的事情，就是围绕这个核心展开工作，做那些能够使得一个团队共同达到预期的商业目的。
一个团队从无到有再到一个高效的团队通常需要经历4个主要的阶段，团队初建、团队磨合、团队凝聚，最后建立成为一个高效的团队。（当完成预期的商业目的以后，也许还要解散一个团队）。谈到团队，我们首先要知道什么是一个团队。在职场上经常会听到团队这个词，但很多时候他们根部就不是一个团队。那什么是团队呢？看Wiki 上对团队的定义，团队是指一种为了实现某一个目标而相互协作的个体所组成的正式群体。看来团队是一个群体，是一个正式的群体。那什么是群体呢？群体是两个以上相互作用又相互依赖的个体，为了实现某些特定目标而结合在一起。一个旅游团，我们很容易理解这是一个群体。一个产品的研发组，我们认为这是一个团队。但究竟是不是一个团队呢？我们要看这个群体是不是具备这些条件：
自主性。 一个团队是能够自我管理和前进的。如果你是一个公司的老板或者经理，在你外出的时候需要不停的看手机，查邮件，监督工作的进展情况。不是你有强迫症，就是你的这个团队还缺乏自主性，需要你的监督才能完成需要完成的工作。
思考性。一个团队是能够不停的审视自身的运转的，发现自身的问题，积极的寻找对策，从而提出流程修改的建议。
合作性。这一项就不作太多的解释了了。就是能不能在有原则和肯协作的趋向下与人沟通。
在不同的阶段，PM(people manager)需要采用的管理风格和做法也是要有所区别的。但是也不是绝对的，要具体问题具体分析。
团队建立初期
team 的成员往往来自于不同的其他部门或者从组织外面刚刚招聘进来。这时候大家还处在相对比较生疏，彼此都不是很了解。如果工作的压力不是很大，在能独立应付的时候，会尽量掩饰自己不满的情绪，对于team或者team以外的合作者，保持一种比较礼貌和积极的态度去应对。这时候，作为管理者，不要以为现在team都很好，大家的情绪都很高涨，大家的合作没有问题。其实恰恰相反，各种危机正在一点点的滋生。一旦工作的进展中出现了挫折，就会成为导火索，各种抱怨和不满就会爆发，影响后面的工作进行以及team内部的合作。那作为管理者你要怎么做呢？以我的一些经验，可以采用指令型的方式开展工作。指令型的一些要点是：给出明确的方向，希望team 成员能够快速的接受；紧密的控制，当有非正面的情绪出现时，给与正确的指引；阐述出如果不按照你给出的指引进行实施，可能产生什么样的不好后果。
与此同时，管理者要善于观察team的一些代表性的成员，看是否有领跑型的member出现。如果有，让大家知道这个member做的好，哪些做得好。如果没有，你又是这个领域的专家，不妨自己亲自上阵，给大家做个标杆。我需要强调的是，作为PM的你，不应该什么事情都事必躬亲。以后你会发现你会力不从心，忙不过来的。在很多公司，包括我自己在内也是一点点被提拔起来的，所以你会是这个方面或者领域的专家。在团队的建立初期，可以适当做些调整。
在团队建立初期，我推崇使用指令型和领跑型的管理风格。目的是：保证工作能够按照预期达到，为团队建立信心；建立你作为PM，在团队中你的威望；标准和流程化部分工作，为team达到共识。
团队磨合期
在经历了初建期后，团队成员也有一段时间的接触。他们开始发现你的合作伙伴没有这么的完美，他们有各种让你看不惯的地方。在此种情况下，他们不是首先和作为PM的你交流去解决其中的矛盾。他们会先和他们关系好的别的同事去抱怨某某，从而达到共识。在此共识的基础上，收听者会继续观察被抱怨者，去进一步印证抱怨。消极的情绪会一点点的滋生，影响大家的士气和进一步的合作。在问题讨论的时候，team 成员也没有刚刚开始的时候的客气了。他们会大声的争吵。（希望只是对事不对人，往往是很难做到的。）这时候PM该怎么办呢？
在团队的磨合期，PM 需要给team一个清晰的vision（愿景）。让大家知道未来是光明的，目前的问题只是光明的前景下的一个黑斑。并且征求大家对此愿景的想法，诚恳的回答大家的各种Why。在得到大家认可的前提下，后面的工作就好开展了。狼蚁网站SEO优化就是让大家说出问题是什么，所有的team 成员共同参加，大家发言。作为PM，你注意聆听。
给大家举一个在我管理的团队中发生的一个例子。公司的领导决定通过提高产品的质量从而更大限度的提高用户体验。tester为了能够表现自己的工作业绩，大问题小问题不停的报，为了使得小问题也得到重视，bug的严重程度和优先级都很高。开发就对此有很大的不满。每次bug review 的时候，就会争论bug 的等级。还有，tester engineer 发现了问题报给了开发，开发由于忙于开发新功能，没去看bug。有些bug一放就好几天。当开发真正要去修这个问题的时候，需要tester 给重现，tester就说环境早没有了，你自己去建环境重现吧，我没时间管了。生产效率打了不少的折扣。
我组织一个讨论会，让大家说说问题和想法。大家七嘴八舌的说自己的想法（其实，能在讨论的时候说出来都不是什么大问题），我在一旁仔细地听不同的function team的想法。最后大家愉快的达成了一致，tester 报的bug，开发需要在24小时内，进行状态的更新，同意这是一个问题与否，或者需要tester 给更多的信息去重现此问题。如果对问题的严重级别，无法达成一致，发给PO（product owner，我们采用的是敏捷开发，有PO 的角色），有PO 去决定严重度和优先级。在这种讨论中，PM应该成为大家普通的一员，让大家畅所欲言，表达各种情绪。PM应该要做的是仔细的听，分析大家的背后真正意图，分析可能的方案。