团建游戏暴露的项目管理问题

上周六公司团建,不出主持人所料,游戏最终全体失败,从中暴露出了很多问题,为了将事情说清楚,有必要先介绍游戏规则。

游戏名称:捕鱼达人

规则:

共分11个队伍,捕鱼周期为10周,鱼初始100条,每周每队私下提交自己的捕鱼条数,抽签决定捕鱼各队顺序,每周结束时,主持人会宣传各队伍是否捕到鱼。

是否捕到鱼的判定条件:
当欲捕鱼条数小于等于湖中所剩数目时为捕到,否则判定为未捕到,注意,如果欲捕条数为0,则一定会被判定为捕到。

繁殖条件:

当湖中剩余量大于等于50条时,下一周变成100条。

当湖中剩余量小于50条,大于等于20条时,下一周翻倍。

当湖中剩余量小于20条,下一周维持在20条。

获胜条件:

  1. 每个队伍至少32条,否则判定所有队伍失败。
  2. 满足条件1,捕鱼条数最多的为冠军
  3. 满足条件1,捕鱼条数最少的为失败。

稳赢且结果最大化的方式是每周每个队伍只捕4条(可以有队伍多捕,但是要保证剩余条数不低于50),这样,第8周结束后每个队伍都已达到32条,剩余2周拼胜负。

然而实际情况是,在第一周剩余条数就已经在20条以下,且即使所有人都知道在此时需要两个休渔期让鱼恢复至80条时,此后9周剩余条数始终为20条以下甚至为0,最终大部分队伍都没有捕到32条,甚至是个位数。

在结束后的分享过程中,很多人提到了人性的贪婪以及囚徒困境,但是我想以项目管理的角度来分析一下游戏中所出现的问题。

分析过程中忽略游戏性,大多时候将这个游戏作为一个项目来看,11个团队为11个项目成员,有时也需要将11个团队整体视为项目集,而每个队伍为项目集中的项目。


团建游戏暴露的项目管理问题_第1张图片
项目管理

WBS

WBS是为实现项目目标、获得可交付成果而对项目团队所需要实施的全部工作范围的层级分解,创建WBS过程中会将可交付成果和工作分解成较小、更易于管理的组件。

因此,WBS不仅定义了项目的总范围,代表着经批准的当前项目范围说明书中所规定的工作,同时其最低层包含着重多工作包,以便于对工作安排进度、估算、开展监督和控制。

在这个游戏中我们可以简单的理解为,为了达到最终目标,WBS规划了每一周每一个团队应该捕鱼的数量,规划过程中每周的繁殖最大化是重要准则。

然而游戏过程中并没有WBS,也就是说各个队伍的每周捕鱼量没有整体规划,由于过量捕杀且无休渔期,导致鱼的繁殖始终很低,最终导致捕获量过低,全员失败。

沟通

游戏规定允许团队内部讨论,但是不允许团队之间讨论,如果各团队为项目组的成员,则意味着团队内的成员没有沟通,缺少沟通的项目组最终失败也是必然。

比如团队内的软件工程师和硬件工程师,软件需要硬件的电路板来调试程序,软件工程师不主动索要电路板,也不问硬件电路板的进度,他认为硬件工程师会把电路板准备好并交给他。而硬件工程师同样也不主动沟通,不将已做好的电路板交给软件工程师,他认为软件工程师如果需要会自己来拿,结果当然是项目无法如期交付。

无效的沟通,体现在各队大副组织在一起开会讨论结论为需要两周的休渔期,所有队伍在这两周不捕鱼,各大副回到各自队伍传达此解决方案时总是有几支队伍未按此执行,可以理解为大副与其队员的沟通无效。

现实工作中导致沟通无效的原因可能是沟通方式问题,如采用了推式沟通而未进行交互式沟通,同时也可能是相关方原因导致的。

相关方

游戏时如果留心能够发现,每个队伍在讨论下周捕鱼数这一事件时,具有说服力并最终影响到决定的往往是固定的几人,他们在整个讨论过程中有较高的参与度和影响力,往往决定了捕鱼数,也就是对项目成功具有潜在影响,而另外一些人可能看看手机、发发呆、单纯地听听或者只是私下与身边人小声发表一下自己的看法,他们并未影响到决定。

在抽集各队伍大副开会讨论方案时,这些具有影响力的相关方未被邀请参与其中,在方案执行过程中这些相关方不认可此决定而拒绝执行。

在实际工作中导致此种情况可能是识别相关方、规划相关方参与、管理相关方参与、监督相关方参与几个环节中的任何一个。

比如在未邀请生产和采购部门代表参与的会议中决定由生产下个月提供10台仪器,当采购和生产部门收到此通知后,根据组件交期判断根本不可能完成,从而拒绝接受任务。

风险管理

风险管理的步骤为识别风险,分析风险,规划风险应对,实施风险应对,监控风险。

