工程师和产品经理之间的恩怨情仇,一直是科技圈茶余饭后久盛不衰的一个话题。“产品狗”摧残“码农”的故事、或者工程师吐槽产品经理什么也不懂只会乱提需求的段子屡见不鲜。那么,产品经理和工程师到底能不能和谐共处,成为一个战线上的好伙伴?
其实,一个优秀的产品经理不仅能和工程师有效合作,甚至可以让工程师觉得跟定了你,没你不行。
在硅谷,我们常说一个顶尖的产品经理每次跳槽,都能拉走一堆优秀的工程师,究其原因:一是,这样的产品经理确实不多见;二是,遇到一个好的产品经理,工程师可以把更多精力花到他们感兴趣的、有巨大影响力的方面,可以更有效率地做出优秀的产品。
在硅谷的很多顶尖科技公司,都是 “工程师导向”的文化,也就要求产品经理不能像监工一样告诉工程师应该做什么。如果产品经理对工程师指手画脚,那工程师会顿时失去工作的兴趣,吵着嚷着要换组、换产品经理。
但是,一个真正优秀的产品经理能够让工程师兴奋起来,满腔热情地投入到产品开发中;而这种热情一旦被激发出来,产品经理就再也不用担心工程师会拖延工期、消极怠工,相反工程师甚至会比你更积极。
那怎么才能激发工程师的能动性呢?我至少和百位不同背景、不同资历的工程师工作过,在无数次“踩坑”后,我总结了下面的这些建议。
第一,作为产品经理,你应该知道这个工程师在乎的是什么。
他是一个刚毕业不久、满腔激情、想赶快升职加薪的工程师?还是一个想解决最高难度的技术问题,哪怕产品没人用,只要解决的问题难度足够高就高兴的工程师?还是一个满肚子主意,极其讨厌产品经理告诉他该做什么的“点子大王”?还是一个有些害羞、很多想法都憋在心里,但其实特别希望自己有存在感的人?
知道了他在乎什么,你才能知道怎么激发他的能动性,以及该让什么人做什么样的项目。
知道工程师要什么,想办法在现有的项目里给他们相应的机会,会让你们之间的合作事半功倍。 至于怎么知道工程师要什么,你不如和他约个时间喝杯咖啡私聊一下,了解他的个人情况,你甚至可以直接问他:“你是如何决定自己做的事情有没有价值的,你在乎的是什么?”
第二,产品经理应该知道怎么和工程师沟通最有效率。
很多工程师最讨厌的就是开会,因为30分钟的会议打断了他们的思考时间,拖慢了他们写代码的进度。
所以作为产品经理,虽然你每天要花很多时间在开会上,但是要考虑一下这个会到底有没有必要让工程师参加,可不可以安排到这个工程师其他会议之前或者之后的时间, 这样尽量少地打断他们的思考,以便于他们有效率地编程。
你还需要思考,除了开会之外,还有没有其他可以高效做决定的方式,比如发个邮件。
第三,产品经理要弄清楚什么决定需要自己领导大家做,什么决定可以放心地交给工程师们自己做。
比如,某个按钮是100像素还是120像素,类似这样的决定,是不是可以让工程师和设计师自己决定?
很多产品经理常犯的错误是,自己做出所有的决定,和工程师交流时只是要求他们按照指定要求来做,但实际上有些要求根本就不切实际。 更或者,按钮是100像素还是120像素,可能对于产品的成败来说,并不是最重要的决定, 你完全没必要在这种决定上花时间。
还有些产品经理只告诉工程师要做什么,从来不解释产品的目的、成功的标准,工程师完全不知道这些决定背后的策略和思考过程, 结果就是事事都需要产品经理告诉他们要怎么做。
其实,一个好的产品经理一定会清晰表达产品要解决的问题、如何衡量成功、需要最先解决的用例以及原因,让产品团队的工程师、设计师、数据科学家等都有足够的背景信息。 这样,很多的小决定完全可以让团队成员自己做,从而既可以大大提高产品效率,又可以提高团队成员的能动性。
当然,这并不是说产品经理什么决定也不用做,一个优秀的产品经理,会确保自己的时间花在“非我不可”的事情上,其他决定都会交给他人。设想, 如果一个产品经理把每天的时间都花在解决按钮是100像素还是120像素这种问题上,他们哪还有时间去和客户做一对一交流、制定产品战略、思考“脑洞大开”的新功能。
第四,产品经理应该帮助工程师解决开发过程中的一些困难。
很多工程师在开发过程中会遇到一些困难,比如因为其他组工程师进展缓慢而导致开发工作停滞,因为开发的新功能被律师认为风险太大而面临一些质疑,等等。因此,产品经理应该积极询问工程师:“你需不需要我为你提供一些帮助”,帮助工程师解决开发过程中遇到的障碍。
因此,帮助工程师扫清开发路上的各种障碍,可以提升你的产品开发效率,而这正是优秀的产品经理需要做的事情。 比如,我常常对工程师说:“现在有哪些工作是你不喜欢做的,告诉我,无论是脏活累活,我来帮你做”。其实,这也是一个帮助你和工程师建立信任关系的过程。
这个问题是很多刚入行的产品经理最担心的,我的建议是,让工程师先自己估计需要的工期,然后再设定截止日期。如果他们预估的工期太长,我可能会提出一些问题,弄清楚为什么需要这么长时间,看看哪些部分可以砍掉,到底值不值得为截止日期砍掉这些功能。
工程师估计完自己需要的时间后,我会和工程师说明我们的发布计划, 比如某月某日营销团队会开始宣传产品功能、 某月某日我们需要开始运营工作等等,这样可以让工程师了解其他部门的进度,增强他们的归属感。
刚入行不久的工程师估计工期的能力比较差,如果他们的工期估计得太长,我就会想方设法让他们告诉我工期是怎么估计出来的,然后跟他一起讨论,哪些部分可以用现成的API,哪些部分可以少花一些时间。
如果遇到确实要将截止日期提前的情况,我会告诉工程师需要提前的详细原因。这样做的目的是,让工程师觉得你和他是一起的,让他感觉到你的信任、你在思考如何一起解决工期提前的问题。
所以,我一般不会直接说要花多长时间,而是让工程师先估计工期,如果我觉得估计得过长,我会诚恳地告诉他我们需要加快进度,看看有没有什么方式能够重新组合一些计划,以加快工期。
在这里,一定要让工程师觉得自己是有掌控权的,而不是产品经理一拍脑袋,就决定个截止日期。 就算这个截止日期是你自己拍脑袋决定或者老板要求的,在表达日期的时候也要尽量体现出对工程师的尊重,用问问题的形式表达自己的看法,积极地和工程师一起寻求提前工期的方式。
改产品需求是一个非常常见的过程,有些时候前期计划做得很好,开始Beta测试时却发现,用户对某个功能根本不理解,还是需要改动。
其实,开发本来就是一个不断迭代的过程,所以应该首先认识到,产品开发不是产品经理闷头花几个星期写一个文档, 然后再抛给工程师让他们按照这个文档执行的过程。
但是,改需求并不代表产品经理可以在产品需求文档上胡写乱写,做出一些不靠谱的决定,这是在浪费工程师的时间。这里我就跟你说说有哪些方式能够避免在开发后期改需求,如果真的要改需求,如何和工程师有效沟通。
其实很多时候,就算产品经理自己主动承担责任,工程师也不会“顺杆爬”埋怨你,他们反而觉得你是个靠得住的好产品经理,甚至会过来安慰你。
积极承担责任,说句“抱歉,辛苦了”,虽然对你来说就是一句话的事儿,但这可以很好地安抚已经努力工作了一个月、每天加班加点儿的工程师。很多时候,给工程师们一些鼓励和温暖,虽然看上去微不足道,但却能让他们干劲儿百倍,对你死心塌地。
最后,我来给你提炼一下今天的要点。
要做到和工程师的有效沟通,你作为产品经理需要做到:第一,知道这个工程师在乎的是什么;第二,知道怎么和工程师沟通最有效率;第三,弄清楚什么决定需要自己领导大家做,什么决定可以放心地交给工程师们做;第四,帮助工程师解决开发过程中遇到的困难。
接下来,我还跟你分享了怎么催工程师加快进度,以及怎么处理改产品需求这种常见的棘手问题,归纳起来不外乎这几点:第一,尽早和工程师进行产品功能设计的讨论,让他们提前了解各种背景信息;第二,积极承担责任,把过错往自己的身上揽,而不要抛给工程师;第三,要让工程师觉得自己是有掌控权的,而不是产品经理一拍脑袋就决定了截止日期和产品的需求。
欢迎你给我留言。