技术人员如何与非技术型产品团队沟通的注意事项

  “技术是产品的根基，但好技术不一定就有好产品”，同意的人继续往下看。

       产品：是指能够提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。（本定义摘自百度百科）

       根据上述定义产品可以看到产品的核心要素有两点：满足需求、成功交易。

       在姊妹篇【 非技术型产品经理与技术团队沟通的注意事项！ 】中我们聊了产品经理如何与技术团队沟通，反之作为技术团队：如何能够很好的理解和贯彻由那些我们眼中的非专业人士提出的需求呢？如何将我们的技术优势力在产品的最终实现上发挥的淋漓尽致？如何在技术实现过程中设计出相对甚至绝对稳健的架构进而减少由于不断的需求变更带来了架构设计变更？如果不再疲于奔命的在加班中一次次的调侃自己的猿人生涯？....

       解决方案只有一个：换位思考。

       技术人员的专业背景和生俱来的线性思维方式，让他们在看到产品需求时首先相到的是 技术合理性和技术可实现性 ，写到这里让我想起来下面这个段子：

        “博士后和民工的区别：联合利华引进了一条香皂包装生产线，结果发现这条生产线有个缺陷：常常会有盒子里没装入香皂。总不能把空盒子卖给顾客啊，他们只得请了一个学自动化的博士后设计一个方案来分拣空的香皂盒。博士后拉起了一个十几人的科研攻关小组，综合采用了机械、微电子、自动化、X射线探测等技术，花了几十万，成功解决了问题。每当生产线上有空香皂盒通过，两旁的探测器会检测到，并且驱动一只机械手把空皂盒推走。中国南方有个乡镇企业也买了同样的生产线，老板发现这个问题后大为发火，找了个小工来说：“你他妈给老子把这个搞定，不然你给老子爬走。”小工很快想出了办法：他花了90块钱在生产线旁边放了一台大功率电风扇猛吹，于是空皂盒都被吹走了。这个故事告诉我们：知识并不一定都是生产力；简单有效的办法才是大智慧！”

      本人认为故事的结果有点偷换概念，我认为它告诉我们什么才是真正知识，是只有被正确应用才算是知识，非则充其量是伪知识。博士输在应用而非“知识”，民工胜在生活经验有碰巧的嫌疑。

      本文不去争论故事本身，言归正传，通常产品经理想到一个点子或一个功能需求时，背后大多都有是一个市场反馈的结果，比如：某个用户投诉，某类用户行为、某种玩法、亦或是某个营销策略，但由于他们的非技术背景限制，在描述需求时很可能过于直白的强调的应用场景或效果，让技术人员产生一个误区：我要解决的电子自动化处理的某个环节，其结果必然就会产生一段如博士所干的一样的技术实现，呵呵！其实这时候如果技术人员能够稍停一下，换位思考一下，先去理解产品经理为何提出这个想法或需求，它背后的动因是什么？这样或许只需调整一段代码、几个参数或几个字段就能解决问题，而不是去加班加点调整自己的所有代码，最后还落得抱怨一片。

       综上所述，技术人员越俎代庖不一定就是个贬义词，我们在理解需求和实现技术之前要做好以下工作：

       1） 清晰产品的故事纲要
             很多技术人员在自嘲码农苦命时，却很少真正用心去了解自己所嫁的公司或和所生的产品。让我们来看那些传奇色彩的技术大神们，他们每位的成功背后恰恰都是源自个人的爱好或痴迷，而非仅是个技术能手，究其原因无非是大神们真正了解自己的每一行代码是为了什么样的目标产物而编写的。因此，我们不断提高自己技能的同时也需要努力试着去了解产品，一个好的产品就是一个艺术品，它必然要包含天文地理社会人文等综合价值。回过头，对于技术人员如何才能了解自己产品的真正目标呢？方法很简单就是通过： 沟通与体会 。与产品经理或需求团队不断沟通是最简单有效的方法；自己做自己的用户也不失一个好的办法；本人经常让技术团队去走访用户，让他们与使用者深度沟通进而获得用户对产品的第一手评价，也是值得推荐的让技术人员体味产品的一个好方法。我认为：一个好的游戏开发者，应该是一个游戏爱好者，更应该是一个出色游戏评论家。

       2） 倾听需求的背后故事
            这一点最好的例证就是我上文讲到的那个小故事，我们要做的是扔掉厚厚的需求说明书，让我们坐在高高的谷堆上面，听产品经理讲故事，讲述那些关于产品的故事。其实每一个需求背后都有产品经理们一段凄惨不安的经历，我们要做的是撕开这段伤疤，尽情的去聆听产品经理们惨叫，知其病因对诊下药才能根治，很简单的道理。了解背后的动因，能让看我们选择最简单有效的技术解决案，更深层次而言，明白了产品真实的目标和需求背后的动因，是确保我们的每个设计才能否在扩展性和健壮性上双丰收的唯一保证。

       3） 成为情境速画大师
            大谈交流和沟通，总给人一种宽泛的感觉，最终我们还是要回归到产品本身是否能够满足产品经理的要求上去，其实最直接的方法就是“情境草图”，在真正开工前不断的绘制这些”草图“（可以是半成品，可以是纸上弹兵，更可以是白板板书....）总之一切可以用来描述自己对实现的理解和产物的描述的方法，都是一张草图，都可以用来作为沟通的媒介。设计一个游戏，玩法定形后，代码开发前，通过详尽的草图来模拟产品的效果，甚至真人秀的未尝不可，目的就是通过沟通消灭所有“先做做再看”的不确定性。同样是费脑的工作，我想每个技术人员都知道，代码一经敲下影响的就是产品一生。所以先当一个绘画大师何乐而不为呢？

       4） 开始越俎代庖当作家
            知道了结局，听过了故事，情境剧幕也画好了，那么就让我们自己来写剧本吧。那些非技术产品经理们的写需求说明书扔了它，让我们来写一份真正能够帮助代码实现的需求规格说明书吧，有些人会问了，即然前三步已经OK，我们为何还不编码，还要浪费大量的时间来编写那个可能从来没人看的需求说明书呢？其实，这个问题问的正确，的确这个规格说明书不是写给其它人看的，它就是一个梳理设计思路，编排设计素材的过程，正所谓“温故而知新”，在我们书写它就是进一步论证和回溯的过程，这绝不是一个形象工程而是一个必须的专业素养问题。

       正所谓：行行出状员，技术人员一旦成为高手或大师，其实本身就需要跳出了专业的范畴，起码要象个哲学者，说白点要有思想。本文不谈技术人生的成长路径，只说我们做一个产品，一个好产品，单纯依靠专业技术和职业素养是不够的，博士不能不算是努力，其实结果呢？技术人员不代表木讷，让我们主动架起沟通的桥梁，与产品经理和团队们一起把产品做的更到最好。