游戏进行中,所有人都意识到湖中剩余鱼量已经低于20条,如果持续繁殖量不足,则无法达到每个队伍32条的要求,这个过程中相当于项目组已经识别到风险,并对风险进行了分析。

接下来项目组规划风险应对,需要连续两周的休渔期,即所有队伍连续两周不捕鱼,让鱼恢复到80条。

然而在实施风险应对时出现了问题,总是有部分队伍没有按照规定的风险应对方式不捕鱼,导致未能得到足够繁殖。

在监督风险过程中发现风险已转为问题,导致全部失败的风险已经发生。

建设团队

研发总监提出游戏过程和结果不理想,主要是由于团队刚刚组建,相互之间不信任,如果团队已经合作很久,那么就会对彼此产生信任,最终很可能是一个好的结果。

这个观点正涉及了团队建设的几个阶段,我们把11个队伍看成是项目组中的成员,团队从形成阶段步入至震荡阶段,在震荡阶段团队成员不能用合作和开放的态度对待不同的观点和意见,成员之间彼此不信任,因此做出影响项目进度的行为,而通过有效的团队建设活动,团队逐渐步入规范阶段再到成熟阶段,在成熟阶段,成员之间可以相互依靠、平衡高效地解决问题。

如果是11位成员处于成熟阶段,那么很有可能他们会在前8周将各自捕鱼数达成,然后用最后两周采用玩味的运气方式角逐最终胜利者。

另外,激励也是建设团队的有效方法,如果执行过程中,对按照方案休渔和未进行休渔的队伍分别进行有效的奖励和惩罚,有助于促进健康和高效的团队建设,那么最终成功的可能性也会高很多。

反例是当原本遵守方案的队伍发现其它队伍一直不执行方案时,也在每周捕鱼数量上写下20,碰运气抽到第一个捕鱼顺序就捞一笔,也就是恶习会传染。

资源管理

游戏进行中,有两支队伍在确认达成全部32条时还过多的享用了资源,最终超过40条,对此其解释为:“在不能保证全部队伍完成任务的情况下,至少要保证我们的团队能获得更高的收益,商场正是这样,每个企业都是为自己争取利益最大化。”

对于这种说法我不能完全赞同,在商业竞争中,处于同一领域的各企业之间通常无共同的成功和失败准则,企业都会不断地追求利益最大化,哪怕某一企业已经拥有60%的市场份额,它仍然会继续抢夺其它99家企业的剩余40%份额,至于其它企业的生死与它无关,甚至往往竞争者死的越多,对自己越有利。

而这个游戏的其中一条规则就是如果有任何一个队伍无法实现32条的目标,那么所有队伍都失败,所以各个队伍更像是一个企业的多个项目,这11个项目组各自完成一个模块,把这11个模块组合起来才是一个完整的产品,只有整个产品都完成了,企业才能产生利润。

很好的例子是生产汽车,企业按照汽车的部件分成多个项目组,有负责生产发动机的,有负责生产变速器的,有生产悬架的,等等。当所有项目组都完成各自的任务,组装到一起才是一个完整的汽车。如果给发动机组分配了过多的工人、生产设备和资金等资源,而负责变速器的只分配了很少的资源,最终发动机组高标准完成任务,质量高、产出多,然而变速器却未能如期生产出来,显然,汽车无法销售,企业将无法盈利。

所以,需要通过项目组合管理来优化项目资源,可以采用自下而上和自上而上等方式合理评估资源并进行分配,在资源上保证目标的成功。

项目经理的职责

以上所有环节都需要以项目经理为主的相关方进行把控,因为项目经理是实现项目目标的核心责任人,负责项目启动、规划、执行、监控、收尾等所有过程组的管理。

作为管理者,项目经理的主要职责是整合和沟通,通过协调相关方利益,共同推进项目以获得项目成功,在执行整合时,项目经理承担双重角度:

  • 与项目发起人携手合作,既要了解战略目标并确保项目目标和成果与项目组合、项目集以及业务领域保持一致。
  • 在项目层面上,项目经理负责指导团队关注真正重要的事务并协同工作。为此,项目经理需要整合过程、知识、人员。

如果这个游戏有一个负责人(项目经理),对以上所有环节进行计划、实施、监督和控制,那么就可以保证全部队伍完成32条鱼的任务,并采取一定措施决出最终的胜负。

游戏中还有一条规则是所有队伍捕鱼数要超过350,如果每个队伍达到32条,则总数已经352,所以这条规则没什么意义或者是写错了。

实际上这个游戏斗智很难完成,不斗智就会变成最后两轮凭运气的无趣游戏,要想游戏容易达成又好玩,需要再增加许多的规则,所以游戏本身不是目的,让参与者在游戏的过程中体悟的一些什么才是最重要的。

你可能感兴趣的:(团建游戏暴露的项目管理问题)