我看游戏公司的“半矩阵”组织结构

在游戏公司观察将近5年,一些游戏公司规模扩大后从“项目制“改革到”矩阵“组织结构改进,有些公司并未完全改制成“矩阵”结构,而是改制了一半,项目组里保留了策划,把技术、美术等改成了公共支持部门。这就形成了“项目制“和”矩阵“并存,项目组成了需求方,技术、美术、测试、用户体验等这些支持部门成了“外包”。这种未彻底改革成扁平化矩阵式的组织结构形式,不妨暂时称之为”半矩阵“组织结构。

1、游戏公司为何要把组织结构从“项目制”改制成“矩阵式”?

项目制的特点
1)团队成员专有、成员稳定;
2)项目负责人在管理项目时有着绝对的权利,既在行政上有管理权,也在业务上有管理权。
3)相对于公司很独立,经常出现整个项目集体被挖走,或者整个项目如果对公司不满集体出走。

正是由于项目制的这些特点,产生一些问题
1)公司对项目组的控制性太小,对于公司来说太不安全,项目老大觉得不爽就跑了。
2)在项目研发的过程中,有些人力在不需要的时候就得闲着,得不到有效利用,势必造成人力的极大浪费(人力浪费实际上是项目研发成本的增加)。
3)不同项目组之间的专业人员很难横向交流,没法形成专方面的持续性发展。对于公司的专业人才持续性培养极为不利。

在项目多于3个时,无疑矩阵式管理结构可以解决项目制存在的诸多问题。在矩阵式管理结构中,每个专业人员都有两个身份:1)属于某个专业团队;2)同时也属于某个项目。这样矩阵式组织的优势就凸显出来了:
1)项目可以根据业务需要申请和释放人力资源;
2)项目管理者更专注于业务,更专注于把项目或产品做好 ,更专注于根据业务使用人力资源;
3)专业人员自然会形成横向的 专业沟通和竞争;同时有利于专业人员的培养,专业水平也具有了可持续性。
4)各专业人员都属于平级的各公共部门,合作上平等,利于各展其能。

基于矩阵式组织结构的各种好处,各大公司基本都采用矩阵式结构,以利于公司的长期发展和资源成本节约。游戏公司也有不少公司从项目制改革成矩阵式,也可能是项目制时项目老大(游戏公司中叫制作人)的权利太大,很难一下子直接改革成矩阵式,不少游戏公司形成了“半矩阵”式的组织形式。

2、“半矩阵”组织结构的问题

通过将近5年的体会和观察,这种未改革彻底的“半矩阵”所存在的问题如下:
1)支持部门的人没有了责任感。公共支持部门的美术、技术、测试、用户体验等人员,他们感觉自己和项目没关系,项目组的成败也和自己没关系;自己再努力,项目好了自己也看不到有啥好处,感觉好处都让项目组得了,没有了责任感。
2)支持部门的人有不平等感,难以发挥主观能动性。项目组内的策划们,他们觉得自己才是项目组的,你们都是XX部门的,都是为我服务的。这就在合作中,公共支持部门人员感觉自己低人一等,处处要看项目组那帮人的眼色;实际上公共支持部门也很难受到很好的认可,项目有问题大多数情况都会 把责任推卸给干活的人,而干活的人也正好是公共支持部门。这种情况下,公共支持部门很难发挥主观能动性。
3)由于项目组一方是需求方,必然造成了项目组人员的强势。所有支持部门干活的目的只有一个,让项目组满意,而不是为了做好产品;势必造成很多专业决策不能由更专业的人员决定,只能和项目组妥协意见。
4)策划水平难以持续性发展。属于项目组的策划,横向沟通少,很难形成专业性的 团队,也不存在专业方面的可持续性发展。

基于自己这些年对“半矩阵”组织结构的认识,强烈建议哪些还处于“半矩阵”的公司,把公司组织结构的改革再彻底一些吧,短暂的阵痛会带来更长久的发展。相信真正做产品的牛人,会更愿意把精力专注在产品上。

当然,矩阵化组织结构对公司的管理水平要求会更高,在改革组织结构的同时,公司管理水平也应能跟得上。

如何做好设计的沟通?

沟通是一门艺术,很多时候不只是简单的把问题说清楚,更多的时候我们要关心对方接受了多少?以什么样的口气沟通对方会接受更多一些,或者不至于因出言不逊伤害对方的自尊等等,相信大家心中都会积压一些沟通的情绪问题。下面是自己做好沟通的一些心得。

1.调整好你的情绪

人是复杂又敏感的,你去找一个人沟通,出现在他面前的那一刻,沟通就已经开始了,尽管你没开口说话,你所流露的情绪基本已经决定了结果,会直接影响对方是否愿意听你说下去。所以我们在去找人沟通的时候,一定要从内心保持友善和尊重,自然而然你就会流露出这样的情绪,同时这个情绪会通过你的气场或表情感染对方。

1)传递友善的情绪
有的朋友会说:“可是我很讨厌他!”,如果所有人都讨厌他,我想他该走人了,如果他必须存在,我想你要职业一点,哪怕没见到他之前你想掐死他,看到他那一刻起,你就要控制好自己,传递友善的情绪。

2)放平心态
不管你想不想承认,很多人在沟通的时候,容易依仗自己的优势,来特意表现自己,故意让周围的人感觉自己比对方强(大概是虚荣心吧)。以平等的心态来沟通,就必须避免炫耀自己,这个炫耀自己可能包括很多,比如:认为自己比别人强、认为自己是上级等等,但归根结底是自己的“优越感”,在沟通的时候会流露出炫耀的语气,以此给其他沟通者带来不快!并可能因此让其他沟通者从情绪上严重抵触。

