软件经济学五：创建高效率的团队



本文来源：谢老师的博客

我们已经从各个层面讨论了软件经济学对于过程改进的影响，但是还有一个最重要的因素也是最困难的问题需要分析，那就是：在任何情况下，团队是决定项目经济效益的最重要因素。当项目开发出现拖延、质量低下等等问题的时候，我们可以考虑，这些问题的出现，很大程度上是由于机构对团队重要性的误解造成的。经验表明，在大部分情况下，处于灾难项目的团队一定存在这样或那样的问题。
    软件经济学不仅仅是在算钱，更重要的是从经济学的角度出发，来寻找提高软件开发效率与质量的途径。由于现在软件组织的技术领导或者项目负责人，大多数是从技术岗位提升起来的，它们对新技术应用充满着激情，迷信只要有了好的技术就一定能够高效率开发。潜意识里认为人这个因素既简单，也不需要花时间去研究。另一方面，管理者认为只要有了很好的规则（流程），人们就会按部就班高效率的工作了，其实这都是误会了。事实上这个世界上最难处理，影响最深远，最需要管理人员水平的方面不是别的，正是人！
    有一个真理我们需要永远记住：“战争的伟力及其最深厚的资源，存在于民众之中。”“在世界一切要素中，人是第一最重要的。” 所以，从经济学的角度来看，创建高效率的团队比什么都重要，当我们用软件经济学的观点来定义过程的时候，一定要把思考的重心放在团队建设上，要让团队建设与过程规范相匹配，过程中需要有人的位置，绝不能只见流程不见人。

 

    1，建立享受工作的氛围

 

    我们应该建立一个什么样的过程？过程改进的方向是什么？我们可以设想，当员工在阅读上千页的规范文档的时候，他们的表情是什么？是皱着眉头还是兴高采烈？既然团队建设如此重要，那么团队建设的目标是什么？什么样的团队才是好团队？
    如果我们建立的过程仅仅是一种被动的规则，员工处于被管理位置。如果软件过程哲学是力争建立一个压抑的氛围，多数员工在单独的隔间内盯着计算机屏幕，被动的完成领导交待的任务。没有交谈，没有一起活动，更没有员工一起从事所喜爱的工作的氛围。如果我们建立的过程致力于面对面交流最小化，过分强调书面交流，造成人与人的关系越来越公文化。没有面对面讨论或者讨论不充分，难以激发想象力。那么，我们怎么能说这样的过程是良好的、能激发人们的积极性、想象力和创造力的过程呢？
    软件开发具有天然的创造属性，我们所建立的过程应该便于人们面对面交流，共同分享信息，相互理解和解决问题。我们所建立的过程应该让参与其中的人们非常享受该项目的工作，并从工作中体会到了无比的快乐。当好的过程被实施的时候，人们应该是轻松与快乐的，每天上班员工走进办公楼，人们会相互问候，走廊成了谈话和讨论的场所，而不仅仅是走路的通道。过程中应该有定期的会议、评审、回顾，应该便于人们从过去的工作中发现问题、获取灵感以实现新的提升。
    在这样的过程指导之下，我们的员工会盼着一早来上班，与朋友、同事共同合作，张开想象的翅膀，完成他非常乐于完成的事情。在这个氛围下成长起来的员工，要比唯唯诺诺听从指令下熏陶出来的员工，对公司的价值将更大，员工的成长也更快，这样的团队才是好的、有价值的团队。过程不应该是死板的、僵化的、压抑的，这样的过程才是一个真正能够提高经济效益的过程。

 

    2，减少沟通成本

 

    那么怎么样才能建立这样的团队呢？首先要解决的问题，就是有效的沟通。

    1）大型团队沟通上具有特殊困难
    大型团队在沟通和协调方面存在着特殊的问题。如果你是项目中惟一的一个人，你可以以你任何喜欢的方式工作，而不必和别人沟通和协调。可是当项目中的人员增加时，沟通的渠道和协调工作也需要增加。沟通渠道数量不是按人数累加，而是n(n-1)/2，其中n为人数，如下图所示

 

    一个2人的项目只有一条沟通渠道；一个5人的项目会有10 条，10人的项目会有45条（这里假设每个人都和其他人沟通）。大型项目一般会有50或50个以上的开发者，会至少有1200条潜在的沟通途径。沟通的渠道越多，在沟通上花的时间就越多，沟通的成本就越高，沟通的错误率也越高。
    2）为保证效率大型团队需要细化组织
    一个有1200条沟通渠道的项目由于有太多的沟通渠道并不能有效运作，实际上，一个50人的大型项目组不能保证每个人都能和其他人沟通。所以过程改进的重要目标，就是使沟通简化和形式化。所谓形式化就是以规则的形式设定沟通的节点、目的、形式和目标，这是大型项目成功的重要因素。
    另一方面，为了简化沟通渠道就会对团队的结构有很大的影响。简化沟通的方式主要是创造某种层次，就是说，把大的团队划分成若干小组，每个小组的功能像团队一样，然后由小组中指定代表来相互沟通和与管理部门沟通，这样就可以大大减少沟通的成本。
    3）需要专人负责概念完整性
    由于一个大型团队被分成了多个小组，就必须有一个人来最终负责产品概念上的完整性和一致性，这非常关键。这个人的工作是确保把团队的所有成功的局部解决方案，扩展成为成功的全局解决方案，并保证同一类问题用同一种方法来解决，确保减少后期维护和将来升级上的成本降低。这个人可以是首席架构师，甚至有时是团队管理者。

 

    3，团队合作对于开发效率的意义
   
    从经济学的角度来说，效率是决定经济效益的关键因素。很多人认为只要有好的管理方法和过程，不同的员工和团队的工作效率就可以差不多。其实不然，相当多的研究证实不同团队的生产力水平有很大的不同。统计表明，在不同经验和不同背景的小组中，生产力会有大约5 : 1 的差别。在相同背景和相同经验的小组中，生产力也会有大约2 . 5 : 1 的不同。   
    什么是团队？并不仅仅一组人恰巧在一起工作就可以构成一个团队。所谓团队指的是：能相互负责的、具有共同的目的、共同的执行目标和共同的方法的有互补技能的一些人的组织。在过程定义和改进中，需要在任何特定的任务中实现团队合作，包括：
  1）开发和审查项目需求。
  2）开发系统架构和设计指导方针。
  3）定义将项目中技术环境的各个方面。
  4）开发在整个项目中使用的代码标准。
  5）协调一个项目的相关方面工作（包括在子系统，模块和类间定义界面）。
  6）设计系统中的困难部分。
  7）检验独立开发者的设计和代码。
  8）调试系统中的困难部分。
  9）测试需求、设计和代码。
  10）审计项目的进展情况。
  11）软件建成后的维护（包括对维护请求的应对和进行紧急修复）。
    尽管一个人可以单独完成其中任何一项任务，但是两个或更多的人共同完成会使大家都受益，这也形成了团队成员之间无形的相互影响。如果大家共同合作，整体有时会比所有个体部分相加的总和还要强大。如果大家之间有冲突，整体会比所有部分相加的总和还要弱小。只有当两个人合起来比两个人单独要好的时候，“团队”才有存在的必要。
    软件过程的定义需要有利于创造团队的凝聚力。有凝聚力的团队会具有一种特殊的“团队动力”，或者说一种文化。团队成员在这种文化氛围中会自然的工作努力、热爱工作、不惜为实现项目目标花费他们大量的时间。而没有“团队动力”的参与者经常不能集中精力甚至会影响士气，并且在与团队目标不同的方向上花费大量的无效时间。所以，判断员工是否称职的时候，应该把员工对于团队凝聚力的贡献作为首要标准，其次才是他的个人能力。

 

    4，创造高业绩的团队

 

    高效率的团队往往也是有高凝聚力的团队。这种团队有什么特点呢？
  1）共同的、可提升的愿景或目标。
  2）团队成员的认同感。
  3）结果驱动的结构，
  4）胜任的团队成员。
  5）对团队的承诺。
  6）相互信任。
  7）团队成员间相互依赖。
  8）有效的沟通。
  9）自主意识。
  10）授权意识。
  11）小的团队规模。
  12）高层次的享受。
    下面我们将逐一解释这些特性如何在软件团对中应用。
    1）共同的，可提升的愿景或目标
    高效运行的团队对于自己的目标都有清楚的认识，共同的愿景有助于各个层次高效率的开发。每个人都赞成大的愿景，在项目愿景上的一致，就可以使小问题的决策简化，团队可以快速做出决策并毫无争议地实施。共同的愿景使团队成员间建立相互信任，因为他们知道他们都是为着共同的目标工作。共同的愿景还可使团队集中精力避免在迷途上浪费时间。一个高效团队建立起来的信任和合作，使得他们能胜过相同技能的个人的总和。
    2）团队成员的认同感
    当团队成员朝着他们共同的愿景一起努力工作时，他们也开始感受到团队成员的认同感。团队成员可以从团队的成就中获得满足，这使他们把共同的目标看得比个人的目标重要，因为他们在团队中有机会实现仅仅通过个人无法实现的东西。
    伴随着认同感，高效率的团队经常还显示出一种精英感，他们为着成功地完成一项极具挑战性的任务或有异常的业绩才加人这个团队，并且努力实现自己的价值。我知道一个项目，这个项目被确定为只是对公司的“低端产品”负责。这样阐述团队的特性是一个错误，因为这样的团队成员往往缺乏自豪感，随之也就缺乏认同感。
    3）结果驱动的结构
    结果驱动的团队结构有以下四个基本特征：
  角色必须明确：每个人必须在任何时刻都对各自的工作负责。责任对于有效的决策制定和对已制定决策的快速实施十分关键。
  有效沟通：团队必须有有效的沟通系统，以支持信息在团队成员间的自由流动，即使在团队和经理之间沟通也可以自由进行。
  有效监控：团队必须以某种方式监控个人表现并提供反馈。团队应该知道谁应该受到奖励，谁需要个人的进一步发展，谁能够在将来承担更多的责任。
  决策以事实为依据：任何时候的决策制定都要以事实为依据，而不是以个人主观的意见为依据。团队需要确保没有偏见地了解事实，因为这些偏见会削弱团队的职能。
    人们确实在努力建立这种团队结构，但令人意外的是，确实有非常多的团队结构不能满足上述要求。
    4）胜任的团队成员
    团队成员也常常由于错误的原因而被选择。例如：有些人被选择常常因为他们在项目中有股份，或他们要价不高，或仅仅因为他们有空，而不是因为软件项目的经济效益而被选择。这会给团队带来比较大的问题。
    在一个好的团队中，团队成员应该是一个多面手。只要团队需要，人们就乐于在不同的时间扮演不同的角色。经常遇到的情况是：在一个好的团队中，一个技术专家很乐于为商务谈判专家充当顾问角色。如果在团队中有两个用户界面专家，那么当一个人致力于用户界面开发的时候，另一个人可能就会改做数据库工作。一个经常扮演技术指导的人在一个特定的项目中，当有太多指导者的时候也会自愿转换成程序员的角色。这种团队氛围，往往是团队将会走向成功一个标志。
    5）团队的承诺
    愿景、挑战和团队认同感结合在一起，会使团队成员可以向团队做出承诺。在一个高效的团队中，团队成员将他们的时间、精力与努力都奉献给团队，这就是所说的承诺。
    承诺驱动的开发是非常有效的。当团队成员承诺时，他们必须要有承诺的对象。他们不能为不实际的目标做承诺。你不能为“所有经理要求做的”事情做任何深人的承诺。愿景、挑战和团队认同感为团队成员的承诺提供了内容。
    6）相互信任
    信任包括四个部分的内容：诚实、开放、一致以及尊敬。如果违背了其中的任何一个部分，甚至只有一次，信任也会被破坏。
    我们有理由认为，与其说信任是高效的原因，倒不如说信任是高效的结果。你不能强迫团队成员之间相互信任。但是一旦团队成员承诺于一个共同的愿景，并且开始将团队视为一体，他们就会学会负起责任。当团队成员看到其他人真正将团队的利益放在心上，并且意识到他们有一个可以遵循的轨迹：诚实、开放、一致和相互尊敬，信任将由此而产生。
    7）团队成员间相互依赖
    团队成员借助各自的优势，做最有利于团队的事情。每一个人都觉得自己有机会为团队做贡献并且，认为自己的贡献很重要。每个人都参与决策。健康团队的成员有时以某种方式依靠其他团队成员，互相的依赖可以使团队具有凝聚力。每个人都被吸引到各自工作的岗位上，没有人感觉被遗漏。
    8）有效的沟通
    沟通不仅仅是一种形式，更是一种态度。有凝聚力的团队成员之间会经常保持联系。他们觉察到当他讲话的时候每个人都能理解，他们分享共同的愿景和认同感，这一事实协助了他们之间的交流。在相互依赖和信任的环境里，当团队成员一旦意识到不愉快的问题，他们就可以提出来，还有时间进行有效的补救行动。与之相反的方法就是掩盖错误，直到它们太严重而无法再掩盖，这对于高效率的开发努力是致命的。
    9）自主意识
    高效的团队会给团队成员机会去做正确的事，他们能够不受干涉地工作。没有人不犯错误，团队成员可能会犯了一些错误，但是激励的益处足以能够补偿错误。自主意识与他们从经理那里感受到的信任水平有关。经理信任团队是非常必要的。这意味着团队管理不要过分细致，不要任意的批评或施加强硬的决策。
    10）授权意识
    高效的团队需要意识到被授权，他们可以采取任何为获得成功所需要采取的行动，例如购买某些为提高效率而需要的软件。组织并不仅仅允许他们去做他们认为对的事情，而目，要在做的过程中支持他们。
    11）小的团队规模
    团队的成员最好在5～ 9人之间。如果项目要求多于10 名成员，就要试着将项目分成多个团队，每个团队一定不能多于10名成员。10个人的限制主要适用于单一项目团队。团队规模的另一极端是成员太少，少于4个人的团队也难以建立认同感，小组会受制于相互之间关系，而不是小组的责任感。
    12）高层次的乐趣
    并不是所有愉快的团队都是高效的，但绝大部分高效的团队都是愉快的。这有很多原因。首先，开发者喜欢成为高效者。如果团队能够支持他们高效的愿望，他们会很高兴。第二，人们天生喜欢做他们喜欢做的事。如果他们花更多的时间去做，他们会做得更多。第三，使团队凝结在一起的部分原因是团队内部的幽默感，比如大家都喜欢某种娱乐方式。我从没有见过一个有凝聚力的团队是没有内部的幽默感的，这也许是我个人的孤陋寡闻。
 

    上述讨论是不是太过于理想化了？是的，世界上没有完美，在这个支离破碎的世界中完美是不存在的。但人们需要有理想，人类社会的发展不就是一代又一代人对于理想的追求过程中发展起来的吗？过程改进的目的不是把所有的人都变成机器，追求经济效益的目的也不是把员工变成苦行憎。规则是必要的，但软件是一个创造，我们的过程不能见物不见人，而是考虑要如何充分发挥每个员工的积极性、主动性和创造精神。软件开发和普通的制造业流水线不同，不能使用完全相同的生产过程概念，这一点是讨论软件经济学时需要牢牢把握的。
（完）