我从事IT行业多年，从研发开始；d、逐步管理开发团队，然后进行项目管理，保持自己编码的习惯。在这个过程中，我逐渐获得了很多团队建设和项目交付的尝试和经验。同时也从行业内同行那里学到了很多知识分享，并对经验进行了总结和分享，希望能对同样在IT行业打拼的小伙伴们有一点帮助。 　　

　　# 1.从组织到团队 　　

　　从表面上看，组织和团队表达的内容是相似的：一群来自全国各个角落的人聚集在一起，为了一个共同的革命目标而做事，组成一个组织。如果是这样，那只是一个组织，而不是一个团队。团队的区别在于自主性，成员是自愿组合的，目标是主动寻求的，分工是逐渐磨砺的。其实所谓的高效团队是一个伪命题。如果一个组织可以被称为一个团队，它本身就是有效率的。否则只能叫碎片化。组建一个团队从来都不容易。IT团队的建设更具挑战性。只有以人为本，注重人才的培养，从最基本的目标设定和任务分配入手，才能逐步实现。 　　

　　高效的开发团队包括四个要素：人员、流程、技术和团队文化。一群可靠的人，一套有效的团队流程和实用的技术和工具。这三者构成了高效团队的三驾马车，也是团队管理中最传统的三要素。一个高效的团队应该有赢得想法、及时交付的习惯，以及实现卓越目标的能力。这是团队随着时间形成的团队文化，团队文化是团队效率的第四要素。 　　

　　目前项目组工作效率不高，投入和产出不成正比。造成这种情况的原因只有以下几点： 　　

　　1.团队没有向团队成员清晰地描述团队的发展计划，团队成员无法将自己的发展计划与团队的发展计划结合起来。没有独特的团队文化。 　　

　　2.团队成员的知识储备是被动面向项目的，有些知识没有很好地传承下来。这使得项目在引进新技术方面进展缓慢。 　　

　　3.项目进度的可视化程度不足，没有有效的团队流程，没有良好的执行力，任务分配器无法准确衡量工作时间和风险。 　　

　　本文着重从人、技术、团队文化等方面探讨提高团队效率的途径，希望能找到一条长期高效的团队建设之路。 　　

　　# 2.文化决定了团队的基因 　　

　　除了跟随一些公司的基因，团队的基因也是由团队管理者塑造的。性格决定命运，格局决定结局。一个铁营，一个流动的战士。团队的文化和气质决定了团队的基因，就像强调标准化和流程化的团队决定了团队的交付能力会优秀，但创新能力可能会受到规范的约束；相反，一个特别强调创新的团队，必然是完全没有规范的，但新的想法和理念往往会爆发。 　　

　　# 2.1团队文化的选择要结合团队的业务形式。 　　

　　任何团队的文化都是团队领导的文化。 　　

　　一个团队可以选择适应多种文化，比如在创新、完美和遵守规范之间选择平衡。但是，作为一个团队，需要培养一定的野心，这是团队不断前进的内在动力。团队需要虎头虎脑的员工，不断给团队注入动力。但无论你选择什么样的文化，都必须与团队所做的业务相匹配。比如产品导向的团队可以选择快速交付、结果导向、极致等作为团队文化。运维团队可以选择规范、专业、可靠作为团队文化。只有团队选择了合适的团队文化，团队的能力才能最大化。 　　

　　一个团队的能力包括员工思维、员工能力和员工管理，尤其是员工思维，是团队文化的集中体现。大部分团队做的是分配和安排，他们愿意做的是团队中少数人的行为，他们愿意做好的是少数人的行为。而在程序员的管理上，目前大部分团队都采用精细化管理，管理者在项目开始前花大量时间进行调度管理，细化到第二天，然后把时间用来工作，把进度反映到计划中。如果任务比预期时间长，项目负责人会立即从其他团队抽调人员参与，以加快进度。程序员也学会了预留意想不到的时间。然后奇怪的事情发生了：一切都慢了下来。这是为什么？对于企业来说，软件的精细化管理很有吸引力。任何组织都渴望控制成本，想知道程序员的投资回报，想准确预测截止日期并做出有效的成本- 　　

