如何才能建立出一支成功的技术型项目团队？
发表于2017-08-26
在IT的软件开发设计中，一直强有力的技术开发团队是项目成功且有效实施的关键。那么如何才能建立出一支成功的技术型项目团队？你可能会迅速的说出诸如执行力，体制的完善等相关的因素。确实，对这些因素的关注程度的高低直接影响着项目的成功以及提升商业伙伴及客户的信任程度。
日前，笔者对加拿大魁北克大学管理院教授Prosper Bernard就如何构建技术型团队的问题,进行了一次专访。
团队竞争力衡量与确认
这是构建成功项目团队的第一部，也是绝对重要的一步。
在构建团队的伊始阶段，团队成功完成项目的能力在客户以及项目组成员的观念思想中形成。教授Prosper Bernard 认为“这种观点的基本构成有我们常说的管理能力，技术能力以及项目领导的方向感。打个比方，如果项目领导清楚的知道‘如何运作’才能使他们的项目成功，项目的客户以及组员就会感到信心十足，而这种信任对团队士气有巨大的影响。” 加拿大魁北克大学管理院
我们知道有衡量软件开发组织成熟度的模型，同样在此思想的基础上，卡内基梅隆大学（Carnegie Mellon University）的软件工程协会（Software Engineering Institute，SEI）做出了团队成熟等级的模型，下面对这个模型的梗概做个介绍。
日前，笔者对加拿大魁北克大学管理院教授Prosper Bernard就如何构建技术型团队的问题,进行了一次专访。
团队竞争力衡量与确认
这是构建成功项目团队的第一部，也是绝对重要的一步。
在构建团队的伊始阶段，团队成功完成项目的能力在客户以及项目组成员的观念思想中形成。教授Prosper Bernard 认为“这种观点的基本构成有我们常说的管理能力，技术能力以及项目领导的方向感。打个比方，如果项目领导清楚的知道‘如何运作’才能使他们的项目成功，项目的客户以及组员就会感到信心十足，而这种信任对团队士气有巨大的影响。” 加拿大魁北克大学管理院
我们知道有衡量软件开发组织成熟度的模型，同样在此思想的基础上，卡内基梅隆大学（Carnegie Mellon University）的软件工程协会（Software Engineering Institute，SEI）做出了团队成熟等级的模型，下面对这个模型的梗概做个介绍。
初始型等级
处在这种等级的团队或组织倾向于采用一种混乱的、特别的、“按照自己的开发方式”的方法构建各种新的制度体系。团队的凝聚力较低，工作效率低。
重复型等级
团队或组织使用了计划技能，综合系统方式中的需求，利用软件质量确认技术，以及按照已经形成的路径图进行后续的努力。
定义型等级
团队和组织按照已经定义的方法步骤，使用过程提升技术以提高方法路径的有效性，引入规范的培训程序，以一种整合的观点看待整个系统开发过程，同时更多的使用正规信息工程和结构开发技术。
管理型等级
团队或组织切实的掌握并应用了软件开发标准，从而实现准确预计以及过程分析的目的。另外，一些全面质量管理（Total Quality Management, TQM）的观念也被应用于提高整体开发过程效率。
优化型等级
团队或组织使用持续的组织变革管理技术以优化自身的运营效率，以强调缺陷预防比缺陷诊治更重要，以持续发现技术开发机会。当然，这种技术也可以应用到整个公司。
按照Prosper教授的阐述，这五种等级依次递增，对于我们实有借鉴参考价值。我们可以利用这种模型为自己的团队定位，因此，可以用来指导采取一些具体的团队建设的措施。这些具体措施，笔者认为有以下几点：
一、项目团队经验互补
团队不仅在技术上是统一的、互补的整合体，同样在经验上也要是互补的。正像Prosper教授说的那样，“即使在成功率很高的组织中，即使在任何情况下，团队成功的关键因素就是项目团队成员的大量经验。”
比如回答这样的问题：项目团队是否有商界专家？如果没有，是否能指任的一个或几个成员站在客户的角度有效沟通和讨论商业需求的问题？团队中是否有人能真正理解“商务活动是个巨大的信心构建者”这种观念？只有当团队回答这些问题是肯定的时候，才能使团队中的分析者和设计者向除顾客之外的其他人询问需要问的问题，而不是仅仅关注顾客。从而，团队可以切实的有效利用每个人的时间，并增强了后续软件工作的安全性。另外，这样也可以保证团队的“创造性思维”在合理的边界内。
说到这里我们很容易想到技术专家。技术专家作为技术上的权威，熟悉在既定技术环境中的专业技术以提高团队信心。一位技术专家可以援助其他人，提供建议，开发项目标准，还可以防止开发错误的时间浪费。他们会在关键的时候觉察出项目是不是进入了茫然区，就像是在海上没有航标一样？
另外，专家也是树立团队领导楷模的关键。通过为其他人树立工作和经验的先锋楷模，技术专家可以在很短的时间内有效的转移技术知识和经验。同时技术专业也是团队避免再上马新技术时，无视标准的情况下，“按照自己的开发方式”进行工作。
二、项目控制和协调
Prosper 教授认为，“对于在整个开发过程中，需要许多人员参与的巨大且复杂的项目来说，需要制定并使用高水平且详尽的说明，以在个人成果整合成最终产品的时候，提供指导性的帮助。项目成果的分解，必然会使项目中的个人关注于自己那部分的工作。这时项目团队需要清晰界定的标准和规格说明，以保证预期最终结果与实际各部分整合后的结果相吻合。”
确实，在许多时候，系统设计可以被认为是一系列规格，且各分任务的各项成果以螺旋的方式交替上升并形成更详尽说明的阶段性成果。在此过程中，能否将所有人的努力统一聚集到一起是整个团队所面对的最终挑战。
那么哪些因素影响着这种统一聚集的程度呢？
笔者从根本上讲，三种比较大的因素需要在产品整合是值得注意。一是开发出合适的标准。这种标准具有一致性和连贯性。在每个项目阶段，应该开发指导方针已指导项目内容以及阶段成果的形势。二是团队的交叉沟通。一般需求，相似论题，共享数据，以及功能性再利用都应该以开放的形势进行讨论和协调。团队成员应该参加所有较高共享目标的开发，鼓励团队成员间的交互作用，增强团队内部的交叉沟通和决策制定。三是上级团队领导将团队个人融为一体，即采用一致的交付成果，质量保证，方法和审查标准。这些方面是必须要在团队中采用的，以保证团队成员的平等。
三、团队目标和个体目标
随着时间的推移，项目团队会呈现出自身独特的“个性”。这种个性表现为与团队有关每个人的反映，比如当团队热情高涨时，自信和确定性也会广泛传播，当团队失去方向时，团队会用怀疑和混淆的眼光看待周围事物。这样的想象常常在我们的IT项目团队中出现。那么，为什么常常出现同一个项目会在不同的团队执行中有如此大的差异？“领导力毫无疑问的起着重要性的作用，但是团队成员的个人态度是产生差异的根本原因。”
Prosper教授提出了两种基本的问题解释了团队努力的热情。
第一个问题：是否团队中的每个人都在努力朝向统一的，清晰的目标前进？第二个问题：目标是谁的？
正如IT经理所看到的，在软件开发项目中会有一些让人意想不到的事情发生：所有人都在忙着工作，忙着做自己认为重要的工作。我们必须承认，这是人类自然的本性行为，也是人类兴趣爱好发展的必要步骤。而我们希望的是每个人的工作应该与其他的团队成果相吻合，否则，个人成果与兴趣永远不能整合到团队层面上。然而，如果团队中的所有人清晰的、正确的明白最终目标，那么我们所希望的状态就会实现。
有必须要指出的是，就笔者多年经验来看，尽管团队成员确实被团队目标所驱动，而团队的领导却对实际的目标很模糊，就会发生个人目标和一些突发性目标占据主要地位的情况，接着就会慢慢形成或者触发那些潜在的冲突。在项目经理认识到冲突之前，表面上每个人都在忙于工作，工作的氛围也看似有效率，但是，不久以后就不得不做一次重大的内部协调工作。这势必会是项目经理陷入被动的状态，这是任何项目经理所不希望的。
对上面提到的问题，解决的方法就是确保整体目标和个人目标能被清晰的说明和定义，以及每个人对各项工作活动和任务的分配与执行有统一的理解，这将会使团队有目标共享的意愿，而且团队中的每个人都要对各阶段的输出成果负责。当各成员清楚的认识到各项工作的相关性和每项工作对最终结果贡献的重要性，当他们的个人目标体现在团队目标中时，这些措施会对成员态度产生巨大的激励效果，比如增强个人的自我激励强度，创造了开放式沟通环境等。
“更让我们欣慰的是，这些激励的效果最终会体现在产品的质量和工作效率上。”
四、系统设计的全新视角
全新的视角很重要，但是，如果这只是某一个人的想法，这种视角不会对任何的有作用。相反，只有当被团队所吸收和采纳，这种视角的优势才能显现出来。“在团队或组织中的‘幻想家’扮演着重要但常被忽视的角色，而正是他们的想法和意愿塑造了独特视角的优越性。他们往往愿意分享自己的观点和想象以及分享自己对现状的理解，而这些正团队实现预期的必要条件”Prosper教授用“幻想家”这个词语代替那些有独特全新视角的成员。
“同时，这取决于两种因素：‘幻想家’对自己的观点的信心以及他对审查和批评的包容。因为随着项目的每个阶段的结束，‘幻想家’必须要持续的发展并和团队沟通他对系统功能和项目实现路径的观点。”笔者认为撇开一些个人的因素，一个专业的系统正是孕育“幻想家”的系统。在这样的系统中，团队内需要推广全新视角，这会产生两种重要的结果：第一，为持续的讨论提供了条件。因为在许多的情况下，项目开始时的原有的观点思想就不会坚持很长时间，原因就是在项目进行中会产生好的思想并增加了讨论的次数和增强了讨论的效果。第二，鼓励批评和结构性的思考。新视角新想法的提出笔会引起一系列的思想撞击，势必会带来针对新视角的批评，但这并不是坏事。
“许多的项目领导倾向于提供一种需要更多输入的‘审查--提高’模型，而不是‘混乱--创造’模型。”在现代社会中，后者更适应时代的变化。另外，如果“幻想家”可以放弃原有观点，并鼓励和促进新观点成为团队所共有的资产，“混乱--创造”模型的有效性就是被体现出来。我们必须承认：项目经理是初始观点的缔造者，而团队成员和商务客户却是项目最终方向和共享观点发展的决定者。
处在这种等级的团队或组织倾向于采用一种混乱的、特别的、“按照自己的开发方式”的方法构建各种新的制度体系。团队的凝聚力较低，工作效率低。
重复型等级
团队或组织使用了计划技能，综合系统方式中的需求，利用软件质量确认技术，以及按照已经形成的路径图进行后续的努力。
定义型等级
团队和组织按照已经定义的方法步骤，使用过程提升技术以提高方法路径的有效性，引入规范的培训程序，以一种整合的观点看待整个系统开发过程，同时更多的使用正规信息工程和结构开发技术。
管理型等级
团队或组织切实的掌握并应用了软件开发标准，从而实现准确预计以及过程分析的目的。另外，一些全面质量管理（Total Quality Management, TQM）的观念也被应用于提高整体开发过程效率。
优化型等级
团队或组织使用持续的组织变革管理技术以优化自身的运营效率，以强调缺陷预防比缺陷诊治更重要，以持续发现技术开发机会。当然，这种技术也可以应用到整个公司。
按照Prosper教授的阐述，这五种等级依次递增，对于我们实有借鉴参考价值。我们可以利用这种模型为自己的团队定位，因此，可以用来指导采取一些具体的团队建设的措施。这些具体措施，笔者认为有以下几点：
一、项目团队经验互补
团队不仅在技术上是统一的、互补的整合体，同样在经验上也要是互补的。正像Prosper教授说的那样，“即使在成功率很高的组织中，即使在任何情况下，团队成功的关键因素就是项目团队成员的大量经验。”
比如回答这样的问题：项目团队是否有商界专家？如果没有，是否能指任的一个或几个成员站在客户的角度有效沟通和讨论商业需求的问题？团队中是否有人能真正理解“商务活动是个巨大的信心构建者”这种观念？只有当团队回答这些问题是肯定的时候，才能使团队中的分析者和设计者向除顾客之外的其他人询问需要问的问题，而不是仅仅关注顾客。从而，团队可以切实的有效利用每个人的时间，并增强了后续软件工作的安全性。另外，这样也可以保证团队的“创造性思维”在合理的边界内。
说到这里我们很容易想到技术专家。技术专家作为技术上的权威，熟悉在既定技术环境中的专业技术以提高团队信心。一位技术专家可以援助其他人，提供建议，开发项目标准，还可以防止开发错误的时间浪费。他们会在关键的时候觉察出项目是不是进入了茫然区，就像是在海上没有航标一样？
另外，专家也是树立团队领导楷模的关键。通过为其他人树立工作和经验的先锋楷模，技术专家可以在很短的时间内有效的转移技术知识和经验。同时技术专业也是团队避免再上马新技术时，无视标准的情况下，“按照自己的开发方式”进行工作。
二、项目控制和协调
Prosper 教授认为，“对于在整个开发过程中，需要许多人员参与的巨大且复杂的项目来说，需要制定并使用高水平且详尽的说明，以在个人成果整合成最终产品的时候，提供指导性的帮助。项目成果的分解，必然会使项目中的个人关注于自己那部分的工作。这时项目团队需要清晰界定的标准和规格说明，以保证预期最终结果与实际各部分整合后的结果相吻合。”
确实，在许多时候，系统设计可以被认为是一系列规格，且各分任务的各项成果以螺旋的方式交替上升并形成更详尽说明的阶段性成果。在此过程中，能否将所有人的努力统一聚集到一起是整个团队所面对的最终挑战。
那么哪些因素影响着这种统一聚集的程度呢？
笔者从根本上讲，三种比较大的因素需要在产品整合是值得注意。一是开发出合适的标准。这种标准具有一致性和连贯性。在每个项目阶段，应该开发指导方针已指导项目内容以及阶段成果的形势。二是团队的交叉沟通。一般需求，相似论题，共享数据，以及功能性再利用都应该以开放的形势进行讨论和协调。团队成员应该参加所有较高共享目标的开发，鼓励团队成员间的交互作用，增强团队内部的交叉沟通和决策制定。三是上级团队领导将团队个人融为一体，即采用一致的交付成果，质量保证，方法和审查标准。这些方面是必须要在团队中采用的，以保证团队成员的平等。
三、团队目标和个体目标
随着时间的推移，项目团队会呈现出自身独特的“个性”。这种个性表现为与团队有关每个人的反映，比如当团队热情高涨时，自信和确定性也会广泛传播，当团队失去方向时，团队会用怀疑和混淆的眼光看待周围事物。这样的想象常常在我们的IT项目团队中出现。那么，为什么常常出现同一个项目会在不同的团队执行中有如此大的差异？“领导力毫无疑问的起着重要性的作用，但是团队成员的个人态度是产生差异的根本原因。”
Prosper教授提出了两种基本的问题解释了团队努力的热情。
第一个问题：是否团队中的每个人都在努力朝向统一的，清晰的目标前进？第二个问题：目标是谁的？
正如IT经理所看到的，在软件开发项目中会有一些让人意想不到的事情发生：所有人都在忙着工作，忙着做自己认为重要的工作。我们必须承认，这是人类自然的本性行为，也是人类兴趣爱好发展的必要步骤。而我们希望的是每个人的工作应该与其他的团队成果相吻合，否则，个人成果与兴趣永远不能整合到团队层面上。然而，如果团队中的所有人清晰的、正确的明白最终目标，那么我们所希望的状态就会实现。
有必须要指出的是，就笔者多年经验来看，尽管团队成员确实被团队目标所驱动，而团队的领导却对实际的目标很模糊，就会发生个人目标和一些突发性目标占据主要地位的情况，接着就会慢慢形成或者触发那些潜在的冲突。在项目经理认识到冲突之前，表面上每个人都在忙于工作，工作的氛围也看似有效率，但是，不久以后就不得不做一次重大的内部协调工作。这势必会是项目经理陷入被动的状态，这是任何项目经理所不希望的。
对上面提到的问题，解决的方法就是确保整体目标和个人目标能被清晰的说明和定义，以及每个人对各项工作活动和任务的分配与执行有统一的理解，这将会使团队有目标共享的意愿，而且团队中的每个人都要对各阶段的输出成果负责。当各成员清楚的认识到各项工作的相关性和每项工作对最终结果贡献的重要性，当他们的个人目标体现在团队目标中时，这些措施会对成员态度产生巨大的激励效果，比如增强个人的自我激励强度，创造了开放式沟通环境等。
“更让我们欣慰的是，这些激励的效果最终会体现在产品的质量和工作效率上。”
四、系统设计的全新视角
全新的视角很重要，但是，如果这只是某一个人的想法，这种视角不会对任何的有作用。相反，只有当被团队所吸收和采纳，这种视角的优势才能显现出来。“在团队或组织中的‘幻想家’扮演着重要但常被忽视的角色，而正是他们的想法和意愿塑造了独特视角的优越性。他们往往愿意分享自己的观点和想象以及分享自己对现状的理解，而这些正团队实现预期的必要条件”Prosper教授用“幻想家”这个词语代替那些有独特全新视角的成员。
“同时，这取决于两种因素：‘幻想家’对自己的观点的信心以及他对审查和批评的包容。因为随着项目的每个阶段的结束，‘幻想家’必须要持续的发展并和团队沟通他对系统功能和项目实现路径的观点。”笔者认为撇开一些个人的因素，一个专业的系统正是孕育“幻想家”的系统。在这样的系统中，团队内需要推广全新视角，这会产生两种重要的结果：第一，为持续的讨论提供了条件。因为在许多的情况下，项目开始时的原有的观点思想就不会坚持很长时间，原因就是在项目进行中会产生好的思想并增加了讨论的次数和增强了讨论的效果。第二，鼓励批评和结构性的思考。新视角新想法的提出笔会引起一系列的思想撞击，势必会带来针对新视角的批评，但这并不是坏事。
“许多的项目领导倾向于提供一种需要更多输入的‘审查--提高’模型，而不是‘混乱--创造’模型。”在现代社会中，后者更适应时代的变化。另外，如果“幻想家”可以放弃原有观点，并鼓励和促进新观点成为团队所共有的资产，“混乱--创造”模型的有效性就是被体现出来。我们必须承认：项目经理是初始观点的缔造者，而团队成员和商务客户却是项目最终方向和共享观点发展的决定者。
五、项目团队的信心
另一个重要的团队态度是项目团队的信心。Prosper教授认为“复杂系统的开发为项目团队带来了巨大的挑战。有时，面对这种挑战，团队的工作更像是为了信仰而工作。”
项目经理都很了解在整个系统中，大量的细节需要收集、分析、组织以及消化吸收。在许多情形下，团队中只有少数成员可以持有全局的观点，并且这种观点也可能会不同程度的发生一些变化。最常见的变化是随着时间的推移，这种观点会变得很模糊，而正是这种模糊性测试了团队的信心强度，比如在不确定的情况下，团队对整个项目成功的确定和信心如何？这会不会影响到团队个人的态度？确定诸如这样地问题，我们可以看出一个团队是不是对未来拥有信心。
“我们可以通过逐渐引入解决方案的方式进行系统设计，反复进行的过程中，实现增强团队的信心，使每个团队成员能耐心的面对缓慢变化的模糊性。团队中曾参与过系统设计整个生命周期的人员越多，则越有可能使整个团队意识到所有的工作将在每个重大里程碑时间点上聚集。”这正是为缺乏经验的项目团队成员建立信心的关键。同样，团队如果有越高程度的地信心，那么客户也会对项目的成功有信心，团队也更能正视自己的成功，尽管会面临不确定的环境。
另一个重要的团队态度是项目团队的信心。Prosper教授认为“复杂系统的开发为项目团队带来了巨大的挑战。有时，面对这种挑战，团队的工作更像是为了信仰而工作。”
项目经理都很了解在整个系统中，大量的细节需要收集、分析、组织以及消化吸收。在许多情形下，团队中只有少数成员可以持有全局的观点，并且这种观点也可能会不同程度的发生一些变化。最常见的变化是随着时间的推移，这种观点会变得很模糊，而正是这种模糊性测试了团队的信心强度，比如在不确定的情况下，团队对整个项目成功的确定和信心如何？这会不会影响到团队个人的态度？确定诸如这样地问题，我们可以看出一个团队是不是对未来拥有信心。
“我们可以通过逐渐引入解决方案的方式进行系统设计，反复进行的过程中，实现增强团队的信心，使每个团队成员能耐心的面对缓慢变化的模糊性。团队中曾参与过系统设计整个生命周期的人员越多，则越有可能使整个团队意识到所有的工作将在每个重大里程碑时间点上聚集。”这正是为缺乏经验的项目团队成员建立信心的关键。同样，团队如果有越高程度的地信心，那么客户也会对项目的成功有信心，团队也更能正视自己的成功，尽管会面临不确定的环境。