【解答】睿泰咨询一部经理 @睿泰杨俊

    缺乏对项目目标与约束的共识

    研发团队缺乏协作的首要问题是无法就项目的目标与约束达成一致，这意味着研发团队之间根本性的缺乏共识。许多人，尤其是许多管理者认为绝大多数的IT项目很难就目标达成共识；另一些人则认同项目目标的重要性，但不知道该从何下手；甚至有为数不少的管理者和专业人士认为，因为IT项目的目标是模糊不清和难以界定的，所以根本就不该去制定什么目标，转而采取随机应变的方法与态度。

    但是明确IT项目的目标与约束如果不是项目管理唯一重要的事情，也是头等大事。如果置身于50年前计划经济时代的工厂流水线上，我们会发现自己只需对每天所需生产的额度进行负责就行。至于做什么、做到什么以及为什么做，那是坐在车间办公室的头头们应该去思考的问题。在体力工作为主的组织里，高级管理者天然垄断了生产中所有的决策工作。

    但是在IT行业中，除了最极端的Coding外包（即贴代码）以外，绝大多数的工作都不是纯粹的体力工作，知识工作的特点就是众多的决策性事务必须交由专业人士自己做出，包括做什么、做到什么、为什么做以及怎么做。

    互不理解

    一旦谈到研发团队，人们天然的就想到了项目经理、需求工程师、测试工程师和程序员等角色。这些角色之间的互不理解对研发工作造成了极大的困难，但是比之更严重的是另一些更为重要的团队成员（虽然许多人都没有意识到他们也是团队的一员），他们是市场人员、实施人员、客户（代表）以及企业高层（在诸如新产品研发等对企业密切关系的项目中，真正的期望者就是他们）。

    如果之前的技术团队至少还用同一种语言进行着交流，那么后面的角色几乎都是用各自不同的语言在进行交流，市场人员是横亘在服务团队与客户之间的翻译官；而项目经理多半是横亘在客户、市场、企业高层与技术团队之间的翻译官。如果各角色之间无法互相沟通，那么除非有一个强有力的翻译官，否则项目就不可能成功，至少不可能在规定的约束内顺利完成，难怪乎实际上在工作中被误解最多，工作最为困难的就是项目经理与市场人员了，这些翻译官在遇到委屈时多半只能把牙齿打碎往肚里咽。

    但另一方面，做得有效的翻译官又屈指可数，对他们太难了，因为要同时维护的利益关系甚多，并且层次不同。但是如前一个问题所述，他们又必须将这些团队成员维护在同一个目标体系下，否则项目团队多半自说自话，各行其是。

    组织结构、职责与绩效制度

    导致沟通不畅的第三个原因是，团队的组织结构已经无法适应合作的需要，在目前典型的IT企业的组织结构中，技术团队的成员在某个项目中主要是一个临时性的角色，这就是从GE公司延续下来的矩阵式管理模式，一名成员在瞬时中同时属于两个不同的组织。

    这在一些小型项目中是没有问题，但是在一些规模较大或十分困难的项目中就会出现许多问题，因为此类项目所需要的时间更多，所付出的努力也更大，但是行政主管，也就是可以决定其绩效的人却并不是这个项目的经理人，而项目经理也没有直接的考核权利。同时，另一些特殊角色，如客户（代表）、市场人员与企业高层又如何被融入到这个组织中？

    另一方面，绝大多数的IT企业实际上沿用了工业企业所采用的职责划分方法，工业企业采取的职责划分方法适用于体力工作者，其核心是“操作”。但是在IT的所有工作中，操作所占的比重十分的低（估计只占工作的20%以下），IT工作绝大多数都属于知识型工作，对知识工作的职责划分应该依据其产出，而非操作。

