【IT168 分析评论】
1.0团队建设所面临的挑战
团队建设是项目的人力资源管理的一个重要组成部分。其主要目的在于培养团队成员的能力，以及提高成员间的交互作用，从而提高软件项目的业绩水平[1]。
在我所在的实际软件开发项目中（用A项目做为代号来表示），团队建设所面临的挑战主要来自于四个方面：
1）项目产品开发团队内部结构较为复杂。整个团队分布在美国，印度，中国三个国家。而我所在的中国团队加入时已经是产品发布前的6个月左右，软件架构已经基本定型，但是还有很多工程方面的软件兼容性问题需要解决，否则会影响到诸多OEM客户的产品发布。
2）小组成员的相关领域软件开发技能存在一定的差距，此前并没有相关领域的开发测试经验，从而给项目的执行增加了风险。
3）项目的时间进度安排的很紧，由于OEM客户需要在圣诞节销售旺季前发布产品，因此所有的注意力都被放在软件产品的开发测试上面，本来计划中的内部培训课程，也被取消，而代之以直接边干边学的工作方式。
4）团队成员的士气不高。由于上面的几个因素的存在，项目团队成员表现出来一定的畏难心理和信心不足，制定计划和获得工作承诺的时候，普遍反映心里没底。
做为项目经理，面临此时的现实情况，首先考虑的是项目管理模型，即应用以质量为核心的“范围—时间—成本”三角形模型来分析此项目的内外部需求，进行任务的优先级排序，并且安排资源的使用，使得我们能够不仅在短期能尽快取得实际的进展，而且在中长期能够逐渐掌握主动，加快项目的进度。
在这里，我采用了头脑风暴和SWOT分析工具进行评估分析，以便较为全面的识别自身的长处和短处，机会和威胁，确定合理的短期和中长期目标任务。
其评估的具体的步骤如下：
第1步：拿一只笔一张纸，项目经理写下自己团队所有的长处（Strength）。接着，写下来所有的短处（Weakness）.要如实的去记录。
例如：
长处：
1.团队年轻，对于技术有热情；
2.愿意对相关领域进行深入研究；
3.这个团队此前有较好的项目开发历史，能承受较大压力和挑战，学习能力强，在美国团队里有较好的声誉；
4.团队成员与美国资深工程师有较好的沟通渠道，彼此较为熟悉；
短处：
1.在新的领域缺乏相关领域经验；
2.对于测试用例本身和测试覆盖缺乏了解；
3.对于新的软件开发调试工具不了解；
4.在本地缺乏资深软件工程师；
5.时差问题，和美国不在同一个时区，如果出现问题，不能实时得到反馈；
6.缺乏清晰的短期和中长期工作目标，并且任务的ownership也没有明确；
第2步：写下未来的机会（Opportunity）和威胁（Threat）。这些都是潜在的，将来时的。注意要有数据支持。避免凭空想象。
例如：
机会：
1.对于团队项目经理，是一个很好的案例来锻炼项目管理经验，并且能够加深产品开发周期的管理经验，应对各种挑战；
2.对于工程师，有机会深入接触到相关领域的最新技术，并且深入了解产品开发的技术细节；
威胁：
1.时间非常紧张，而我们并没有完成项目的Rampup，如果不能建立起有效的学习型组织，则就无法完成赋予的任务。
2.团队成员对于任务的紧迫性没有充分达成共识，彼此的配合也不够默契。
3.由于问题重现的困难性，有些软件调试任务可能会在不知不觉中花掉很多的时间，很难预测和控制这类任务的时间安排。
4.某些问题，需要协调公司外部的其它软件公司的配合才能够解决，而这些任务的时间协调也是较难预测和控制的。
第3步：召集一次会议，就分析的结果与大家进行讨论，在核心成员间达成共识，并制定接下来的行动计划，把评估结果转化成实际的行动。
分析完毕后，我们与美国和印度的团队进行了协调，并且就任务的范围，时间和每周工作任务量达成了一致。其要点包括：
此时，当任务的范围和时间目标基本明确后，项目经理的主要功能就转化为领导团队成员一起执行和调整。
1.2学习型团队建设
学习型团队建设是当今各个软件开发项目都会注意到的主题，对于团队建设的结果——提高软件项目的业绩水平，各个团队主体基本上没有异议，但是对于采用什么样的手段来发展，不同环境条件下的团队，却难以取得共识。在本文所提到的A软件开发项目中，我们也面临到学习型团队建设的问题，并得到出一些经验和体会。
经过上个阶段的SWOT分析后，项目经理发现此时团队成员的最主要瓶颈在于相关领域开发知识和经验欠缺，导致分析和解决实际软件产品问题的时候思路不多，方法单一，这方面的能力提高，是一个较为长期的过程，因此建设学习型团队是要从第一天就抓起的。
但是这个领域需要多个学科的经验和技能，做为项目经理，我并不是很了解那些知识和技能是最紧迫和重要的。因此，需要建立多学科小组对于此团队成员进行评估，它一般包括项目经理找到相关领域专家进行咨询，了解到那些技能是最重要的，以及如何最短时间就能掌握，如何针对某个团队成员的任务需要，学习某项技能等等。其关键在于，这些咨询和评估是用来界定团队成员需要的，必须围绕着团队成员的实际情况和他的个人任务需求（短期和中长期），来确定他所需要的知识和技能，这样才能做到有的放矢，磨刀不误砍柴工。
此外，由于项目刚开始时，团队普遍有畏难心理，而每个成员在工作中所表现出来的性格特征也不同（有的A型性格，有的是B型性格），因此在实际的项目操作中，项目经理可能会发现，一开始较难把一群人凝成一股合力，往往会遇到各种各样的问题。人们一般认为，问题主要是团队成员自身的态度不够积极，参与团建建设的意识不强导致的。与此对应的措施是项目经理要想办法激发成员的积极性，同时尊重成员的参与意愿。
但问题在于，成员真的不积极参与学习型团队的建设吗？还是成员无法积极参与？简单的讲激发和尊重有用吗？如何激发，又如何尊重？必须在软件项目开发的这个环境下，深入探讨成员没有参与的深层次原因，这样才能找到让成员积极参与团队建设的行之有效的办法。
通过我的实际项目经验，体会到几个制约学习型团队建设的深层次原因：
1.项目经理的权威不够，动员能力不足。项目经理不一定是相关领域的技术专家，因此团队成员对于项目经理所制定的目标和计划抱有怀疑态度，认为方向可能偏离了实际的需要。
2.成员可能有“搭便车”的心理，团队建设的培训和互相学习需要每个人的付出，这些学习性活动，虽然和成员密切相关，但毕竟和各人自己的项目任务比起来还是有距离的。所以等别人先做的心理就容易产生。此外，这种学习性活动是义务性的，往往“能者需要多劳”，有些成员往往产生观望心理。
3.团队成员存在经验分享的“交易型”心理，对于彼此知识的分享存在认识上的偏差，经验资深的团队成员可能倾向于保留，因为新进的团队成员无法拿出有吸引力的技能来与其交换，因此会降低资深成员乐于分享的动机。
这些因素都制约着学习型团队建设的开展，从而提高了项目的潜在风险和降低软件项目的业绩水平，因此需要项目经理加以管理和介入。
项目经理在介入时的要点包括：
1）了解团队成员各自在项目任务压力下，是怎么计划安排自己的学习内容和学习时间。看看每个团队成员对自己的学习计划，有没有深入的理解（insight），如果没有，则需要咨询专家帮助该成员制定合理的计划（提高学习计划的权威性），然后应当鼓励成员选择他自己感觉比较轻松的方式去学习。
2）鼓励成员间的正式的或者非正式的知识分享。正式的分享包括课堂形式的培训，非正式的分享主要是日常工作时的Q&A。对于前者，一般项目经理都是很重视的，这里要强调的是后者，我们发现非正式的Q&A对于新人尤其重要，因为他没有相关的经验，因此往往不能在课堂上提出很多具体的问题，往往需要资深成员在实际工作时来提供手把手的指导。项目经理应当通过物质和精神奖励的形式，推动组内各种形式的知识分享。
3）对于“交易型”心理，项目经理可以制定一定的学习制度来保证每个人都有机会和义务来分享自己的经验，如指定固定的每周学习时间，每个成员轮流给团队讲解一个技术方面的问题，然后得到大家的反馈。
4）项目经理要经常了解团体成员的反馈和态度。上面提到的都是学习型团队建设的工具，但是工具不能代替成员的态度。只有使成员在团队学习建设中，都具有“知情，决策，管理和所有”的权利，成员才能评估出他们真正的需求并且产生自我的学习活动。
经过一段时间的摸索，我们认为参与式团队建设是一种比较好的团队建设理念。
1.3参与式团队建设
为了说明“参与式”行动理念，让我们回到软件项目团队建设的出发点和归宿点，即项目和项目团队的需要上来，看看两方面的需求是什么。
软件项目的发展是一个多层面的进程，它不仅涉及到软件产品功能与可靠性逐渐成熟，更重要的是软件团队思想、行为和技能的成熟。可以说，一个成熟的产品，是作为一个成熟的团队的发展结果来获得的。对于此点，应该没有太大的异议。但是，传统的团队建设主要是自上而下的模式，这种模式主要是由管理者来驱动团队成员来获得开展，其特点更多的在于集体主义式的“求同”。在实际项目操作中，这种模式不能充分调动成员的积极性，因而经常出现结构失衡的现象，少数成员前进的速度很快，而多数成员没有办法赶上，降低了团队继续发展的动力。
参与式团队建设，正是作为对传统团队建设的反思的面目出现的。它强调尊重团队成员的差异，平等协商，通过软件项目组成员的积极，主动的广泛参与，实现项目组的持续有效的发展，使得成员都能够在建设过程中得到收获。参与式团队建设的另外一个优点在于，通过更多的让团队成员参与到项目规划和决策的过程中，团队成员不仅能够提供项目所需要的专业技能，而且把项目的任务需求转化成自身的学习需求，增强了成员对于项目的承诺。
这种参与式团队建设，其核心思想就是授权给团队成员的过程，让成员积极的介入到与自身有关的团队活动中，实现自我负责和自我管理[2]。这里要强调的是参与式团队建设的三个要点：
1）思想、行为和态度
前面提到，工具不能替代态度。项目经理需要起到模范作用，通过各种日常项目工作的影响，影响整个团队的参与合作态度，并且用事实来证明给团队成员，看到参与式团队建设的积极作用。
2）知识共享
鼓励团队内部形成良好的知识分享习惯，包括知识方面和技能方面，并予以适当的奖励。
3）参与式团队建设的工具
可以使用多种工具，除了常见的SWOT分析，头脑风暴，反馈和奖励等等几个工具之外，还有一些新的工具可供参考。
以上的三个要点，最为核心的理念是“移交指挥棒”，项目经理起到开头作用和表率作用，然后应当让团队成员发挥创造力和责任心，并和团队一起定期的反馈和检讨，不断优化流程，提高效率，这样每个团队成员也就认识到自己在项目中的职责是重要的。
通过半年多的实验运行，这个软件团队成功的完成了多项任务，和整个产品开发团队一起，提前了产品的发布时间，并解决了不少直接影响OEM厂商发布产品前遇到的问题，从而为这个软件团队赢得了各方的好评。在这个过程中，团队成员自身也比较从容的完成了各自的任务，专业能力也得到相应的提高，保持较高士气和工作效能。
1.4总结
本文以一个实际的软件产品项目A所遇到的团队建设问题为案例，提出采用自主参与式的理念和工具来进行团队建设，通过“移交指挥棒”的方式，项目经理调动团队成员的工作主动性和创造性，从而提高团队的业绩水平。在可以预计的未来，随着IT行业的发展以及各方认识度的提高，参与式团队建设的理念必将取得更广泛的采纳和应用。
参考文献
[1]美国项目管理协会，《项目管理知识体系指南》第三版，电子工业出版社，2004
[2]著，《参与式社会评估：在倾听中求得决策》，，2005