　　收入分析。但是这种方法没有理解软件开发的本质。软件开发是一个创造性和实验性的过程，是一个需要多次理解和实现的复杂系统。具有主动性和自主性的人最适合高效和创新的工作。开发者需要实验，避免错误的设计方法，有选择方案的自由。如果你问我一个函数需要多长时间才能完成，诚实的回答是不确定的，有一定的概率会出现长尾效应。如何管理开发者，首先应该给开发者自主权。软件开发更好的方法是设定高级目标，然后由开发人员自由完成。他们有可能会失败，项目负责人需要为意外情况做好准备。但是不要强加更多的过程和控制来处理失败。致力于打造值得信赖的成功团队。 　　

　　# 2.2建立团队文化的有效途径——工位会议 　　

　　站在团队中的意义将对团队文化的建设和团队的高效运作起到重要作用。虽然团队一直在前进，但并没有为团队产生足够的动力。与会者应澄清以下三个问题。 　　

　　1.我在过去的会议周期中做了什么？ 　　

　　2.下一个会议周期我打算做什么？ 　　

　　3.目前遇到了哪些障碍？你需要其他团队成员的帮助吗？ 　　

　　团队成员通过回答“你在过去的工位会议周期做了什么”来暴露项目实施的进度；每个组员回答“下一个会议周期我计划做什么”，解决计划调整和执行的问题，并向大家讲清楚。 　　

每日站会除了具备使项目高度可视化的功能，还具备凝聚团队，使得团队高度互助，充分调动主观能动性的作用。站会有一个“仪式”的功能，每天开站会的时间就是一次团队建设的机会，通过短短的时间交流并提醒团队：我们是一个整体，我们需要共同为承诺负责，我们每天都有一个清晰目标。团队通过每日站会的形式，所有成员对项目进展、近期计划和已经发生的问题都有所了解，在这样的环境下，他们可以充分发挥项目主人翁的精神，让每个人都负担起责任、相互合作，为项目的开始时定下的目标努力。

# 2.3影响站会效果的因素

团队在进行的站会时常会发生以下几种情况，从而降低了站会的效果。使得站会无法达到预期的效果，久而久之失去站会的意义。

# 2.3.1会议讨论蔓延

团队中的成员在会上讨论或试图解决一些技术问题，这样往往会扩大讨论的范围，并且耽搁团队中部分成员的时间导致效率下降。

改正措施：有争议的方案或技术风险问题，在会上跟成员约定好，线下讨论，团队Leader可根据情况决定是否跟进。在下一个站会时，可将问题讨论的成果与团队成员联络周知。

# 2.3.2向管理者汇报

团队中的成员仍觉得站会是在向上级汇报工作状况，而非向团队其他成员汇报。站会的目的是要将项目的状况展现给所有的成员，让团队成员对每个任务的进展都有所了解和关心，这样团队成员间才能较好的交流经验，让彼此成为Backup变为可能，长期保持这样的气氛，有利于培养团队互助的氛围。如果单纯向管理者汇报，而对别人所讲的内容漠不关心。久而久之，站会就成为大家的负担。

改正措施：每个成员不单单汇报工作进度，也需分享自己的工作经验，汇报尽可能简短，不耽误其他成员太多时间，紧凑、流畅的会议进程有利于集中大家的注意力。

# 2.3.3管理者过多干预

部分团队的管理者有较强的控制欲望，会习惯性的在会上对团队成员提出超出会议主题的谈话内容，如对某个功能进度的询问，提起讨论某个技术问题，渴望现场解决团队遇到的阻碍等。这些做法都将损害团队开会的节奏性和专注性，会使得会议的内容蔓延，会议时间延长，导致很多与讨论内容不相干的团队成员被迫参与讨论而浪费时间。最根本的问题是它会破坏团队自由、积极的基因，久而久之，大家会回到传统听后命令、等待安排的被动工作状态。

改正措施：不直接参与项目交付的成员不要在站会发言。如果有需要询问或了解的技术细节，可以线下进行。

