创新还是沟通,这是个问题
听到Gino先生聊创新,说着说着,话题跑到了沟通上,随手记一些想法。
两个人,哪怕面对面,说上半个小时,如果没有相同的体验,有可能完全不知道对方在说什么;或者说就算知道,那种切身的体验,只能想象,不一定能理解。现场举了一个例子:Sam吃了一个不知名的糖,然后形容是“甜甜的,很滑,像巧克力”。Gino问Liang, 你知道他的感受吗?Liang摇头,于是吃了同样的一颗糖之后,他也开始形容:甜的,有点像巧克力。这个时候,两个人总算有了共同语言,有了真正在一定层次上的理解和沟通,而不是简单的点头同意。这个时候,两人会心的眼神比起语言更有说服力,有了真正切身的体会后,语言已是多余。
这种事情显然发生在男孩女孩之间更有说服力。路遥小说《平凡的世界》中,金波参军去青海。多才多艺的他每日听见墙外动听的歌声,于是与她对歌。几个来回过后,金波终于忍受不住内心的冲动,到墙外会见只闻其声未见其人的姑娘。在没有任何外人帮助的情况下,两个素未谋面、语言不通的青年一眼就认出了对方。更多的细节在这篇Blog中不适合描述;这里要说的是,人类许多朴素的感情与与生俱来的感受:喜怒哀乐、爱恨悲伤、音乐绘画、山川河流,他们自己比描述他们的语言更具沟通力。
人与人的交流,现在也许很容易——不是么,总有一个与你某一项兴趣相投的人。生命长度有限,宽度则取决于自己。社会能提供的远比人的数量少,因此总能找到说话的人。但要达到一定程度的沟通,却显得越来越困难,因为那些纯朴的感受已经被各式各样的外观包装起来。人们选择这些不同的外观并不一定处于同样的目的。一个简单的例子,许多人去健身,但并不是去健身房的人就能找到能沟通的人;有人无聊,有人体弱,有人喜欢运动;有人真喜欢运动,有人喜欢在运动中享受平静。在这样的一圈人中想要偶遇一定层次的沟通,概率与大街上的邂逅基本相同。
心理学家/医生在一定程度上,是这种现状的职业产物。通过一定的理论指导,丰富的人生阅历以及敏感的触觉,他们总能够倾听的时候,在恰当的时机对他的顾客进行一两句话点拨,以期有一些帮助。更多的时候,这是一种单向的帮助。它能够有效解决一定程度上的问题,更大的功能是单向情绪宣泄。
很多书在讲述如何说服别人。这是一个不太容易的事情。从许多人的经历看来,无论是充当说服者还是被说服者,这体验大多数情况都不好:因为在说服之前,几乎很少有人考虑被说服者的想法。一般是直接把观点说出来并试图别人接受。能够将这种思维倒转过来即将自己的想法埋在心里并仔细聆听对方想法的人,往往更受欢迎。如果此人更具备相当的领域背景,创新的可能是理所当然的了——一个好汉三个帮,在共同的理念下做事,事情当然做得又快又好。
说说老本行。无论是瀑布模型,RUP, CMM还是敏捷,这些方法论的支撑背后,都只有一个目的:使团队中的所有成员了解目标所在。换句话说,有共同的目标。这不能一蹴而就,只能通过某些手段。瀑布模型等采取了一种对人来说很奇怪的方式——大量的文档。要命的是,如果发生变化,这些文档瞬间变成废纸。在使用敏捷之前,我被教导:要让客户意识到,软件变化是很危险的,不能随便改变。这很奇怪。客户的观点发生改变这是很自然的事情,市场变了,为什么不变?
正如我在刚开始所说的,事实本身比描述事实的文字更有说服力。我们无法在很短的时间里让开发者、客户共享领域知识,于是敏捷采取了一个很简单的方式——让客户与开发者在一起。从这几个月参加的敏捷实践体会来讲,我隐约体会到上面所说的这些跟敏捷(Agile)“客户现场”的原则一致。我们常说,开发人员不知道客户要什么;真正的情况是,不仅如此,客户也不知道开发人员能做成什么样子。参与过的一些项目,开发者与客户相互诋毁也不少见。实际上没有人会做任何没有目的的事情,无论是开发者或是客户,都是普通人,都会有想法成熟不成熟,放在一个完全不同的领域背景下,理解的差异在所难免。客户现场的原则,将客户与开发者绑在一起,共同工作,共同体会一个软件从无到有,从bug产生到修复的完整过程,荣辱与共,风险共担;拥抱变化,使得允许普通人犯错误或者改变主意成为可能。即便外界环境发生何种变化(主要是市场),有了良好的沟通环境以及其产生的一致目标产出,使用敏捷始终交付最大价值软件成为可能。
其他一些想到的: 看到相当多的web应用开始关注用户体验,这当然是好的。web2.0的一些原则包括增强用户体验,提供创作内容的平台而不是内容本身,关注用户习惯等,这些比起传统的web应用来说确实迈进了一大步。然而,web应当更进一步,她应该更智能,更聪明,不仅仅根据你的行为猜到你的习惯,甚至能够根据你的习惯理解到你的真实想法,真正成为用户的聆听者/沟通者,为使用者提供更大的帮助。在资讯越来越发达的今天,成为聆听者也许比成为倾诉者更受欢迎。我知道这些想法未免有点惊骇,晚几天我会整理一些文字描述这些想法。