以用户为中心的设计 |
|||
设计的沟通与协作,这个话题一抛出来,就让我很头大。 需求方、产品经理、UIUE、程序、测试之间的烂事儿一大堆。涉及到第三方甚至是几个公司之间而非一个公司内部,那沟通的困难更是雪上加霜。再如果涉及到跟政府部门的协作,那简直就是一场灾难,2012。 即便是内部沟通,考虑到内部利益集团博弈,互相拆台这样的事儿发生,那基本上就完全是无法沟通,只能靠手段去制衡。 所以,真要讨论涉及的沟通与协作,必定要设定一个相对理想的环境,即:大家都是对事不对人,才有可能讨论下去。否则,就要用辩证的具体问题具体分析 了。而我下面写的关于沟通的问题,也是基于理想化环境的,因为我是一个产品经理,所以我是站在产品经理角色去理解和处理这些问题的。 沟通、协作是个盘古开天地时就遗留下来的问题,同样,也遗留下来了五件必杀神器: 1:你们有我懂设计吗? 这五神器分别被美术、产品、技术捡到。神器一出,秒杀,你郁闷到缩阳也没用了。在UCD珠海书友会上,金山同学第一个问题就是技术使出必杀:这个我们没法实现。 对于五大神器,我实在碰到过很多次,其实必杀可破,只看你愿不愿意。破必杀之法,我归纳为五点: 1、平等对话 如果作为一个产品经理,却不知道自己业务的底层是怎样,基本代码、数据原理是怎样,被人丢必杀技是活该。 引用某前端一句话:“我绝对拒绝与连HTML都不懂的产品经理合作,这是底线。” 2、自己是否想清楚,是否真有必要; 向别人提出需求的时候,一定要想清楚,是否真的要这样,有没有必要。想办法说服别人时,最好能有数据说明你的需求是确有必要的,能缩短用户查询时间、提高装机率、降低卸载率,提高在线时间等。产品经理做好事前分析工作,是对自己工作的尊重,也是对合作拍档的尊重。 拍拍脑袋的决定,最好不要搞。毕竟我们轻描淡写几句话,技术、美术可能就要为你这几句话忙活几天甚至是数周。 3、别人拒绝时,弄清为什么; 关于这一点金山的剑三总监唐洪亮打得比方很好:厕所地上有水,为什么有水?因为笼头滴水,为什么滴水?因为人没关紧,为什么没关紧?因为笼头不是很好关,为什么不好关?因为笼头的设计问题,那为什么要采购这种笼头…… 碰到问题,不能退缩,要较真,要去问,要打破砂锅问到底。 程序员有一个信念,这个世界上,没有代码实现不了的事情。如果他说无法实现,一定是他不想。为什么不想,要么是修改成本太高,要么是你的需求他认为根本没必要,要么是他压根看你不爽,八字不合。找出问题根源,然后对症下药,总能解决的。 4、确认别人理解的,是你想说的; 你想的是A,讲出来的是B,别人听成了C,理解后变成D,最后再加工做出来个E,网友一看,说:这傻×公司,做出来个F,就是Fuck的意思。 沟通变成鸡同鸭讲,世界将会怎样?要避免这种情况,所以在沟通之前一定要保证信息对称,需求背景、调研资料、用户数据等,免得你突然说出来一个决定,别人莫名其妙的,怎么沟通? 说完以后,还要确认对方接受了你的信息,并且理解的也是跟你一样。所以需要让他复述给你一遍,就像集结号里面谷子地给团长复述命令,信息发出与接收需要Match一次,确认无误后,这次沟通才算结束。 5、他性格怎样、情绪怎样,你跟他关系好嘛? 一般来讲,解决上面四个问题,报障基本沟通是没有问题的。但比较我们是人,不是机器,所有流程执行完毕,Match一次,确认无误就OK的。人,是 会有情绪,会有关系的。所以当需求被拒绝时,还需要考虑人的因素,比如说:股票亏了,老婆跑了,情人吹了,别人发了……等等,这些时候你热着脸去找别人沟 通,别人只会给你屁股。 无论你们公司体制怎样完善,找技术、美术等拍档多吃吃饭,一起出去远足什么的,交换一些私人空间,成为朋友,这样有事儿的时候,你能理解我,我能理解我,共建和谐新社会。 至于沟通的泛技巧比如倾听、表达、平等、等,就不在此说了,其实,很多时候碰到的问题,都是制度上的存在问题,如果大家的利益捆绑在一起了,可以解决很多的沟通问题。 以上所列都是平级或跨部门沟通的问题,除此之外,还有与上司沟通的问题,与下属沟通的问题。这就不算设计的沟通与协作范畴了,不过我看到一篇文章,觉得说得不错,简单归纳一下,就是三点: 一、向上沟通没胆:下属向上级沟通时没有胆量,缺乏积极主动性。 说了这么多,再自省一句:任何事情,懂得再多理论,都要注意知行合一。 |