# 2.3.4回答太过简单、机械

有些团队成员在站会时汇报或回答方式比较应付。比如说“我今天开始修改AM0100X_01的程序，发现了几个Bug，修改了，其他没问题。”这样的汇报对于团队其他成员来说毫无启发作用，也没有任何参考价值。汇报的内容首先要让团队所有成员都能了解项目的进展处于什么阶段；其次在听和说这些问题的过程中，了解到哪些同事所做的任务和自己的任务有关联，或者遇到过类似的问题，解决的思路是否可以互相借鉴，完成某些任务的经验是否可以相互借鉴等。这些才是每个成员参加站会时真正应该关注的。而前面的回答方式，对别人来说无任何价值。

改正措施：在回答三个问题时，一定要相对具体且精炼地给出对其他人有价值的内容。尤其跟团队别的成员有交互的地方或者需要引起注意的地方，要特别注意。如前面的回答可以改为“我今天开始修改AM0100X_01的程序，发现了几个Bug，造成问题的原因是因为共同代码中遗漏了XX

case，目前的解决方式是XXXXXXX，大家在使用这个方法时需要做XXXXXXX”这样的回答相比前面的描述，无疑对团队其他人来说更有价值。

# 2.4站会的价值

每日的站会实践并不像其表面看起来那样简单容易。团队必须在实施的过程中利用回顾会议，定期进行反思和改进，逐步体会到其价值和精华所在。如果没有这样的回顾过程，团队按照之前的运作习惯或单纯地揣测、模仿，不但无法获得任何价值和帮助，而且可能深受其苦。所以首先团队要明确站会带来的价值。

# 2.4.1 了解状况，未雨绸缪

每日的站立会议帮助团队成员了解项目当前状态，让所有人对项目进展和所面临的风险都了然于胸。从项目的角度来说，做到了项目状态和风险的可视化。对团队成员来说，让每个人都置身项目的全局中，有利于后续调动团队成员的主人翁意识。也更利于管理者发现项目的潜藏危险，从而可以较早的制定相关决策或采取应对措施。

# 2.4.2 增加团队成员的团队融入度

站会的交流方式让团队成员富有责任感，可以在站会上让团队成员领取任务，这可以让团队成员在参加每日站会的时候更加关注项目相关的所有信息。因此，当项目出现问题时，不再是某一个人的问题，而是大家的问题。所有人都有责任出谋划策，让问题尽快得到解决。

# 2.4.3 交流沟通，资源共享，培养主人翁意识

团队通过互相交流，彼此分享经验，主动求助或提供帮助给他人的方式，逐渐活跃组织气氛，增强团队成员主人翁意识，从而最大限度的发挥每个人的能量。而且，在这种团队氛围下，团队成员的个人技能提高速度必然更快。

# 2.4.4 增加向心力

团队齐心协力，通过合作的方式共同完成项目目标，众人一心，其利断金，这样的团队更具备解决问题的能力。

# 三、人才是团队的重要基石

没有人，何谈团队？一个高效的团队需要什么样的人？需要勤奋、每天不是加班耗时间，而是主动做事情的动机和行动；热爱自己的产品，珍惜自己和团队的劳动成果、以积极的心态对产品持续地进行优化和改进；有钻研技术和解决问题的精神，针对技术坚持不懈的努力，寻找解决问题的自由方案并执行。

# 3.1团队成员需培养的能力

在团队中可能有很多原因导致团队的效率不高，但可以归纳为一点，就是有技能的人的问题。每个岗位的员工需要掌握岗位所需的技能。有些员工在起初具有岗位所需的技能，但在团队的发展过程中固步自封，最终成为团队效率提升的阻力，作为团队的领导者应该着重培养团队成员以下方面的能力。

# 3.1.1主动学习的能力

技术更新日新月异，一个优秀的程序员必须要跟上主流技术的发展，经常性的打破自己的瓶颈，而不能抱残守缺，固步自封。通过阅读书籍或通过互联网搜索等方式获取工作相关的知识和技术，并对获取的知识和技术进行加工和理解，从而不断的跟新自己的知识结构，提高工作效率。

