Team Leader你会带团队吗？你懂合作吗？你好像都不会啊！

Team Leader你会带团队吗？你懂合作吗？你好像都不会啊！(上）

Team Leader你会带团队吗？你懂合作吗？你好像都不会啊！（上篇）
                                                  ------打好你手中的牌

 

前言：

       这篇文章是写给Team Leader和往这个方向前进的人。也适合一般的程序员，对你们在团队合作的理解上面会有所帮助；对你将来选择什在什么样的团队做事也有帮助。在文章中我也侧面道破了国内好多敏捷开发失败的原因。

 

    团队管理是一个比较大的范围和概念，但我们可以把它进行简化到以团队为基础，在团队上进行一些方法的应用。我在文章中，将分为不同的块讲解。当你把这些不同的块都理解清楚，结合起来就是团队管理。

PS：文章中的一些理解，是基于我学习一些管理书籍的内容和在工作中实践总结的一些个人概念的叙述。是一种经验的分享，可能会包含错误和不全面。需要读者自己去判断和理解。
      为了能让大家对团队更好的理解，我讲的很细，导致了字数严重偏多。我本来想一起放上来，但怕大家看着睡觉，故分成了上下两部分。下篇会重点集中在团队的内部培训和团队成员的招聘，还有团队关系处理上。先把上篇放出来看看大家的意见和反响，也可方便我对下篇进行调整。 看完后，如果你觉得受用，请推荐下。共同提高，我们的工作和发展才能更和谐。

　　下篇《Team Leader你会带团队吗？你懂合作吗？你好像都不会啊！(下)》

 

以团队开头：（如果你知道什么是团队，可以跳过）

       什么是团队？这里有个比较标准的解释：团队（Team）是由员工和管理层组成的一个共同体，它合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。

 

    在软件公司，一个基本的团队单位，是由Team Leader（也可能是项目经理，每个公司对头衔的分配不一样。这里以Team Leader为总的称谓）所带领的一群人（如程序员）。以数据结构来说，就是一个多叉树的结构；每一个节点都是下面子节点的领导；节点和子节点组成了一个团队。Team Leader的领导（项目主管或项目经理）又会管理着多个Team子节点（开发组，测试组，美工组等）；这些Team组成了一个大的Team团队，主管也是大Team的Leader。换句话说，每个节点都是下面子节点的Team Leader，至于起什么头衔，并不会影响Leader的职能。

 

团队类型和选择：（重要，直接决定着后续的多个因素）

       团队的类型其实没有一个什么固定的称谓和标准。一些团队领导在工作中不断调整团队成员的组成。当达到一个比较成熟的团队模式时，为了方便大家理解，会拿生活中大家熟知的一些事物来代替（如手术台类型）。

 

    其实，前人已经为我们总结出了很多成熟的团队组成类型。如：手术台类型。做手术大家一般比较熟悉，是以一个主治医生为主刀，其他医生为辅助，来完成整个手术。我们可以很容易的把这种模式与团队组成结合起来。一个团队中，以一个或两三个程序为主导，其余程序员为辅助来完成代码开发；这样的模式在国内游戏开发中经常使用。主刀也就是我们常说的主程（主要程序员或技术一把手），以主程为核心进行开发，其他程序员辅助完成附加功能。

 

    在实际的工作中，我个人倾向于交响乐队类型（这个是我个人的叫法，因为这个模式和交响乐队基本一样，也便于大家理解。我在后面的“团队合作”里进行了较详细说明和对比）。在交响乐团中，团员都有各自的技能，并分工明确；在指挥的指导下完成演奏。这里的指挥就是我们的Team Leader。

 

    团队的类型有很多，这里只是列了两个被大家广泛使用的类型；其它的类型，就请大家自己钻研了。

 

    选择什么样的团队类型，是一个Team Leader在组建团队时要解决的一个问题。不同的团队类型涉及不同的团队成员组成，并对团队成员技能的要求也不一样。这会涉及到你需要招什么样的人，这也是为什么我把副标题定为：打好你手中的牌。不同的团队成员就如同不同的扑克牌，你要去组织和打好它。发散下思维，可以把团队管理抽象成打扑克牌的过程，打牌就是在进行管理。

 

      不同的团队类型有不同的优劣。如手术台类型，对主程的要求很高。在整个团队开发中，主程的个人能力决定了整个项目的成败；在很多时候，主程也担当着Team Leader的角色。主程个人能力这个因素，导致了我不太喜欢使用这个模式；因为风险较集中。但是在一些尖端技术的开发中，往往又是需要手术台这种模式。原因很简单，尖端当然需要顶尖人才去做了。这个模式有一个好处，就是对其他程序员的要求不高，比较容易招到合适的人。

 

      再来说说交响乐队类型。这个是我普遍推荐的，很大一部分原因是我们并没有很尖端的技术要去实现，并且这个模式可以分散风险。但是这个模式对程序员的能力有一定要求，就是需要某方面的特定能力（具体需要什么能力，根据你的项目需要来划分）。我不需要你会很多东西，你只需要对特定领域有钻研；或者你对某个领域赶兴趣，并愿意往这个领域走下去。我需要你专精一点，如同交响乐队里面每个人有各自的乐器技能。但这模式也有个缺点，那就是在初级程序员的招聘上，基本很难找到有钻研一个方向的。毕竟他们对程序才起步。不过这个问题通过内部培训是可以解决的。后面会具体探讨内部培训。

 

    所以，选择什么团队类型要看项目需要和Team Leader的经验。发散下思维，其实在好多小公司或非正规团队，也是使用的手术台类型。3-5人一个团队就上架干活了，1个技术领头的（主程），搭配2-3个人就干了。这种类型好搭建，成本低。换作交响乐队类型，同等情况一般人员配置会稍多，成本稍高。但是作为长期发展来看，交响乐队类型的团队比较稳健和可持续发展；如果是要技术难点突破，手术台类型的团队就比较适合去攻克难题。

 

    提点敏捷开发，敏捷开发也是一种团队类型，被大家尝试过、讨论过、分析过。我也尝试过，最终还是转回了交响乐队的模式。这里简单说下我对敏捷开发的拙见。优势，快速开发，快！非常快！劣势，按照敏捷开发的理论，应该是没啥劣势。一切看起来是那么美好的敏捷开发，到具体操作起来却很多失败。其主要问题就是，敏捷开发对开发团队的人员平均素质要求太高，一般的中小公司，很难达到这个平均素质水平。这也是我失败的原因。

 

团队合作：（别跟我说你会团队合作，十有八九你在忽悠）

       团队合作根据团队类型的不同，合作的方式也是不同的。这就是为什么我在“团队类型和选择”后面标上重要。如果你现在对团队类型的功能性理解不清楚，下面好多问题你都会产生模糊不清的观点。那么我建议你最好花点功夫去弄清楚不同团队类型的组成模式。比如手术台，你可以想象在做手术时，医生们是怎么样合作的；在交响乐队演出时，大伙是怎么合作的。

 

    团队合作不是一群人在一起做事，不发生冲突，自己做自己的事情。通过我在工作中的观察，发现很多人都持有这一观念。根本原因是，我们从小到大就没有接受过团队合作的训练。虽然我们走上社会时会知道出去工作要合作，老师也会提醒。但我们脑子里的映象是，一群人在一起做事就是合作。不发生冲突和大伙一起做事，这只能是一个基本的工作态度。如果这都做不到，那么你根本就没有准备好做事。

 

    如果你要问我什么是团队合作。那我也只能给你字面意思的解释：团队合作指的是一群有能力，有信念的人在特定的团队中，为了一个共同的目标相互支持合作奋斗的过程。

 

    如果按照字面的意思来理解，其实是理解不了的。这只是一个理念，不是具体操作。要怎么做，我将给大家在下面道破。但是要记住一点，不同的团队类型，其合作的方式和具体实现都是不一样的。这样就会产生很多不同的合作方式，因为有很多不同的团队类型。如果你说你懂团队合作，这不是忽悠你自己吗？能弄懂弄会一两种方式的团队合作就很不错了。这里再提一下敏捷开发，敏捷开发对合作是另一种方式，这种方式明显对合作素质要求比较高。很多人连基本的两个团队类型的合作方式都不知道，就要他们直接跳到敏捷开发的合作模式。你说能不失败吗？

 

    下面我将通过交响乐队的演出来说明团队合作如何进行和为什么要这样做。这里只是一种类型的合作方式，我主要以交响乐队类型打开你对团队合作的理解。后面在慢慢讲解其他类型。

 

      一个交响乐队有很多团队成员组成，可以分成弦乐组、木管组、铜管组和打击乐组（如开发组，测试组等）。如弦乐组又是一个提琴的家族，包括小提琴、中提琴、大提琴和低音提琴（如开发组里面的前端，后端等）。不难发现交响乐队分工明确，职能清楚。对了，还有一个指挥（Team Leader），先忽略他。如果没有指挥，大家各自只顾自己的，你拉你的大提琴，我吹我的双簧管等，他弄他的长号。这样演奏出来的只能是噪音。也许大家可以商量下，我拉完大提琴，你在吹双簧管，他吹完你在演奏长号。不错哦，这是一个办法，好像没指挥啥事。如团体舞蹈表演里面就是这样的过程，通过观察别人的表演事件点是否完成或者到某个状态点时来启动我接下来的表演；通过上一个人的事件来触发下一个人的事件。但这有一个缺点，就是需要处理大量的上下文环境事件（前一个人表演结束，或者某个触发点）。一旦中间有人出错了（异常），就会引起后面的人整体出错，因为大家不能捕获异常和对异常进行处理。而且这样的一个表演，对表演者的个人素质要求很高，需要大家有很高的默契和能够对复杂不确定的异常进行处理。我们可以从中初略看到，引发异常的不确定因素很多。那么怎么处理和简化这个问题呢？回到我们的交响乐团，这里出现了一个指挥（其扮演着Team Leader的角色）。现在交响乐队的团队成员不用去观察复杂的上下文环境，而是专注自己的技能和观察指挥的手势（命令）来触发演奏（执行）的开关。这样问题就变得简单和好控制了，因为指挥可以纵观全局，并扮演着异常处理的角色。一旦有团员出现异常，指挥可以马上捕获这个异常，并用经验进行处理；且不用中断演出，团队成员也不用去关心有什么异常。每个人都有自己独特的功能，只用等待指挥的调用即可。问题是不是变得简单很多呢？但在这里突出了一个人的重要性，那就是指挥。其实很多人不理解指挥，认为指挥其实没什么大不了，就是在上面挥挥手。一个很简单和容易角色，没有乐器演奏者重要或技术含量高。不要指挥，不出现异常，其实也可以表演的很好嘛。如果你这样想，那是因为你不懂指挥的重要性，你不懂团队合作的精髓。如果你是这样一个团队成员，那么你不会信任你的指挥（Team Leader）。当异常出现时，这个演奏可能中断并崩溃。因为你不信任你的指挥，在出现异常时，你会用你的个人能力去判断该怎么做。这时指挥对你的调用将不起作用，那么这样就会造成一个无法处理的异常。这也是很多团队失败的原因。可见指挥（Team Leader）处理着整个表演的异常情况。（发散思维：根据这样一个流程，我们就可以很容易追踪到事故源。查明是Team Leader异常处理的方法有问题，还是异常调用出现问题。具体细节不是这篇文章讨论的重点，但是通过异常的判断很容易定位到责任人。）

 

      团队合作是要Team Leader来控制和主导的。对于团队成员来说，你只要明确的执行了Team Leader的指示，你就产生了一个合作。但这不是说你就会团队合作了。对于团队合作的精髓，Team Leader和团队成员都要很清楚的理解，要不然你们是不可能产生信任，那么也不会存在合作。经过我的观察和跟别人的交流发现，团队里面最大的问题是不信任。但产生不信任的原因是什么呢？用编程的思想“抽象”来处理这个问题，经过不断提取发现，最根本的原因是大家不懂什么是团队合作。

 

    回到交响乐队类型的团队，我们可以从中发现：程序员信任你的Leader，并完成Leader对你的指令。这就是交响乐队类型的团队合作。是不是很简单？希望你是真心理解了。记住“信任”这个关键词。

 

    简略说一下手术台类型的团队合作，主要是让你理解不同类型团队的合作差异。手术台：程序员要默契辅助你的主程（其实主程就是你的Leader）。注意这里的关键词是“默契”而不是信任。在手术台模式下，成败完全是由主程一个人决定的，程序员可以不去信任主程。但要和主程有一个默契，当主程需要什么时，马上提供相应的辅助。

 

      其实还存在一个每种类型的共同点，就是Team Leader你要信任你的团队成员。我不着重讲，是因为你要是不信任你的团队成员，你也不会去用他。你用人的基本前提就是：疑人不用，用人不疑。

 

    留给你自己去琢磨的，交响乐队类型，Leader需要了解你的每个团队成员技能，并且自己本身也需要会技术。基本上交响乐队类型的Leader都是从高级程序员发展而来。手术台类型，其实这个类型Leader的概念比较模糊。如果你分为主程和Team Leader，那么Team Leader不需要任何技术技能。这样Team Leader会有点多余，所以很多团队里面，主程就是Leader。这样的组织结构，成败完全在一个人手里。如果不是做技术难点攻破、核心技术开发，我个人不建议组建这种类型的团队。

PS：这里我要推荐大家去看一部电影《速度与激情5 Fast Five》2011年上映的片子，我把这部电影定义为是一部标准的讲解团队合作的片子，我组织部门的人都看了一遍。网上高清下载一大把。这个电影很好看，很有激情。电影中他们一群人组成了一个团队，分工明确，独特的技能。他们团队也出现了不信任，并处理不信任。是一个完整的交响乐队类型的演绎。这个片子2011年上映时，我看完心里感触很多。当我正通过阅读来学习团队管理时，对团队合作等好多概念还比较模糊，能理解但又不能很好的把每个地方结合。直到看完Fast Five，整个任督二脉被打通了。这个电影也触发了我想写一篇团队管理的文章，但一直迟迟没有下笔。

Team Leader你会带团队吗？你懂合作吗？你好像都不会啊！(下)

Team Leader你会带团队吗？你懂合作吗？你好像都不会啊！（下篇）
                                                  ------打好你手中的牌

导读：

　　这是接着上一篇《Team Leader你会带团队吗？你懂合作吗？你好像都不会啊！(上）》写的。上一篇，我着重写了什么是团队，并比较深入的去解释团队和其组成。团队管理不是什么新鲜玩意，有很多好的案例和经验给我们学习；但是如何运用，则需要我们很好的去深入理解团队开发的每一个细节。在下篇，就会涉及到一些人提出的疑问，并比较偏应用了。但是整篇对整个团队管理涉及还不是很完整，因为团队管理的全部内容不是就靠两篇文章可以写完的。有机会我会再深入的写一篇团队管理的进阶篇，但是对读者的能力要求就会比较高。

 

　　我看了下关于上一篇的评论，有些人不屑于去深入理解什么是团队，我只能说你将来在团队管理上的进步是会很渺小和漫长的。如同在我们做软件开发时，有些人根本就不理解操作系统原理、编译器原理、托管代码运行的原理，但这影响他们编程吗？不影响，他一样可以编写出程序，还会出来叫嚣；但是对于懂编程和懂原理的，你会发现代码质量是差别很大的，而且以后的成长也是看得出差距的。

 

招聘和培训：

　　只要你明确好你到底需要什么技能的程序员，招聘其实是一件相对容易做的事情。既然很容易，可为什么有时候却又老招不到人，结果却变成了招人难。对于这个问题，在我的实践当中，可以归纳为以下几个方面。

1）  需要超人。

2）  需要超人。

3）  需要超人。

　　对于招人难，我不断总结、反复总结，能总结出的就是“需要超人”。对于超人这个东东，可以看我的另一篇文章《不是HR，Leader你到底需要招什么样的程序员（变形金刚？超人？可能吗！）》。

 

　　在这里我以一个小团队的创建来举例说明下如何招聘和招到你需要的人。其中的核心思想就是明确你需要什么技能的程序员。

 

　　招聘前，你要对你的项目需求有正确的理解。你才能了解你需要哪方面技能的人。假如这里我要做的是一个.Net的Web网站的项目。首先可以把程序员分为两级，初级和高级。如果我想把Web网站的前台和后台独立开来，那么我们就需要两个高级程序员（一个负责前台，一个负责后台）；如果你觉得没有必要独立开来，一个高级程序员就可以了。接着你就要明确高级程序员在项目中的职责。我希望高级程序员在项目中负责架构设计和前端后端核心代码的编写。到这里其实就可以完了，可以开始写招聘需求了。至于要几年工作经验和有没有相关项目的经验，看你自己的把握，毕竟是你的团队。按照普遍高级程序员3-5年的工作经验来算，我们就可以大致写个如下的招聘需求。

1.3-5年工作经验

2.熟练使用C#开发语言（语言看你们项目使用来定），熟悉网络开发

3.能够完成项目中的框架代码的编写和主要功能开发

4.掌握Javascript 和 Html

其实这就可以了，如果你有明确的更细的要求，自己再列出。如：

5.理解MVC开发原理

6.熟练使用Jquery

等，具体要什么，看你的实践需求。切记，不要写出来的招聘需求是在招超人。写完后Leader你自己好好读读你写的招聘需求，看是不是在招超人。要是是，那么就需要修改需求，直到合适。其实在每次修改需求时，也是在加深你对你们需求的真正理解。 

 

　　下面我们就要开始进行初级程序员的招聘了。首先我们要确定总工作量和高级程序员的工作量。这样我们就可以计算剩余的工作量。工作量的计算在很大程度上取决于你个人经验的计算。当我们确定了剩余工作量，我们就可以细分我们需要几个初级程序员来完成和需要什么技能。如需要完成接口的开发和前端网页的编写。这样我们也可以写出招聘需求了。

1.1-3年工作经验

2.能够使用C#进行指定功能开发，对接口开发有一定了解

3.能够使用Javascript进行网页交互操作

4.能够使用Html和Css制作网页

 

有时我们还需要带美工性质的前端

1.1-3年工作经验

2.熟练使用Html和CSS制作网页

3.能够使用Photoshop切图和绘图

4.会Javascript和Visual Studio的优先考虑 

　　先说到这里。你也许会说，实际比这复杂的多。这里我要说，我只是通过例子让你去了解一个流程和理解它。如果你真正理解了，其实整个流程也就是很简单；没有你想象的那么复杂。如果你觉得很复杂，可以从一个方面说明你目前能力还不够。

 

　　在我实际的经历中。刚开始，我写的招聘需求内容很多，要会这要会那。在我现在的观点，我就是在招超人。但是当时我觉得，我就是要会这么多技能的人，要不然没法做。现在看来，其实不用会这么多，也能做。因为在开发的过程中还涉及有学习和培训的一个过程（我下面在讲）。当你写出的招聘需求是在招超人时，你就要开始简化，尽量简化到单一且核心的需求。但是有个情况，你的实际需求确实需要会很多很多。那我们怎么办？你可能也是程序员过来的，以你自己的经验和你身边人的经验。会这么多的人，你身边多吗？既然很少，那么你肯定招不到合适的人。这时你就需要把一个人的任务拆分成两个人或三个人的任务，招两个人或三个人来做。这里可能还有一个情况，就是你的老板说要招一个人，可是按照拆分下来的算，你需要两个人。这时的你，需要和老板好好谈谈，因为这时不是你的能力可以及的。不要钻牛角尖，那样只会让你招超人。问问老板，看老板有什么建议和指点的。有时你可能会觉得你的老板某些观念过时了、是错的、不如你。虽然我也有过，但是在实际的经历当中，这些有着老程序员经历的老板确实比你想象中的厉害很多。

 

　　还有一种情况，就是我要涉及到的培训了。当你把招聘需求提炼到很简洁了，对能力要求也按照经验做了调整。可是，你还是会发现前来应聘的人达不到你想要的要求。怎么办？有时你会觉得在降低需求就真的没有需求了。在这里也许会有人要来抨击我了，觉得我把程序员说的太那个了。这里我来表达一下我个人的观点。人才确实有，但很多优秀人才不可否认的都集中在了大型企业和公司；还有一些人则在老程序员前辈的创业公司为了理想而奋斗。还有一个现状就是，现在软件公司真的是越来越多（当然倒闭的也多）。一些中流砥柱基本上都已经被瓜分完了，有时还略显不足，最后摊下来的其实没有多少了。我个人的看法是，以现在软件公司的数量和环境，中高级的软件人才确实还是一个严重不足的情况。那么这就造成了中小企业招人难的一个问题。虽然投简历的人很多，来面试也是一批一批的，但是却往往很难招到合适的人。这个时候，我们就要对应聘者放宽点要求，并提供内部培训。

 

　　当你经过数次招聘后，发现应聘者的整体水平没有达到你的需求。这时你就要调整一下你的要求，适当降低一些技能。因为我们得接受事实；虽然你觉得你的要求不高，但是来的人却都没有达到你的要求。这时我们的重点就不应该放在是否达到了你的所有需求，而是只要满足你某些需求（你自己觉得比较重要的几个需求）。我们就可以把他暂时列为一个合格的候选人。当我们有了数个这样的候选人时，我们就可以从中筛选我们所要的人。这时筛选的依据是什么呢？就是学习能力。这里又涉及到怎么去考察一个人的学习能力了，这就要看Leader你的能力了。这个也属于你该会的一个技能。我个人使用的是，通过深入谈话来对候选人进行了解。通过一个具体的问题，让候选者给出个设计方案或者思想。通过候选者对问题的回答和阐述，其实就很容易找出哪一个具有比较好的学习能力。那么，你要招的人就是他了。你接下来要做的就是对他进行内部培训，让他达到你所需要的技能。这里又涉及到一个问题，如何去做内部培训。在这篇里面，我不打算涉及具体的怎么去做内部培训，因为这又是一个大的话题。你可以自己去琢磨琢磨怎么弄，不是很难。我们不是要搞个培训学校什么的，只要可能达到你需要的技能。我想说：对于应聘者，其实只要可以做事并且有一定学习能力，他就是符合你的。什么要这要那的，都是浮云。

 

　　对于初级程序员的招聘，我们可以采取笔试题+面试的方法。一般招聘初级程序员的人数相对较多，而且有时会安排集体来考核。笔试的作用就是节省时间，快速的过滤掉不合格的人。再在筛选出剩下的几个人中进行面谈。

 

　　对于高级程序员的招聘，我们直接采取面试。这里我是极度反感使用笔试的。不是不能用笔试，只是你往往出不了很好的笔试试卷来考核高级程序员的水平。而且高级程序员的数量要求比较少，也不需要用笔试进行快速筛选。通过深入的谈话，就可以了解到很多你从试卷当中了解不到的。有时我们要结合一下公司自身实力来考虑是否需要大量的笔试题。要不然你会发现很难招到人，且不合适。如果，你是世界500强、你的工资开的非常高；那么，你想怎么样都行。

 

　　最后提醒下你，如果你需要特定的人时，或者招不到合适的时候。我们还有一个选择，可以通过猎头来帮你寻找。

 

　　其实，我只列出了些比较基本和重要的一些因素。当往后发展，你还会涉及到实习生的招聘。等层级结构变复杂后，还会涉及到架构师等很多细分的职位。但是只要我们明确，到底我需要他来做什么。明确需求后，其实招聘的过程都是大同小异。

 

团队关系：

　　团队关系我不会讲很细，只是会稍微提下，因为这话题本身就很复杂和深奥。想完全击破它需要花费长时间经验累积。不是说2，3年的管理经验就可以理解透彻。你要不断学习，不断去思考，才可能引导你进步。我就把我遇到的和理解的做个分享，以便于提供一个方向。最后，其中的对于错，还需大家结合实际去分析。

 

　　团队关系涉及到管理学里面的内容了，大家这时需要去读一些管理书籍，最好是西方管理和中式管理的都要涉及。西方的管理体制很完善和健全，但是很多地方不适合中国国情，特别是对人性的管理。学习西方的管理理念在结合中式管理是你需要掌握的技能。

 

　　团队关系的处理，分下来可以为两个方面：员工对员工的问题和员工对领导的问题。如当某个员工知道另一个员工和自己级别一样、能力差不多且工资却比自己高时或有员工工作态度比较随意和散漫，都会产生一个员工对员工的问题。当领导给一个员工加工资时，就会产生其他没有加工资员工对领导的问题；有可能还会产生其他员工对加工资员工的问题。产生这些问题都是人性管理当中的问题，每个人的性格不同，会产生很多你无法预计的问题出来。想要处理它，你需要长时间的经验摸索。一旦产生问题，就会影响团队和谐。当团队不和谐时，虽然不会怎么严重的影响到每个人手上的开发任务，但是会影响团队之间的合作效率。团队的合作效率一旦受到影响，开发的时间周期就会延长，并产生风险。所以Leader，你要好好照看你的团队成员。其实通过控制风险的一些方法，也可以看出团队之间是否有不和谐的端倪，我放在后面在讲。

 

　　团队关系的处理虽然复杂多变，但他始终是一个对人性管理的过程。我们只要满足了员工的基本需求，员工也会自我去调整和团队的关系。大的需求集中在：工资、工作环境和发展空上。当有员工开始出现问题，这时我们就需要了解是什么影响力他，让他产生了问题。普遍不会逃出这三个大方向。你在看是否需要满足他其中的一个要求。如果不在这三个之内，基本上都是些不太合理的需求，我个人认为是无理取闹。但是我们还是要细心去了解是什么其他原因。如很长见的是员工家庭的原因，这时你就需要进一步了解。如果是，可以给予帮助或合适的便利。

 

　　还有员工的跳槽啊等等都会产生员工的问题。这里不会再去讨论和解说了。只要你掌握了原理和深刻理解了，当出现问题时，你都会有方法来解决它。

 

风险管理：

　　对于刚开始做Leader的人来说，风险控制是很头疼的一件事情。有时心里会祈祷不要出现风险或对自己说应该不会出问题的。当有这种想法时是万万要不得的。一旦风险出来，你可能会慌乱和不知所措，最后导致项目的失败。那么风险管理的难点在哪里呢？其实就是在于你对团队理解深不深刻。只要你理解了团队，使用些晓得方法就可以控制住风险。最后你会发现风险控制很简单嘛，那是因为你对整个团队的流程和细节都了解清楚了。这时的你，也开始走上团队管理的正确道路上了。

 

　　在项目开发当中，最主要的风险就是时间。那么我就在这里击破它。首先我要说：如果你项目的复杂度所需的真正时间确实超过了老板所给的时间或者超过了你估计的时间，那么神仙也救不了你。因为一个是你老板的问题，一个是你自身的问题。如果是这样，你自己找墙去撞。除了这个之外，我们使用些小方法，就可以解决掉时间的问题。在分配任务时，我们都会明确的给予一个功能的具体时间。如果一个单个功能需要4个工作日以上的，就需要写报告来汇报功能进度（每3天一个报告或你自己定）。这样你可以很好的了解功能的进度，一旦发现可能会超期完成，你就要介入进去了解和分析是什么原因造成的。如果是你们确实低估了该功能的难度，那么马上进行调整，是重新分配工作时间还是降低该功能的要求。如果是员工个人原因造成的，那么你需要了解是什么原因造成的。看看这个功能是否需要与人合作开发。如果需要与人合作，那么很可能是产生了团队关系的员工问题。这时你需要去调解和解决问题。通过风险的管理，我们也可以找出一些团队关系的潜在问题出来。如果是个人能力不够开发该功能，那么马上更换人员进行开发。对于4个工作日以下的不需要发送报告，只用在功能完结时发个报告，以便进行下一个功能。因为这种功能时间需求短，一旦超期，是有时间来调换人员来做的。如果某人长期超期，你就要进一步去了解了。有公司强行每个员工每周写周报，有的是2个星期一写。我只能说，周报这玩意真的很稀烂。别跟我说是方便管理方便考核，这就是Cao蛋。这里还有一个问题，就是每个工作日的有效工作时间。有Leader是控制在一个工作日80%时间都在进行开发，有的甚至是90%。我个人喜欢控制在70%左右，因为一天能高效编写代码的时间也没有多少。而且一旦遇到有超期的功能，你就有人手和足够的时间来进行处理。我们要留出风险处理的时间。

 

　　当项目完成后，发现有Bug。这时可能已经接近项目尾声了，你没有多余的时间去处理Bug了，这时产生了一个风险。为了能把Bug在开发中就消灭掉，我们需要开发和测试并行执行。在项目开发的时候，测试组就根据功能接口开始编写测试代码。当有开发人员提交一个完成功能时，就可以马上开始测试，并当有Bug时可以马上进行修复。这也是为什么在一个工作日当中留多一点时间，因为你还有Bug要修复的。当Bug提交时，每天早上花30分钟（30分钟就够，不要花太多时间）集中程序员和测试人员快速开个会，把Bug全部过一遍。有些Bug是不用修复的，我们可以标出。有些Bug是需要排出优先级的，这时需要你来分配。通过每天对Bug的审查，当项目交收时，你会发现Bug都被你控制了。

 

　　还有一些突发事件引起的风险。如：程序员离职和项目中提出要求加工资。一般这两个因素会打扰你的整个计划。当出现这两个因素时，处理的优先级是最高的，要马上解决掉。如果是有人离职，就放他走吧。就算你强留下来，可人家心已经飞了。这对于功能完成和时间上的风险已经不好控制了。你要做的是赶快重新分配人手和调整时间，并马上进行招人。有人可能会说这哪里来的急。这里就要回到我前面招人所说的，明确你需要的每个人的职责和所需要的技能；当有复杂的招聘需求时，就进行拆分，使需求尽量比较单一。这样当出现问题时我们可以很容易招到合适的人。如果你招的是超人，那么到这里你就没法处理风险了。还有一个我们需要做的就是平时储备人才，遇到合适的就先招之。对于临时要求加工资的，分两个情况：公司没有一个明确的加工资制度和有正规的考核加工资制度。如果你们公司属于前者，你不要怪别人，你们自己都很Cao蛋；如果是后者，那么对于要加工资的杀无赦，并准备开始换人吧。

 

总结：

　　这是一篇初级的文章，我没有讲的很多，但尽量讲全。从文中我们可以知道，从团队开始的每一个环节都会和后面的风险处理紧紧相扣。这也是我为什么强调一定要理解什么是团队这个基础概念。要不然到后面，你会发现风险越来越不受你控制。就算你找到办法补救了一个，却还有很多未知的风险。你就等于在亡羊补牢。亡羊补牢我们都知道，晚了嘛。

转自：http://www.cnblogs.com/bruceli/archive/2012/06/18/2553270.html