产品设计团队协作与沟通技巧(6页).doc

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