合作共赢-既生RD何生PM

【关键词】沟通和跨部门协作 【案例故事】 产品和技术是永远的矛盾共同体,非技术型产品经理可能会觉得:“即便我们拥有一只很强的技术团队,开发进度始终还是跟不上市场变化的节凑,无法满足产品策划乃至营销方案的需要。”而技术人员也可能会抱怨:“一周一个样,原先的产品设计就没想清楚,现在又要变了,真不靠谱„”。以下故事也许在我们周围经常碰到: 某APP产品经理希望能实时记录用户的登陆信息,技术人员听到这个需求,很简单啊,增加一张表在登陆时插一条新记录就行了,OK双方理解达成一致。版本推出了大受欢迎,用户数增长成倍长,产品经理心情大好,提出最好在登陆时要能显示出这个用户上次登陆的信息。技术人员免为其难的也实现了,每次登陆都会到上百万条记录中去找对应信息,结果性能成问题。还好经过技术高手的努力和重新调整,性能也不成问题了。虽然上线时间比产品经理预想的多了几天,有点郁闷但还是小开心,一得意又说了:每次登陆要有积分,下次登陆时显示出来,最好再排个名次,鼓励用户能多多登陆。这时技术真要打你了,早不说,现在每天都有上百万条记录,为了上次性能优化我已增加了一些东东,加个积分还说的过去,在确保保证性能的同时你还要统计出来还排名,我是干不了你找高手去解决?于是乎„„ 造成这种局面的原因是什么?如何才能让产品和技术更好的沟通协作? 【问题讨论】 产品经理与技术团队脱节了,原因有三: 1)产品目标不清晰 很多产品经理对产品都会有中、长期目标设定,但是由于自身对技术本身和技术发展趋势缺乏了解,从而导致在制定这些目标的是很容易忽视技术方案的匹配性。如果有偏差技术团队就会因为目标的不完整,造成设计的可扩展性不正确,导致经常性的返工和方案重新定义。技术框架合理选择和构建对于技术实现而言是至关重要,但这恰恰是产品经理最不关心的东西,总是会有这样的话出现:“先别管那些,把东西快做出来”,短期达标却为中长期埋下了一个巨大的陷阱,蜜月期一过,一切问题就出来了。因此,对于非技术型产品经理而言适度的掌握一些技术知识和技术发展,是其能对产品目标定义准确和把控的非常重要的基本功,尽量做到市场与技术实现的匹配是产品经理的要务。 2)需求描述不准确 需求描述说起来简单,就是把想要的内容告诉对方,对方按照这个内容去实现就行了。但是,恰恰就是这个“告诉”出问题了,先假设你能全面、准确和细致的描述,还要看对方是否能够完整、全息的理解你提供的信息。中文从来都是最复杂的语言,词不达意、仁者见仁的事还少见了么?再说,产品经理真的能够把产品的方方面面都讲清楚?起初你们可能会因为一个操控不如意,一个按键的位置不恰当,一段文字的描述不统一而争论,慢慢的你会为某个功能的不达标或者某种玩法的太弱智争吵,最后MLGB这种帽子就一直会伴随在你的头顶了。学习如何用技术沟通语言精确的描述需求也是非技术型产品经理的一个必修课程。 3)产品设计不了解 出现上面两个问题,后果很严重,但起码可以通过不断沟通,原形迭代,啤酒火锅来解决,因为产品经理你只要够主动、皮够厚、心够细、嘴够甜问题都是可以克服的。第三个问题就难了,这需要了解技术人员产品设计内容,举个形象又关键的例子)技术人员是如何组织管理你的客户信息,用户规模小的时候都没问题,不好的设计也能通过技术手段过关,而你只要从交互界面上、后台报表看到信息无误即可,但当用户规模上到百万级,它影响的不仅仅就是信息准确问题了,性能问题会扑面而来,更重要的是你的数据是否能如你想要这个话题就变的至关重要了。如果产品想做到精准营销,行为分析、深度挖掘等高级市场策略时,数据的设计不过关将会给你致命的一击,夸张点说)心中是黄金,手捧却是屎。这才说了核心数据问题,包括系统部署、技术选型等等一系列问题,都会随着产品的不断深化和规模化后,突显出来。正所谓最好的办法就是防患于未然,所以产品经理们可以看不懂代码,可以写不了技术设计文档,可以不会硬件知识,但一定要学会如何读懂数据,如何理解关键技术设计思路和方案,否则你无法做到真正的随心所欲,总有一环勒死你。 站在技术人员的角度,也应该力求做到) 1)清晰产品的故事纲要 很多技术人员在自嘲码农苦命时,却很少真正用心去了解自己所嫁的公司或和所生的产品。让我们来看那些传奇色彩的技术大神们,他们每位的成功背后恰恰都是源自个人的爱好或痴迷,而非仅是个技术能手,究其原因无非是大神们真正了解自己的每一行代码是为了什么样的目标产物而编写的。因此,我们不断提高自己技能的同时也需要努力试着去了解产品,一个好的产品就是一个艺术品,它必然要包含天文地理社会人文等综合价值。回过头,对于技术人员如何才能了解自己产品的真正目标呢:方法很简单就是通过)沟通与体会。与产品经理或需求团队不断沟通是最简单有效的方法,自己做自己的用户也不失一个好的办法,本人经常让技术团队去走访用户,让他们与使用者深度沟通进而获得用户对产品的第一手评价,也是值得推荐的让技术人员体味产品的一个好方法。我认为)一个好的产品开发者,应该是一个产品爱好者,更应该是一个出色产品评论家。 2)倾听需求的背后故事 RD要做的是扔掉厚厚的需求说明书,让我们坐在高高的谷堆上面,听产品经理讲故事,讲述那些关于产品的故事。其实每一个需求背后都有产品经理们一段凄惨不安的经历,我们要做的是撕开这段伤疤,尽情的去聆听产品经理们惨叫,知其病因对诊下药才能根治,很简单的道理。了解背后的动因,能让看我们选择最简单有效的技术解决案,更深层次而言,明白了产品真实的目标和需求背后的动因,是确保我们的每个设计才能否在扩展性和健壮性上双丰收的唯一保证。 3)成为情境速画大师 大谈交流和沟通,总给人一种宽泛的感觉,最终我们还是要回归到产品本身是否能够满足产品经理的要求上去,其实最直接的方法就是“情境草图”,在真正开工前不断的绘制这些”草图“可以是半成品,可以是纸上弹兵,更可以是白板板书….)总之一切可以用来描述自己对实现的理解和产物的描述的方法,都是一张草图,都可以用来作为沟通的媒介,目的就是通过沟通消灭所有“先做做再看”的不确定性。同样是费脑的工作,我想每个技术人员都知道,代码一经敲下影响的就是产品一生。所以先当一个绘画大师何乐而不为呢 4)开始越俎代庖当作家 知道了结局,听过了故事,情境剧幕也画好了,那么就让我们自己来写剧本吧。那些非技术产品经理们的写需求说明书扔了它,让我们来写一份真正能够帮助代码实现的需求规格说明书吧。有些人会问了,即然前三步已经OK,我们为何还不编码,还要浪费大量的时间来编写那个可能从来没人看的需求说明书呢其实,这个问题问的正确,的确这个规格说明书不是写给其它人看的,它就是一个梳理设计思路,编排设计素材的过程,正所谓“温故而知新”,在我们书写它就是进一步论证和回溯的过程,这绝不是一个形象工程而是一个必须的专业素养问题。 技术人员一旦成为高手或大师,其实本身就需要跳出了专业本身的范畴,起码要象个哲学者,说白点要有思想。技术人员不代表木讷,让我们主动架起沟通的桥梁,与产品经理和团队们一起把产品做的更好。

