游戏化到底有什么用

之前的某个周六和fxp007聊了一下午,从一个基本的基于地理位置的产品构思,到startup成长过程中可能遇到的问题,很少有机会和创业圈的朋友进行如此深入的交流,老实说从讨论结果来看,我也开始意识到TW本身的一些问题。

小平是个十足的实用主义黑客,从nodejs到avos的重度使用,无不看出他们把优秀的hacker基因划入急速的产品交付中的能力,这点和TW的工作模式其实是有很大共通性的,只不过在互联网大潮中,我们渐渐在失去这个优势,如果说敏捷是TW基因里最有价值的东西,那么Gamification便是Agile的核心思想。

肖然上次的分享里提到一句“Poster 是我们咨询中最大的武器,当你面前的墙上贴满poster时,就可以是一口气了,因为有这么多问题,随便从哪里开始都可以了。”

Poster是敏捷的一项gamification创新,一些看似平常的贴纸,再通过条条框框分割开来,就是inception的第一步“发散与归类”。

如果你的方案设计是有趣的,那么它一定是有价值的。因为“让人快乐”本来就是大多事情的本来意义。

如何界定游戏化

规则 + 乐趣 = 游戏

不存在没有规则的游戏,因为游戏需要规则才能成型。 也不存在没有乐趣的游戏,因为游戏需要乐趣才能成功。

游戏化在软件开发中的例子

Reverse Conway’s rule

“设计系统的组织机构会受到一种限制,即产生的设计会复制这些组织机构的沟通结构”,Mel Conway在1968年写道。他接着说,设计者第一次想到的架构几乎不可能是最好的设计,所以公司应该同时准备好改变它们的产品架构和组织结构。

什么样才是一个好的Agile组织结构?你可以说“我的团队如果能多一个QA,可能就会好很多”,但是你肯定不会说“2个Dev加1个QA,然后这就是最强配置了”,因为人是不可以用标签衡量的个体。

组织结构的演进是每个项目、企业、组织都会遇到的课题,在不断的扩张中,松散的结构会逐渐依据职能而划分为各个部门,设计系统应该追随组织结构,还是应该先于组织结构,是不成定论的,设计系统就是游戏化的一个要素“规则”,如果统筹组织的方式是“有趣”的,那么最终这个游戏化的组织结构就能发挥出魔力,反之,如果制定一套“无趣”或者“无序”的规则,都会诱发组织的僵化或者混乱。管理者尤其需要评估这些点。

看板

游戏化的另一个经典体现是看板,丰田是首个实践看板方法的企业,之后软件业的敏捷思想也受到了看板的熏陶而自成一派。看板是源于丰田这个精益之源,同时也是一个非常自然的习惯,大概是受启发于会议白板和课程表,但是通过引入story周期和泳道,为这个古老的进度跟进方法注入了新的血液。一个看板可以画成千奇百怪的样子,哪怕是游戏地图里的模样,只要能自圆其说也不为过。游戏化的另一个经典体现是看板,丰田是首个实践看板方法的企业,之后软件业的敏捷思想也受到了看板的熏陶而自成一派。

一个看板包含了游戏规则,在规则内的项目进度,会按照不同的执行者而形成不同的风格,比如有的时候,看板的work in progress非常宽裕,一部分人会由此变得非常紧张,认为太多任务没有完成,同时对于相对灵活的团队,这又恰恰提供了一个比较流畅的氛围,可以通过不断的变换策略来更高效愉悦地达成目标,所以看板看似一种很老土的方法,却是包含了对人个性的考虑,好的看板模式是对工程心理学的一种可视化。

游戏化的例子还有许多,下一篇开始我会举一些更加有趣的例子供参考