# 3.1.2务实精神和坚韧性

程序员的任务是要开发一款有效的可用的软件，而不是在技术方面达到十全十美。如果不能快速地用优美的代码达成目标，应该先选择快速地完成任务，然后在空闲时再重构和优化自己的代码，这是一种务实的精神。而遇到技术问题时，往往需要想尽一切办法去解决它，一个优秀的程序员应该，享受解决问题的喜悦，对于困难有坚韧的态度和精神。

# 3.1.3激情与全情投入

高效的程序员需要对代码，新技术、新工具的引进以及团队协作有充分的激情，能够在大多数时间里全情投入，付出超出自身能力的努力，创造出创新的机会，不断的完善自我。让自己在从平凡到优秀，从由优秀到不凡的道路上坚定前行。

# 四、技术是高效团队的后盾

团队的技术要以核心成员的技术为主，避免用的过于杂乱。对于多数服务型的团队技术的选型应该以稳健、易维护为主。而在项目的进行过程中技术团队会使用大量的知识，所以在技术团队中为了提高整体的技术能力，需要做好知识管理的工作，确保管队的人员可以在技术上得到快速成长，尽早形成战斗力。目前团队中的很多知识是以模仿的方式进行，这样的方式造成许多知识无法举一反三。所以知识管理应该围绕学习展开。

以知识工作者为主的IT企业内存在着大量的知识。有些存在于公司的内部资料中，有些存在于互联网上。知识要先学会才能产生价值，所以很多问题并不是缺少知识，而是缺少学习。因为存在电脑上中，互联网上的知识不能产生价值，只有被人学会了才能产生价值。学习不是靠简单的几次培训或者读资料就能做好。

# 4.1技术领域相关学习的特点及理论

# 4.1.1情景认知理论

心理学的情景认知理论认为，认知是情景化的的，人类学会了抽象的知识后，往往会在具体的场景下忘记使用这些知识。很多知识并不是我们不会，而是在特定的场合我们忘记了去使用它，或者说我们没有意识到这个知识是可以用的。到时使用的环节，知行之间的巨大鸿沟会展现在我们的眼前，识别问题，意识到当前是使用该知识的正确时机并不是容易的事情。在IT领域我们知识都是和实践相关的。

# 4.1.2生物学基础及挑战

从生物学的角度，每个人的大脑都是不同的。我们无法简单的用整齐划一的办法解决所有人的学习问题，知识就是学习的生物学给我们带来的挑战。但人类的构造又总是相似的，所以我们总能得到一些学习的模式。比如，我们可以分析出学习某个知识的前导知识，要求学习者掌握，以此来提高学习效率，并且训练其倒推和发散的思维能力。

# 4.1.3教学的基础理论

为了提高效率，我们势必会组织教学，那么涉及到教学，我们就要了解一点教学理论。以下是加涅提出的九大教学事件

1.引起注意

2.告知目标

3.提示回忆原有知识

---|---|---

4.呈现教材

5.提供学习指导

6.引出作业

7.提供反馈

8.评估作业

9.促进保持与迁移

例如我们在组织某个知识学习的时候，仅仅是第一个要求“引起注意”就非常的困难，我们指导参加学习的人各有不同，有人会懂得一些，有的人却毫无基础。并且每个人的岗位不同，思考的方式也有差别。而最后一个事件“促进保持与迁移”也是非常困难地通过前面所讲的情景认知的理论，也许你完成的教学的过程，但也有可能到项目中不会使用，因为复杂的代码已经让你识别不出这个知识应用的场景。了解了这些之后我们就可以看清团队的痛点并且找到解决的方案。

# 4.2团队痛点

无法应对变化的业务需求。因为学习方面存在的问题，可能造成团队的技术陈旧，成本攀升。团队面对高速变化的需求时疲于奔命。在互联网化趋势日渐明显的今天这个压力变得更大。

# 4.2.1过多的在项目上实践新技术。