最典型的工种就是测试工程师，测试人员们普遍觉得企业管理者是虚伪的，一面强调质量而另一面却忽视自己。但是管理者也是有理由的，因为他们发现引入更多的测试人员也无法帮助组织提升产品或服务的质量。人们把此归咎为个人能力太差，但这实际上是职责界定的错误，测试工程师并不认为自己是对产品质量负责的人，所有人尤其是程序员们觉得测试人员就是一群找茬的人，他们只是在测试（一种操作行为），其产出只是缺陷的报告。测试人员们从来不在乎程序员们有没有精力修改完成，也不会提出合适的修改建议，更谈不上帮助他们提前预防错误了。这样的误解只是项目团队所有误解的一个缩影。

    最后，绩效制度也起到了负作用，生产性工作所采用的职能制绩效方法天然的将各种职能拆分开来单独考核，但没有一个总体考核指标代表团队的工作效率。而IT研发团队类似于一个足球团队，无论前锋的表现多么出色，只要团队输球，整支球队就只能接受失败。所以IT研发团队首先需要的是团队绩效指标，而不是个体绩效指标，指标体系必须首先建立在团队的整体表现之上。

    解决问题的思路

    文字无法解决问题，但至少可以表达思路，对于这个问题我们还没有太好的解决方案，但是其改进的方向却是明确的。

    首先，我们必须保证能够制定出合理的项目目标，但这确实非常困难。企业的所有管理者都必须首先就企业当前的业务状况进行深入分析，确保团队的每个管理成员（尤其包括项目经理们）深刻理解业务现状，然后就企业典型的项目关键特征达成共识。

    有一家专门做大型政府项目的IT企业请所有的经理人坐下共同讨论企业项目的关键特征，结果人们发现原先所谓的质量要求并不是自己项目的关键特征。政府类型的项目在许多情况下要求对国家政策进行预演，结果实际上企业的大多数项目都属于这种预演型项目，这些项目本身是不是赚钱并不重要，重要的是一旦他们抢占先机就可以为未来的全国推广做好充分准备。但是此类项目实际上没有现成的客户，做成什么样完全是摸索，对其的质量要求根本就是其次的问题，首要的关键要素是“速度”，其次是“包装”，此类项目占公司资源甚多，值得企业大力改善工作效果与效率。结果一旦这种类型的项目被接下，再也没有人对质量提出太多的要求，每一个项目经理都知道首先要确定这个项目的时间约束，并且作为基本约束规划整个工作进度，同时将功能按优先级列为4档，尤其是第四档的功能基本不做，诸如性能等非功能指标也不在项目的优先考虑范围之内，但是企业尤其强调“易用性”与“功能贴合政策的创新程度”。

    什么是我们项目的60分？也就是不完成就根本不能交付；什么是80分？也就是更好?回答这些问题对于IT项目来说十分困难，但必须做得到。

    其次，企业应该仔细思考整个团队的组成，哪些人对项目的成败至关重要？这些人就应该是团队成员，每一种人有不同的期望和语言，但是作为一家知识型企业，专业工作者必须能够深刻理解业务知识，无论是系统工程师还是测试工程师对业务知识的理解程度直接决定了其工作的有效性，企业必须加大力度培养与培训。如果一个已经在企业待上两年的工程师无法回答“客户是谁？谁决定采购？客户到底采购了什么产品或服务？这些产品或服务到底为客户带来了什么价值？”等一系列问题，那么我们可以断言，想要互相沟通是几乎不可能的。

    另一方面，包括企业的高层与市场人员也要尝试了解企业的关键技术领域的知识，当然要了解到什么程度始终带有争议，但是我们至少可以说一个市场人员或企业高层对于技术知识的了解要足够到超越其客户对其的所知，甚至最好能够适度提出建议或见解，否则在专业服务市场，客户不会愿意花多少时间接待一个在解决方案的领域知识上甚至不如自己的人，他根本就不会信任这样的供应商。

    在维护共同的语言方面的最后一个建议是 —— 教育客户，客户是完全捉摸不定的，也是无法去控制的，但现在我们知道至少我们可以去影响他们，尤其是当一个客户成为我们的长期客户时。在专业服务市场，客户通常因缺乏专业知识而表现的没有安全感，他们如果偶尔表现出对专业知识的自信，那也是因为他们不希望被愚弄而故意表现出来的。只有真正能够引导客户需求的专业服务供应商，才能最终征服客户。

    接着，只要企业渡过了生存期，并且研发团队的规模已扩大到原有规模的3倍以上，IT企业就应该尝试改变自己对项目的组织形式，尤其是需要尝试改变专业人员的职责界定。这通常是最难的，企业高层担心专业雇员的能力尚不足以承担起这样的职责，而专业雇员则已经十分习惯原先的工作方式与职能定位（即使人们对原有的方式表现的极不满意，一旦要求改变其抵触情绪会更大于对原有方式的不满），但要么继续痛苦下去，要么就只能想办法改变。

    最立竿见影的方法与步骤是调整绩效制度，使得其代表显示的利益能够显示整个团队的绩效，这样即使没有外部压力，团队也会存在改变沟通的动力。绩效体系，作为一种手段，必须保证其适应企业当前的环境，并保证其不会破坏团队产出的成果，否则还不如不要。

    以上只是浮光掠影的浅谈了研发团队缺乏沟通与协作的原因及改进方向，企图在千百个字里就浮现出方法与操作显然是不可能的，但是至少我们知道了原因及方向后才有可能做出行动。