• Team Leader你会带团队吗?你懂合作吗?你好像都不会啊!(上篇)
    时间:2012-06-19   作者:布鲁斯.李   出处:cnblogs.com/bruceli

    这篇文章是写给Team Leader和往这个方向前进的人。也适合一般的程序员,对你们在团队合作的理解上面会有所帮助;对你将来选择什在什么样的团队做事也有帮助。在文章中我也侧面道破了国内好多敏捷开发失败的原因。
    团队管理是一个比较大的范围和概念,但我们可以把它进行简化到以团队为基础,在团队上进行一些方法的应用。我在文章中,将分为不同的块讲解。当你把这些不同的块都理解清楚,结合起来就是团队管理。

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

    以团队开头:(如果你知道什么是团队,可以跳过)

        什么是团队?这里有个比较标准的解释:团队(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,整个任督二脉被打通了。这个电影也触发了我想写一篇团队管理的文章,但一直迟迟没有下笔。

    网友留言/评论

    我要留言/评论

    相关文章

    反反外挂驱动的驱动 - 给网游写一个挂吧(一):去年做了一些研究,研究做外挂的一些相关技术,打算放出来跟大家分享,分享一下我们做挂的一些思路,挂的原理,希望抛砖引玉。
    为什么离开的都是好员工?:很多公司有这样的现象,好多有能力的员工得不到赏 识,最后一一作出选择离开,等到后面原公司老板知道离开的员工待遇比自己给出的待遇要好得多,而且在与属下谈话,了解离开员工的工作表现和人品,却在属下 口中发现该离开员工作表现和人品都是非常不错的,作为老板和经理人怎么样才能用自己胸怀去接纳重用这些有能之士,用自己的眼光去识别这些人才为我所用不让 其离开?
    苹果公司的11个面试问题:又是一年毕业季,走出大学校园的你一定期待一份好工作。面试则是一个必经的过程,除非你是空降兵。下面让我们看看苹果公司的11个面试问题,你们能回答几个?
    用户访谈心得总结:最近做了一些项目的用户访谈,总结出些许经验心得,这里先就一些访谈过程的关键点作为一个开头,后续再来补充其他技巧等方面,大家也可以共同补充,同时欢迎大家拍砖。
    开发移动应用的 7 个致命错误:“幸福的家庭总是相似的,不幸的家庭各有各的不幸”,这个准则同样适用于移动应用开发者,最好的移动应用一般具备以下几个特点:美观,简单,实用,耐看。而对于不好的应用,有些常见的缺点是可以避免的,下面我们列举出开发移动应用时7个致命错误
    如何撰写网站文案:Sofa是我个人特别喜欢的一家公司,他们的产品,从软件本身到网站界面,均优雅精美,网页上的文案写的也好,总能敏锐的找到那句最直指人心的话来俘获潜在用户,本文即是负责为他们写作网站文案的专业作者的经验之谈,我读后感觉颇具可操作性。
    小设计有大学问:为什么滚动条在右边?:为什么大家每天使用的浏览器、word文档的滚动条都在右边呢?很多设计师认为把滚动条放在左边才是更好的设计,但是事实是自从施乐推出Star(第一台使用图形界面的计算机)以来,每种图形交互界面都将滚动条放在右边。 除开打字之外,拖动滚动条也许是图形交互界面中最常用的操作之一。想想你一般什么时候会使用滚动条。比如你在一个文档或者表单里找某个东西,你把滚动条一点一点往下拖动,与此同时你在文字中不断扫描直到找到你想要的东西。
    尽可能的不要一个人编程:我在宾夕法尼亚州匹兹堡地区一个有相当规模的制造公司里工作。我是那里唯一的一个 ruby 程序员。公司里还有个程序员,但我们的工作通常不相交,他不懂 ruby。来到这个公司后,我最终被分配的任务是开发 web 应用程序。之前,我学的是软件工程师,我花了大量的时间学习了底层编程,C/C++,甚至汇编。这里,我以为学习 web 开发是件很快乐的事,所以我买了一些书,开始研究。
    时间管理方法 - 管理人员必备:掌控:让你不必总是神经紧绷,也不会总是精神松懈,这就叫做掌控。平衡是一种最理想的状态。
    网站分析:系统邮件体验设计:每天我的邮箱都会收到很多系统邮件。有些是网购订单的状态通知,有些是网站活动宣传,有些是社交网站消息提醒。相信大家也都有和我一样的烦恼:怎么老是这么多垃圾邮件!淹没掉我重要的邮件啦!烦死啦!!你们有没有为我们着想啊!!其实从交互的交互来看这些邮件,还是有很多的学习地方的,俗话说:三人行,必有我师焉。择其善者而从之,其不善者而改之。所以今天我们来一起从分析下这些邮件。