项目中由于学习新技术而造成的开发效率下降这种情况要从两方面考虑：一方面，IT领域学习内容大多属于技能，技能类的特点就是学习时工作表现会“先变差后变好”；另一方面，每种新技术，都是为了解决旧的问题而创造的，同时又要跟旧有技术争夺使用者，那么势必它的设计就是为了提高开发效率。也就是学习的最终意味着在效率上会有提升，只是过程“有些痛”。过多的使用新技术会可能会对团队造成巨大的成本压力，因此在实践新技术上应该把握好成本与收益的比重，必要时可以采用迭代的方式来逐步实现新旧技术的更迭。

# 4.2.2要学习太多会失去方向。

虽说新技术都是为了解决旧的问题而创造的，但并不意味每一种新技术都是能很好解决现有的问题，在开源的趋势之下，知识变得愈发海量化。面对林林总总的需要学习的内容，很容易失去方向。

# 4.2.3员工无法持续学习

团队中，陈旧的技术和做事方法往往一直在延续。要做出改进就需要持续的学习，但似乎团队中的人感觉没有学习的动力，而一些有学习动力的人有时又得不到帮助，比如学习和工作总是冲突。

# 4.3 提高团队成员学习能力的措施

# 4.3.1个人能力情况的可视化

只有有了个人情况的可视化，才能更好地平衡个人成长与组织发展的需求，并能监控组织的共识与个人的实际行为的差距。如建立个人能力矩阵，定期(每周)进行跟踪更新。在工作过程中可以对新人的代码进行code

review并在此过程中了解技术上的不足和成长点。

# 4.3.2建立教练机制

推崇教练机制是有以下几个原因：

1. 每个教练都可以撬动多个人，它减少了人员的管理难度，使得难度大幅下降。不需要专业的软件支持也能轻松进行。

2. 从人的心理来讲，每个人都渴望并需要私人定制的成长计划。一个有经验的教练就可以根据实际情况完成对他的成长计划的制定。并且在这个过程中帮助团队积累经验。可以将成功的经验复用于今后的新人培养中。

3. 教练可以管理新人的驱动力，可以根据人的情况引起他对于要学习的事情的注意，引发主动性，管理学习者的期望。

4. IT领域是以技能为主的。有些知识只是看书很难有成效，需要教练的辅助练习。才能将知识和实践结合。

# 4.3.3对教学的优化

即使是有了教练后，依然会有各种浪费。如果每个人的教练都自己准备教学的资料，好处是他们可以足够熟悉教材，坏处是重复的作业势必会产生，这将是一种浪费，并且可能会有各有偏颇和遗漏。

这就需要一些教学体系的支撑。优化教学的最终目标是能建立起一个游戏般的机制。需要有专门的人员来进行思考和设计。在互联网时代，知识在网络中随处都是。但验证是否学会了某种知识的题目却凤毛麟角。在教学的优化方面，以结合自己的场景总结的题库会对团队更有帮助。一方面，对教练来说可以关注于题目的结果。有针对性地指导并减少无谓的时间付出；另一方面，对学习者而言，目标更加清晰，而且可以更多的关注于学习的点，减少时间的投入。

# 4.3.4松散学习组织的促进

IT行业的一个特点就是知识更新太快，只有在团队内已经成熟的知识适合在团队层面上进行学习，而正在初级阶段的内容适合松散的民间分享形式展开。这种自组织的形态在知识更新比较快的情况下是性价比较高的学习形式。如小范围的兴趣小组，各个成员设立自己的学习目标，并对自学知识的分享交流。

# 4.3.5团队级的辅助

所有学习的推进都必须依靠团队的辅助。我们可能在绩效、考评或者学习资料等方面给予支持。对于松散组织形式下为团队积极学习的做出贡献的员工也应得到奖励，对

于教练的成果要给予积极的肯定。也要减少对加班的鼓励，因为加班会侵蚀学习时间。互联网时代，是一个知识极大丰富的时代，知识的更新换代速度不断加快。团队发展与囤积的知识相关性越来越小，与团队的学习能力相关性越来越大。越早重视起团队的学习能力就对团队获得竞争优势越有利。