标签归档:协作与沟通

我要的是葫芦

《我要的是葫芦》是人教版小学二年级语文上册的课文。文章讲述了一个人一心想要心爱的小葫芦长大,认为叶子上的蚜虫与葫芦毫无关联,毫不在乎。最终葫芦被蚜虫蛀了,他的愿望也落空了。

标题里用这个,想要说的事情是,我们要真正的理解目的,才能做出来合适的方案。用比较不人话的话来说,不要站在问题本身看问题,才能真正解决好问题。

最近,我跟小伙伴们讨论一个需求,我表达了我为什么要这么做的原因,然后给出了一个我心目中的方案。

接收到需求的小伙伴拿着我的目的和方案走了,在跟团队其他小伙伴讨论的时候发现,我的方案有瑕疵,实际无法执行,于是,他们又来找我。

这一次,我们讨论的不是「我要这么做的原因」,而是「我的方案」。于是,我们就探讨了半天,实际证明,我的方案确实是有瑕疵的,不能执行的。

搞了半天,我忽然想起来,我们为什么要花这么多时间来探讨我的方案呢?我其实只是想要那个目的啊,我其实并不是很在乎是不是用我的方案去做了。如果大家有更好的方案,那是更好的事情啊。

几个人在一起,复盘了这个事情,不由得觉得好玩。然后我们的一个小伙伴总结了一下关于这个事情的感悟,如下图:

我要的是葫芦.pic
这个事情之后,我做了一下反思,反思我在接收老板的需求的时候,和我作为老板向小伙伴们发出需求的时候,分别是怎样的遭遇。

首先,我们在发出一个需求的时候,都是会描述一个「我们想要的结果」,或者叫做「我们为什么这么做的目的」。为了让我们发出的这个需求看上去不是那么扯淡,我们常常都会附上一个「我们心目中的解决方案」,这个解决方案一方面是一种佐证,证明我们的想法是合理的,一方面也是一个指导,给出了一个大概的实现步骤。

然后,我们大概会遇到3个结果:

1、完全不能理解「我们为什么这么做」,但是,老板交待了事情,我们必须得做,就依着自己的性子,搞了一个方案出来。

不理解为什么,不参考指导方案,只盯着要的那个具象的东西,结果就是一塌糊涂。

2,能理解「我们为什么这么做」,但是,不能理解给出的指导方案的目的是什么,就完全照着指导方案去执行了。

这种是最常见的,这种是号称执行力强的做法。我理解你为什么要这么做,你也给了个方案,我要做的事情就是,二话不说,崛起屁股就干,我完全听你的。

这种强执行力的玩法,需要下发需求的人把事情想的足够明白指导方案给的足够正确,同时,实现路径也足够单一才可以。稍微复杂一点的业务,复杂点的事情,这种状态就会经常出现,我很努力,但是,我好像做的始终不是那么回事。

3,完全理解「我们为什么这么做」,明白指导方案与为什么这么做的关系。

这种是最牛逼的配合,你要的是葫芦,但是,我要帮你除草抓虫,因为,即使你知道种个葫芦很不容易,你也不会知道种个葫芦如此之不容易。

当然,就像我的小伙伴说的,不同类型的老板风格不一样。不过,我愿意善意的揣测说,其实,绝大部分老板是这样,他们想要的是葫芦,他们也知道种葫芦很不容易,他们给了你葫芦籽和种子,至于怎么种葫芦,你可以随意发挥,他们不会去干预,只要你能把葫芦搞出来。

其实,我们延展来看,这个案例,就是我们常说的「需求分析」了。如果我们把「老板」当成是一个用户,我们应该首先通过老板提的要求,去分析他真正的需求,理解了他真正的需求,再去思考怎么解决他的需求。

用户所有的需求都是这样的,我要的是葫芦,反正我要的是葫芦。

之前给新人做分享的时候,我经常会用一个例子来说明如何做需求分析及沟通:

– 客人:服务员,给我来杯水

– 服务员拿来一杯热水

– 客人:我靠,这个水怎么这么烫啊!