沟通和跨部门协作-主动扭转合作困局

【关键词】沟通和跨部门协作 【案例故事】 小王,某公司老员工,入职后就在A产品线从一线工程师成长起来,三年后开始负责A产品线测试团队的管理工作,与周边角色打交道的机会很多,与周边团队合作一直都很顺畅。2013年8月,小王响应组织架构调整轮岗到另一个部门负责B产品线的测试团队管理工作。 小王发现:在带领测试团队与产品团队的融合中,出现与产品团队沟通不畅、协作效率不高等情况,并且这种情况,对一线团队的氛围也产生不良影响。 据小王自己分析,最主要的原因在于对应的产品leader本身就是“难相处、说话不注意分寸和场合、戒备心强”的人,产品团队的其它同学在这个leader的带领下自然而然也被“熏陶”出同样的毛病。 其实,在与前任经理交接和团队one on one的过程中,小王就已经了解到测试团队与产品团队合作历史中充满着不愉快,团队之间互相猜疑、互相不信任,产品上线后就算出现了一个很小的线上问题也会互相指责,推卸责任,这种“不融洽”的氛围也令一线同学非常沮丧。因此,小王也想尽办法想扭转这种局面,他采取的措施是:对于出现的线上质量问题,小王带领组内同学第一时间跟进,不推卸责任,以解决实际问题和给出后续改进措施为重点。 对内,小王会给组内同学传递正能量,帮助一线同学建立对产品的信心,引导一线同学在遇到问题时多从自己身上找原因。一段时间后,小王发现情况有所好转,但仍然没有达到他的目标:各角色为了产品更好的发展而戮力同心,产品同学多传达一些产品理念,而技术角色能够在这种理念的指导下更好地配合完成技术实现工作。因此他很苦恼。 【问题讨论】 如果你是小王,面临这种团队合作中出现的问题,该如何解决呢? 建立透明的度量体系,由QA lead定期通报和呈现产品的质量情况,一方面表明测试同学一直在为产品的质量问题做努力,另一方面,让产品的同学能够更充分的了解全局的质量情况,避免出现一点小问题时就反应过激。 Leader之间先建立信任关系,尝试与对应的产品leader多做线下沟通和交流,交朋友,解除产品leader的戒心,让产品同学对技术同学产生更多依赖。 要有自我牺牲和批评的精神,遇到问题以解决问题为主,不盲目保护自己的利益。 以个人为媒介,主动找产品同学了解产品理念和后续规划,然后向一线同学传递这些信息,让一线同学对产品更有信心。

