研发 VS 产品

花火田丁 花火田丁 2019-02-12 15:59:18 +0000

题图来自于NextDay

最近时常需要兼任产品相关的工作,也就是传说中「产品经理」的相关职责。

关于研发和产品之间势同水火的状态,业界已有很多段子。产生矛盾的原因多半还是因为互相对于对方的知识领域不了解,同时又无法说服对方。

作为研发,在设计一个产品原型的时候,画具体界面的时候,本能地会首先去考虑技术上是否可实现,毕竟再好的设计也要落地了才能发光发亮。于是,有研发背景的产品经理,本能上设计出来的产品一定是可实现的,研发的同事拿到设计稿至少不会因为不可实现而吵起来。

显然,这也是一种局限,这样的设计相对比较保守,稳妥/能做出来为主要宗旨。中规中矩,甚至没有特色,用户体验和界面美观上就会有欠缺。作为产品,用户体验、产品的核心价值如何体现才是最重要的点,围绕这些点,操作是否简洁明了、界面是否符合受众的审美才是关键。

一边追求稳妥,一边追求体验,体验通常意味着一些细节的处理,一个看似很小的功能需要暗含很多处理逻辑,用户用起来无感,但是背后的设计可能相当复杂,于是很大程度上会需要增加研发的工作量。能不能实现,以及如何更好地实现,这些都是研发需要考虑的问题,有些只是需要更多的时间,有些需要去引入新的技术框架,但这些过程,如果没有一定的技术背景,很难去预估工作量,那个吵翻天的点就在这里,产品经理认为改一下应该很快啊,就几个按钮嘛,而研发心中已经一万只在奔腾,但似乎又跟产品解释不通,真是懊恼。

反之亦然。产品觉得某个按钮不应该放在 A 处,而应该放在 B 处,而对于研发来说,也许并没有太大区别,也许牵一发而动全身,但就是不理解为什么非得放在 B 处,这时候该换做产品心中一万只在奔腾,但跟研发也同样解释不通,更是气愤。

多数的沟通不良,都是认知上的偏差,如果研发有设计背景,而产品有研发背景,沟通上势必会顺畅很多。作为一个有追求的研发,花点时间去研究下设计,比起产品的人去研究技术,通常情况来说,要更容易一点。再加上,如果在设计产品的时候,能够暂时抛开技术的局限,那就无敌了。

原型图工具真是个好东西,可以在真正研发开始之前就把很多产品细节展示出来,所以我一般倾向于提供比较详细的原型图,而不是简单的跳转关系的草图,原型图中小到一个按钮的图标、一个点击动作、一个加载提示都是最接近最终产品形态的。有这样一个原型的好处在于,无论是跟领导沟通,还是跟研发的同事沟通,都非常顺畅,界面长什么样、如何跳转都看得清清楚楚,这样研发的同事心里也有底,哪些点会需要消耗较多的工作量、难度如何,也都一清二楚了。

最理想的沟通状态是,双方对对方的领域都有所了解,至少有基本的常识,基于这样一个「共同的认知」,沟通的结果也一定不会差。那这样是不是意味着我们需要掌握很多领域的知识,理论上是这样的,就像查理·芒格时常提到的「跨学科」是一个道理,不要认为做出一个投资决策仅仅具备金融知识就够了,一个详尽的调研和决策可能会涉及很多行业。但如果每个学科都精通,确实需要付出异于常人的精力,对于我们大多数人来说,可能会有点困难,那么就退一步,不需要个个都精通,但是常识性的理论(Common Sense)还是要花时间去学习下,这样至少碰到问题,我们会知道要从哪入手,再去找寻更深入的答案。

所以当同时需要兼顾产品和研发时,对我来说,有技术背景,保证产品可实现这一点无需担心,跟技术同事沟通也不存在任何阻碍,更大的挑战在于如何跳出技术的限制,有时候确实需要更天马行空一点,用好的设计来倒推更好的技术实现方式。


撒欢吧
谈理想
聊人生
讲故事
相对论
花火田丁
微信号:huahuoding
花火田丁
不折腾不人生