– 服务员:不好意思,不好意思,我给你换一杯

– 服务员去换了一杯温水来

– 客人拿起温水给自己的女朋友洗了个手

怎么做沟通,怎么做分析,这个故事你看得懂,就可以了。

— 题外话

每当看到我的团队里,有小伙伴有类似的总结与复盘感悟,我都觉得很有成就感。

我最近在思考,到底我们需要怎么样的成就感?或许在不同的阶段,对成就感的定义是不一样的,当我把我自己放在这个团队里的时候,我想,我需要的是让自己有成就感,让小伙伴有成就感,就是这样。

同时,从私心上讲,我又是很希望我的团队能学会独立思辩、勤于复盘、直接的表达,这些是我的价值观与做事方式,也是我认为一个好的产品应该具备的素质,我希望我能黑化他们。

江湖路漫漫,总希望能有志同道合或者臭味相投的人一起前行,大概就是这么个执念吧。

不知道是好是坏,管他呢!

基于权益的团队协作方式思考

故事1,我要的是葫芦

小D:小Q,我需要一个没有籽的葫芦,能搞定吗?
小Q:葫芦是可以搞定的,但是,没有籽的目前无法搞定,不过,搞定是可以的,但是需要很长的时间。
小D:都是男人,直接点,我在一周内需要,能不能搞定吧!
小Q:这个很复杂,而且目前的工艺还不具备,所以,我实现不了。
小D:好吧,我早就听腻了,我要的是葫芦而已,你跟说其他的有什么用?

故事2,放心大胆的去挑礼物吧
小Q:小D,去挑礼物吧,拣你最喜欢的拿,我付钱
小D:好啊,我喜欢那个2K的兔子
小Q:不行,我只能花20块,重新去挑吧
小D不依不饶又哭又闹,事情变得无法收场了….

故事3,我们种苦瓜吧
小M:小D,小D,隔壁种了苦瓜耶,不少人去围观了,收效不错哦,我们也搞颗来玩玩吧
小D:呃,苦瓜不适合出现在我们的园子里,而且,来我们园子的家伙们不太适应苦瓜的味道哦
小M:为神马,为神马?为神马隔壁搞苦瓜就能火呢?再说了,等我们种了他们自然就能慢慢接受了,说不定能把隔壁的人拉过来呢
小D:……

故事讲完,聪明的你一定也能看出来了,这里小D是个典型的设计师、小Q是典型的工程师、小M是典型的市场运营。是的,就是他们,上面三个故事讲的就是他们三个之间的世世代代都无法理清楚的剪不断的纠葛。

在 传统模式的团队里,市场运营人员从市场的角度来分析产品概念:谁需要某种产品,谁会购买这个产品,产品讲如何被供应和销售,其成本是多少;设计师根据产品 的卖相(视觉)和人机工程学等方面的知识进行测量,设计师更注重的是某个事物应该是什么样子而不是它现在是什么样子;工程师则只会专心的考虑产品技术创新 方面的概念问题,以及开发的技术成本。在这样的产品研发模式下,各自独立的专业分工,不可避免的就是出现三个中心。这也是上面三个故事出现的根源。

首 先,我们必须承认上述分歧是天然存在的;其次,这种分歧实际上对产品团队是有利的,当然,这种分歧是必须要控制在工作范围内的,工作范围外的分歧必然会危 害整个产品团队的发展;第三,控制这个分歧的理念应该是“以用户为中心的设计(UCD)”,而具体执行的家伙应该是产品经理

一般而言,解决团队的分歧会动用三种手段,分别是:权力、权利、权益。

以权力为基准的协商过程,简单说就是动用等级制度强迫别人做他们不愿意做的事情。其结果必然是产品相互间的矛盾,在协商中输掉权益的一方在今后的工作中往往会需求反击的机会,最终损害整个团队的运转。

以权利为基准的协商手段是运用各种已有的标准、和观点等来解决纷争。这里往往会有输掉冲突的一方,或者必须选择一种折衷的方案。虽然协商各方的权利在设计过程中都有他的地位和作用,但是这种方法得到的结果往往都是常规的,缺乏新意的。