沟通影响-下属的越级沟通

【关键词】 向上沟通 【案例故事】 小海是某公司C部门的一名一线PM,入职后在C产品线从一线成长起来,三年后TRANS到A部门PM团队,被领导大张提升为管理者,管理5人团队。 小海团队的成员虽然都很年轻,但他们的个人能力都很不错,工作积极性也很强,比较受领导信任,能够胜任交代的工作;其中小新是最突出的一个,他能够替小海分担很多重要的事情。工作上一切运转的似乎都比较顺利。 随着工作的逐渐开展进行,小海在review项目时发现小新常会接到一些大张直接指派的任务,直到项目开展了一半甚至完成后自己才会知晓。而小新对自己的能力也很自信,喜欢在领导面前表现自己,经常绕过小海找到大张去汇报。小海通过自己分析,大张派给小新的部分项目预计收益并不高,这样可能会影响小新工作中其他一些高优先级的事情,对团队其他成员也会造成不好的表率。他感觉这样很被动;但大张在A部门的风格就是喜欢和一线同学直接沟通,没有什么架子;而小新也并没有在这些项目工作中犯错,小海感觉很困扰,不知道该怎样去处理这个问题。 针对这些问题,小海决定静下心来想一想… 【问题讨论】 1. 上下级沟通:对于下属越级沟通的问题,小海应与小新明确问题,团队成员的工作成果不止代表个人,更代表了团队,也代表了leader的认可;如果是大张的直接安排,小新应该在接到任务的第一时间,迅速反馈,同步信息给小海,后续按正常的项目推进流程及时汇报。 2. 领导管理方式多样化:小海应保持沟通并适应大张的风格,对于临时项目,建议先执行,后回顾,以及定期式回顾,整体看这些任务决定是否正向,并给大张及时反馈。 【管理者点评】 关于越级沟通的几点看法: 1. 如果出于业务需要,在某些紧急情况下,越级沟通是没问题的。但前提是做好整个团队的信息同步。即发生越级沟通之后,下属应及时主动地将越级沟通的信息同步给自己的直属上级,以及与此次沟通内容直接相关的团队成员。除非有特别需要保密的部分。这样做是为了避免出现由于信息不对称而对整个团队的效率造成影响。这一点作为管理者应该在团队内明确要求。 2. 越级沟通往往不意味着对中间层管理者的不信任,不要过于敏感,应该就事论事地去看待,并尽可能站在上级管理者的角度去思考问题。

