明确角色是项目管理的关键

作为一名IT经理，我曾经经历过一段现在想来确实是十分难得的舒服日子。那个时候，需要管理的差不多只是一种类型的员工，因此只要在工作中有足够的投入，几乎所有的问题都可以得到解决。但是，当我手下的项目小组的数量不断扩大，员工类型不断增加――既包括程序设计人员、又包括质量****、安全小组、基础设施工程师、人力资源**和临时的看门人的时候，我开始逐渐的意识到：要完成工作任务，仅仅靠努力工作――哪怕是**性的工作――已经远远不够了。实际上，现在对员工进行管理的方式同以往相比已经是截然不同了，需要管理者应用**的组织和管理方法。

作为一名IT经理，我曾经经历过一段现在想来确实是十分难得的舒服日子。那个时候，需要管理的差不多只是一种类型的员工，因此只要在工作中有足够的投入，几乎所有的问题都可以得到解决。但是，当我手下的项目小组的数量不断扩大，员工类型不断增加――既包括程序设计人员、又包括质量****、安全小组、基础设施工程师、人力资源**和临时的看门人的时候，我开始逐渐的意识到：要完成工作任务，仅仅靠努力工作――哪怕是**性的工作――已经远远不够了。实际上，现在对员工进行管理的方式同以往相比已经是截然不同了，需要管理者应用**的组织和管理方法。

项目**失败我意识到这一点是在一个失败的项目的进行过程当中，后来这个项目被我形容成了**失败的项目。我的项目小组又包含了五个分组，每个分组都有自己不同的职能和职责。其中有三个分组“工作”非常勤奋，以创建客户环境。另外两个分组负责向这三个小组提供管理和质量支持。我同项目小组的其他负责人一起努力工作，并且同其他的小组成员保持着联系和沟通。

在一个规模比较大的系统升级进行了六个月之后，整个项目小组的工作都停了下来。我们没能按时完成一个新的ERM软件的配置。当我问及能够完成任务的时间时，开发主管告诉我说：“永远也完成不了。负责质量**工作的那些该死的**永远也完不成他们的工作”。

听他这么一说，我立即就给质量**小组的负责人打了电话。他给我的回答竟然与开发主管的回答基本相同：“只有在有了成品之后我们才能够进行质量验证，可是开发小组根本拿不出任何可以让我们验证的东西来”。在他看来，更为糟糕的是，在配置小组和业务小组的帮助下，开发小组总是把在客户环境中配置新软件的责任推到质量**小组的头上。

在同这些负责人的交谈中，我受到了某种触动。这些工作小组在谈论的似乎是**不同的工作。根据我当时的理解和判断，一定有什么地方出了问题，我在自己的头脑中敲响了警钟。

在经过了反复的考虑之后，我召集了一个小组负责人会议。在会议召开之前的一个星期，我单*把每个小组的负责人都叫到了会议室面谈。在交谈的过程当中，我们一起分析各个小组的工作情况，明确各个小组的职能和职责。当一个小组的工作同其他的小组密切相关时，我们也会从**者的角度对相应小组的角色进行分析。

事实突现在会议召开的前一天，我把自己手头的工作交给了自己在公司里的朋友，让他们在未来几天的时间里代我履行基本的工作职责。然后，我就静下心来，把会议室的门一关，同各个小组的负责人一起分析整个项目小组的工作情况。

从某种角度来说，我还是感到非常高兴的。因为大家至少都在表面上在项目涉及的一些基础问题上达成了共识。在其他小组的职责问题上，各个小组的负责人之间存在很多重大的分歧，但是在任何项目的进行当中，出现这些分歧都是正常的，所以我们都不会感到奇怪。

但是，从另外一种角度来说，我的心又不禁感到一沉。造成冲突的原因，同时也是造成工作无法按期完成的不可避免的原因，是那么清楚的展现在我们的面前。

生产小组对其他小组的外部依赖程度要相对小一些。它们的职责和职能决定了他们的工作表现直接取决于工作投入。如果这两个分组的某个成员在某项任务上投入了九个小时的时间，那么他能够得到的回报就是这九个小时的工作产出。