以权益为基准的协商反映了与项目相关的每一个人所关心、期待和需求的事情。我们了解每个人的喜好和工作重点,找到消除障碍的权益措施,从而使所有人所有专业的权益得到兼顾。而更重要的一点在于,用户的利益也被考虑到其中了!

如果我们使用一种以权益做基准的协商手段为主、适当的时候结合权利基准、不得己时小心动用权力的团队协作方式应该可以得到团队效率的最大值。

所以,在一个团队里,我们应该鼓励任何人拿下面的问题去问任何人(注意,是任何人都可以这样问,特别是产品经理最需要被这样拷问!):我们这个产品的核心用户是谁?我们是在什么情况下,满足他们的什么需求?这个产品模块的市场目标是多少?我们面临多大的技术难度?

最后,四个问题的答案必须的是理性的(有数据支撑的),而不是以“XX这样说”、“我认为”、“以XX的经验来看”。正确答案的格式是:“根据我们拿到的数据进行分析…..”、“我们做的用户访谈说明….”、“根据市场预测并且基于我们产品的成长….”

思维盲点

读《明朝那些事儿》,朱棣起兵造反欲取建文帝而代之,在离胜利只差一步的时候,朱棣陷入思维陷阱。朱棣得知京师空虚,如果此时出击京师必可得胜,但是此时朱棣在北平建文帝京师在南京,而在通往南京的路上,最大的障碍就是山东,此地民风彪悍,士兵作战勇猛,而且还有名将镇守,无论如何也是很难打过去的。在朱棣看来这是一个很难克服的障碍!

于是朱棣很郁闷,欲取建文帝需先取京师,欲取京师则必取山东,但是,山东无法撼动。朱棣倒推了一下,发现,自己没有希望了…..
就在朱棣钻入思维牛角尖的时候,谋士告诉他,我们的目标只是京师而已,去京师又不是只有一条单行道,条条大路都可通京师,我们为什么不绕道山东过去呢?朱棣恍然大悟,遂引兵南京,夺了江山…..

当年明月认为,这里山东就是朱棣的思维盲点,朱棣对江山、京师、山东三者关系的推定就是思维死循环。读到此处恰逢近期也遇到类似的事情,颇有感受。
4月的时候我的房子会到期,过年来了之后我和室友连想到没想直接准备换房子搬家,于是我们找了约半个月的房子无果。我们的问题是,我们可以接受房租比去年稍贵的地方,但必须离地铁近。于是我们拿着这2个标准去对照,发现,根本没有办法做到,地铁边的都超级贵,便宜的都质量很差,同时不满足交通。
就在我纠结与房子的时候,有天我突然问我自己,我为什么要搬家?我搬家的目的是什么?是为了上班方便,同时房租不贵。OK,那,我现在住的地方算不方便吗?不算!那,我现在住的地方房租算贵吗?虽有涨幅但与寻找新房相比相当能接受…..

靠!问题回来了,那,为什么要搬家?又折腾又难找…于是,我说服自己继续住这里。

在做产品设计的时候,我也会经常钻牛角尖,当由于技术的或者其他的阻力的时候我发现我无法按照之前的构想来继续设计,于是,我不断的对之前的那个想法进行改良,不断的堆加新的东西进来进行补充与完善以求可以实现,最后搞的自己累的要死。
突然有一天睡觉之前,我问自己,为什么花这么大的力气来做这个模块或者这个交互?目的是什么?最后发现,靠!完全可以舍弃他,对核心功能没有影响啊,遂释然….

2010年3月的UCD书友会话题是“设计的沟通与协作”,在说到如何向团队成员表达你的设计意图的是时候,Angela提到应该先再次的向团队成员统一我们为什么要做这个?然后再开始布道….其实,也是这个意思,永远不要忘记问题的核心点,不要被横着的马其诺防线挡住,可以试着把他竖着来看!
如果在做产品设计的时候把现在做的东西与我们的目的进行比对,或许会避免出现很多不必要的思维盲点。以此共勉。