沟通影响-向上沟通的艺术

【关键词】 向上沟通 【案例故事1】     王鑫给下属RD张华布置任务,希望能在1个月内增加几项新的功能。张华结合目前团队正在进行的几个项目,根据重要紧急程度,如果在1个月内增加这几项功能,人力压力很大,预计很难完成。于是张华跟王鑫提出能不能再多协调2个人过来支持?王鑫说,现在其他项目人手也都很紧张,估计很难协调更多的人力。张华听完之后,没再说什么,默默离开了。     项目进展过程中,张华还是尽力去协调现有的资源到这个项目上,其他项目都或多或少受到了一些影响,但是项目最后还是delay了。王鑫很恼火,质问张华为何没有如期做完?张华很委屈地说:我之前就跟您说过人手不够,做不完,而且我已经在想尽办法从其他项目协调人力过来支持了。王鑫说:你现在跟我说这个有什么用?项目组的PM经理直接投诉到我的老板那里了,我如何跟老板交待? 【问题讨论】 1. 为什么会出现这种情况?     张华(下属的问题),     1) 张华没有及时跟老板汇报进展     2) 张华没有跟老板说明如果不增派人手,可能导致的风险     3) 张华没有主动去争取资源     田鑫(上级的问题)     1)没有及时询问进展,进行过程监督和管理 出现这种问题,下属应该承担主要责任。 2. 张华应该怎么做?     1) 应该主动争取资源,在争取资源的时候,要跟老板强调如果资源不能保证的情况下,可能会带来的风险,引起老板关注     2) 即使没有争取到资源,也要及时阶段性汇报,让老板知道项目进展,让老板知情,不至于到出了问题老板才知道 【案例故事2】     田宇最近全身心都扑在某个非常重要的项目上,公司领导非常重视,目前团队所有成员都在加班加点赶进度,这2周马上面临上线,本来时间就紧,在节骨眼上,团队中一位很重要的研发人员小李,由于家里老人病重,临时请假,项目的压力就更大了。这时领导找到田宇,临时安排一个任务,希望在2天内完成,时间要求也很紧张,说是上面的领导派下来的。 【问题讨论】     田宇该如何去跟领导沟通?     面对领导对这个临时的任务的安排,田宇首先要表达积极的意愿,同时也要提出自己的想法,对于此任务进行say no,并说明客观理由,比如现行项目的压力等。最后针对领导的这个突发任务可以给出自己的建议。最后需要让老板去衡量,是否继续安排这个。     以下是接受任务时的沟通要点:     • 表示理解和积极意愿         理解上级的焦虑,担忧,急切     • Say no         提出异议,拒绝接受     • Explain(解释原因和说明顾虑)         说明现有任务的重要性和紧迫性         说明完成任务资源的匮乏     • Advice(提供建议)         提供2个以上的解决方案