资源小组如果没有其他小组的帮助，可谓是寸步难行。这两个分组的工作同其他小组的工作之间存在着错综复杂的相互依赖关系。如果没有配置小组的帮助，质量**小组就不能更改测试数据库中的数据。如果没有其他小组的授权，资源小组也无法召集会议。换句话来说，这两个小组的工作极大的取决于其他小组的工作。真正起作用的并不是他们在工作当中的投入有多少，因为他们对其他小组的依赖性实在是太强了。

业务/支持小组的情况兼具上述两种特征。他们的某些工作同工作投入直接相关，而另外一些工作则要极大的依赖其他的小组。

事实表明，根据各自不同的状况，各个工作小组要想完成自己的工作任务需要采取不同的方式。一方面，有的小组的工作表现是由他们的工作投入决定的。另一方面，还有的工作小组的工作表现是由他们处理同其他小组的依赖关系的能力所决定的。

视角一：依赖性与工作投入之间的冲突这不禁让我想到了另外一个问题：通过投入或是对其他小组的依赖完成工作，这两种不同的完成工作的方式总是会引起各个不同角色小组之间的冲突。

根据实际的工作经验，那些对其他小组的依赖性相对较小的小组相信只要有足够的时间投入，任何工作任务都可以完成。他们的想法是正确的。他们可以把各项工作分成几个小块同时进行，这样就可以同时完成多项工作任务。

而那些极大的依赖于其他小组的小组则认为，与其他小组的支持和各个小组之间的相互交流相比，在工作任务的完成上，工作投入所发挥的作用是非常有限的。他们的想法同样也是正确的。实际的工作经验表明，如果他们不能从其他的小组那里得到很好的合作，他们就没有办法工作。更为糟糕的是，他们心里也很清楚，如果任务完不成，他们肯定难辞其咎，即使他们已经在自己的能力范围内作出了最大限度的努力。

上述区别不可避免的会引发冲突，而这种冲突又是我们可以预见的。而只要是我们能够预见到的问题，我们就可以对其进行控制，并将冲突的烈度降到最低。

视角二：角色组织存在区别依靠投入来完成工作任务的小组同依赖其他小组来完成工作任务的小组之间的角色区别同样也决定了他们各自不同的组织方式。

一般来说，我们对靠投入来完成工作的小组的组织是通过合理的工作分配来完成的。我们试图将权力集中，明确有哪个人具体负责哪项工作任务。

而在对其他小组依赖较大的小组进行组织时，我们就必须考虑到各个小组之间的相互依赖和制约。为了让这样的小组能够尽快完成工作，我们就必须要减轻各个小组之间的相互依赖。如果一名员工在开始自己的工作之前必须要等其他的三名员工先完成工作，那么他毫无疑问要等很长的时间。而如果我们能让他只要在另外一名员工完成工作后就可以开始自己的工作，他等待的时间就要短得多了。

联系实际在考虑过了上述问题之后，我把注意力放到了自己所**的项目小组现在正遇到的问题上。在为期整整一天的会议上，我让各个分组的负责人都向我介绍了他们的工作任务以及他们同其他小组之间的互动方式。我们具体分析了各个小组所存在的问题，分析了小组间互动的成败。

最后，我们达成了一致，从根本上对资源小组和质量**小组的职责进行重新的界定。质量**小组又重新做起了自己的老本行，对硬件和数据库进行测试。这让他们又重新找回了几年以前的位置和状态。要知道，开发和配置小组之所以会对质量**小组不满，就是因为他们曾经迷失了自己的位置。资源小组也拥有了更大的权力，可以对各个小组的资源购买做出决定，并且可以在不经其他小组负责人授权的情况下同公司其他部门保持交流和沟通。

整个重组过程又花费了我们两个星期的时间，但是这种时间上的付出是值得的。大家对自己的职责都有了新的明确的定位，我们也学会了在冲突爆发之前即时发现问题。我们再也不会重蹈失败的覆辙了。