合作共赢-既生RD何生PM

【关键词】沟通和跨部门协作

【案例故事】

产品和技术是永远的矛盾共同体,非技术型产品经理可能会觉得:“即便我们拥有一只很强的技术团队,开发进度始终还是跟不上市场变化的节凑,无法满足产品策划乃至营销方案的需要。”而技术人员也可能会抱怨:“一周一个样,原先的产品设计就没想清楚,现在又要变了,真不靠谱„”。以下故事也许在我们周围经常碰到:

某APP产品经理希望能实时记录用户的登陆信息,技术人员听到这个需求,很简单啊,增加一张表在登陆时插一条新记录就行了,OK双方理解达成一致。版本推出了大受欢迎,用户数增长成倍长,产品经理心情大好,提出最好在登陆时要能显示出这个用户上次登陆的信息。技术人员免为其难的也实现了,每次登陆都会到上百万条记录中去找对应信息,结果性能成问题。还好经过技术高手的努力和重新调整,性能也不成问题了。虽然上线时间比产品经理预想的多了几天,有点郁闷但还是小开心,一得意又说了:每次登陆要有积分,下次登陆时显示出来,最好再排个名次,鼓励用户能多多登陆。这时技术真要打你了,早不说,现在每天都有上百万条记录,为了上次性能优化我已增加了一些东东,加个积分还说的过去,在确保保证性能的同时你还要统计出来还排名,我是干不了你找高手去解决?于是乎„„

造成这种局面的原因是什么?如何才能让产品和技术更好的沟通协作?

【问题讨论】

产品经理与技术团队脱节了,原因有三:

1)产品目标不清晰

很多产品经理对产品都会有中、长期目标设定,但是由于自身对技术本身和技术发展趋势缺乏了解,从而导致在制定这些目标的是很容易忽视技术方案的匹配性。如果有偏差技术团队就会因为目标的不完整,造成设计的可扩展性不正确,导致经常性的返工和方案重新定义。技术框架合理选择和构建对于技术实现而言是至关重要,但这恰恰是产品经理最不关心的东西,总是会有这样的话出现:“先别管那些,把东西快做出来”,短期达标却为中长期埋下了一个巨大的陷阱,蜜月期一过,一切问题就出来了。因此,对于非技术型产品经理而言适度的掌握一些技术知识和技术发展,是其能对产品目标定义准确和把控的非常重要的基本功,尽量做到市场与技术实现的匹配是产品经理的要务。

2)需求描述不准确

需求描述说起来简单,就是把想要的内容告诉对方,对方按照这个内容去实现就行了。但是,恰恰就是这个“告诉”出问题了,先假设你能全面、准确和细致的描述,还要看对方是否能够完整、全息的理解你提供的信息。中文从来都是最复杂的语言,词不达意、仁者见仁的事还少见了么?再说,产品经理真的能够把产品的方方面面都讲清楚?起初你们可能会因为一个操控不如意,一个按键的位置不恰当,一段文字的描述不统一而争论,慢慢的你会为某个功能的不达标或者某种玩法的太弱智争吵,最后MLGB这种帽子就一直会伴随在你的头顶了。学习如何用技术沟通语言精确的描述需求也是非技术型产品经理的一个必修课程。

3)产品设计不了解

出现上面两个问题,后果很严重,但起码可以通过不断沟通,原形迭代,啤酒火锅来解决,因为产品经理你只要够主动、皮够厚、心够细、嘴够甜问题都是可以克服的。第三个问题就难了,这需要了解技术人员产品设计内容,举个形象又关键的例子)技术人员是如何组织管理你的客户信息,用户规模小的时候都没问题,不好的设计也能通过技术手段过关,而你只要从交互界面上、后台报表看到信息无误即可,但当用户规模上到百万级,它影响的不仅仅就是信息准确问题了,性能问题会扑面而来,更重要的是你的数据是否能如你想要这个话题就变的至关重要了。如果产品想做到精准营销,行为分析、深度挖掘等高级市场策略时,数据的设计不过关将会给你致命的一击,夸张点说)心中是黄金,手捧却是屎。这才说了核心数据问题,包括系统部署、技术选型等等一系列问题,都会随着产品的不断深化和规模化后,突显出来。正所谓最好的办法就是防患于未然,所以产品经理们可以看不懂代码,可以写不了技术设计文档,可以不会硬件知识,但一定要学会如何读懂数据,如何理解关键技术设计思路和方案,否则你无法做到真正的随心所欲,总有一环勒死你。

 

站在技术人员的角度,也应该力求做到:

1)清晰产品的故事纲要

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

2)倾听需求的背后故事

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

3)成为情境速画大师

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

4)开始越俎代庖当作家

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

技术人员一旦成为高手或大师,其实本身就需要跳出了专业本身的范畴,起码要象个哲学者,说白点要有思想。技术人员不代表木讷,让我们主动架起沟通的桥梁,与产品经理和团队们一起把产品做的更好。

发表评论

邮箱地址不会被公开。