3)学会尊重别人
尊重别人就是尊重自己,因为你这样对别人,别人也可能这样对你。不要试图侵犯别人的尊严或者隐私,不然别人一有机会就会报复你。别人同时包含尊重和相信对方的能力,这样才能建立认同感,进而从内心里相互尊重,同时可以激励对方主动发挥优势。

2.注意你的语气

1)不要用反问、否定等可以产生负面情绪的语气去沟通。
如果你读过卡耐基《人性的弱点》,你就会知道人都认为自己是对的,不要试图否定并说服对方,也不要去激怒对方,否则对方也会找机会同样对你,久之就会形成较为恶劣的关系。大家都知道在管理学所有的因素中,“关系”总是排在首位的,关系不同基本判定这条沟通的线路不通,甚至影响着这个工作流程走不通。

2)更忌讳使用不当语气做笼统的表述。
假如你是产品设计师、交互设计师或者一个管理者,你对着一张视觉设计的图开始“喷”了:“不大气”、“总体看起来很烂!”、“还差的很远!”。视觉设计师听到类似的话会怎么样?郁闷 !心里骂娘!不理你或者拒绝和你沟通……  或许你说的也都对,对方却没有理解你想要什么;或许他只是想拿出一个想法和你讨论一下,期望你给他点专业的意见。而现在,他觉得你那么可气,就算你说的有些是对的,可能仍然不愿意接受,因为这时候他很讨厌你。

3.学会倾听

沟通的问题是中心,沟通的人也被可以视作中心源, 所以我们要认真的倾听发起沟通者的描述,认真揣测发起沟通者想要达到什么意图,这样才能针对目的进行有效的沟通。试想,如果你不管找你沟通的人想要得到什么结果,就很自我的发表一通言论,沟通的结果是什么:搞笑?让对方觉得不快?炫耀了自己?根本谈不上有效沟通!对方的情绪只能是不满、不快或无奈。

小结:在开发团队中沟通基本上是人和人之间的事情,人都是有情绪的;我们在设计或开发中,多数是为了具体问题而沟通,而非为了情绪而沟通,但我们应首先处理好情绪,避免因情绪而带来麻烦,然后才能很放开的去充分沟通问题。

通过分析设计的方法验证UED价值

首先说明一点,本篇文章中提到的UED基本都指交互设计.

一、为什么需要数据验证?

天天看到你们也挺忙的,但是怎么衡量游戏的用户体验提升了多少?

是 的,高层对战略方向关注的更多,不可能了解每个员工所有的工作细节。在最终的游戏体验里,能看到漂亮的视觉、有趣的玩 法,却唯独感觉不到交互多美妙。其实交互设计的追求恰恰是“让用户感觉不到界面的存在”,只有感觉不到界面的存在,才能沉浸在游戏里,感受身临其境的愉 悦,感受玩法的趣味。

对于大多数公司来说,高层基本很关注投入产出,游戏也是一样,我们做一款游戏,能够通过广告投入吸引多少用户来玩,在来玩的用户中,大概能有多少用户留存下来,在留存下来的用户中,又能有多少用户付费。归根结底,公司关注的是投入多少成本、多少玩家付费。

二、我们大致摸索出一个通过分析设计来进行数据验证的方法

考虑高层更在乎投入产出的相关数据,我们决定演算出和“质量用户留存客服压力”这3方面的相关数据。其中质量关系着品牌影响力,产品的声誉等;用户留存关系着公司的收入;减轻客服压力可以为公司降低成本。

下面我们通过一个虚拟的示例来说明一下验证的过程。
1.
在所设计的系统中,抽样7个左右,就每一个原型进行分析。下面举一个操作步骤的统计过程。(如果为了追求客观,可以多找几个维度。)
本步骤示例:组队操作过程示意 (举抽样中的其中一个示例)

未有队伍时,通过点击主导航‘组队–>创建队伍成功的过程:

qiyu2011060301


 

优化前后的对比表

操作步骤 信息认知量
优化前 3 5
优化后 2 3

柱形图对比

qiyu2011060300


操作步骤和信息认知量对比

由此我们分析出,组队过程在操作步骤上减少了40% .

2.把抽样的数据汇总成一张表

(表中的数据为了后面的计算而虚拟)

系统名称 操作步骤减少
主界面导航按钮 40%
组队 40%
装备维修 54.5%
宠物 30%
家园 60%
家族 45%
摆摊 50%

 

3.根据步骤2的基础数据分别计算出公司层面关注的数据

提高产品质量

对7个数值进行平均。

(40%+40%+54.5%+30%+60%+45%+50%)/7=45.64%

保守估计,产品优化了45.64%

(注:数据的抽取,大家可以根据自己的需求进行抽取,尽量体现出品平均水平。)

对用户留存的影响

用户留存因素,保守假设:玩法50%,风格30%,UE20%

45.64%×20%=9.128%

即在用户留存的提高里,设计的因素占9.128%

(注:用户留存因素也可以根据自己掌握的实际数据调整所占比例。)

减轻客服压力预估

客服压力因素,假设:BUG20%,操作问题50%,其他30%  (这部分的假设最好听取一下客服部的意见)

45.64%×50%=22.82%

在客服压力减轻的因素里,设计因素占22.82%

(注:客服因素也可以根据自己掌握的实际数据调整所占比例。)

小结: 验证的方法有很多种,这里主要是在设计完成后,能够通过分析的方式来完成初步的验证。最终真实的效果还需要用客观的定量方法去验证,由于非本次重点,就不在赘述。