16 如何和工程师有效沟通?

工程师和产品经理之间的恩怨情仇,一直是科技圈茶余饭后久盛不衰的一个话题。“产品狗”摧残“码农”的故事、或者工程师吐槽产品经理什么也不懂只会乱提需求的段子屡见不鲜。那么,产品经理和工程师到底能不能和谐共处,成为一个战线上的好伙伴?

其实,一个优秀的产品经理不仅能和工程师有效合作,甚至可以让工程师觉得跟定了你,没你不行。

在硅谷,我们常说一个顶尖的产品经理每次跳槽,都能拉走一堆优秀的工程师,究其原因:一是,这样的产品经理确实不多见;二是,遇到一个好的产品经理,工程师可以把更多精力花到他们感兴趣的、有巨大影响力的方面,可以更有效率地做出优秀的产品。

优秀的产品经理能激发工程师的能动性

在硅谷的很多顶尖科技公司,都是 “工程师导向”的文化,也就要求产品经理不能像监工一样告诉工程师应该做什么。如果产品经理对工程师指手画脚,那工程师会顿时失去工作的兴趣,吵着嚷着要换组、换产品经理。

但是,一个真正优秀的产品经理能够让工程师兴奋起来,满腔热情地投入到产品开发中;而这种热情一旦被激发出来,产品经理就再也不用担心工程师会拖延工期、消极怠工,相反工程师甚至会比你更积极。

那怎么才能激发工程师的能动性呢?我至少和百位不同背景、不同资历的工程师工作过,在无数次“踩坑”后,我总结了下面的这些建议。

第一,作为产品经理,你应该知道这个工程师在乎的是什么。

他是一个刚毕业不久、满腔激情、想赶快升职加薪的工程师?还是一个想解决最高难度的技术问题,哪怕产品没人用,只要解决的问题难度足够高就高兴的工程师?还是一个满肚子主意,极其讨厌产品经理告诉他该做什么的“点子大王”?还是一个有些害羞、很多想法都憋在心里,但其实特别希望自己有存在感的人?

知道了他在乎什么,你才能知道怎么激发他的能动性,以及该让什么人做什么样的项目。

知道工程师要什么,想办法在现有的项目里给他们相应的机会,会让你们之间的合作事半功倍。 至于怎么知道工程师要什么,你不如和他约个时间喝杯咖啡私聊一下,了解他的个人情况,你甚至可以直接问他:“你是如何决定自己做的事情有没有价值的,你在乎的是什么?”

第二,产品经理应该知道怎么和工程师沟通最有效率。

很多工程师最讨厌的就是开会,因为30分钟的会议打断了他们的思考时间,拖慢了他们写代码的进度。

所以作为产品经理,虽然你每天要花很多时间在开会上,但是要考虑一下这个会到底有没有必要让工程师参加,可不可以安排到这个工程师其他会议之前或者之后的时间, 这样尽量少地打断他们的思考,以便于他们有效率地编程。

你还需要思考,除了开会之外,还有没有其他可以高效做决定的方式,比如发个邮件。

第三,产品经理要弄清楚什么决定需要自己领导大家做,什么决定可以放心地交给工程师们自己做。

比如,某个按钮是100像素还是120像素,类似这样的决定,是不是可以让工程师和设计师自己决定?

很多产品经理常犯的错误是,自己做出所有的决定,和工程师交流时只是要求他们按照指定要求来做,但实际上有些要求根本就不切实际。 更或者,按钮是100像素还是120像素,可能对于产品的成败来说,并不是最重要的决定, 你完全没必要在这种决定上花时间。

还有些产品经理只告诉工程师要做什么,从来不解释产品的目的、成功的标准,工程师完全不知道这些决定背后的策略和思考过程, 结果就是事事都需要产品经理告诉他们要怎么做。

其实,一个好的产品经理一定会清晰表达产品要解决的问题、如何衡量成功、需要最先解决的用例以及原因,让产品团队的工程师、设计师、数据科学家等都有足够的背景信息。 这样,很多的小决定完全可以让团队成员自己做,从而既可以大大提高产品效率,又可以提高团队成员的能动性。

当然,这并不是说产品经理什么决定也不用做,一个优秀的产品经理,会确保自己的时间花在“非我不可”的事情上,其他决定都会交给他人。设想, 如果一个产品经理把每天的时间都花在解决按钮是100像素还是120像素这种问题上,他们哪还有时间去和客户做一对一交流、制定产品战略、思考“脑洞大开”的新功能。

第四,产品经理应该帮助工程师解决开发过程中的一些困难。

很多工程师在开发过程中会遇到一些困难,比如因为其他组工程师进展缓慢而导致开发工作停滞,因为开发的新功能被律师认为风险太大而面临一些质疑,等等。因此,产品经理应该积极询问工程师:“你需不需要我为你提供一些帮助”,帮助工程师解决开发过程中遇到的障碍。

因此,帮助工程师扫清开发路上的各种障碍,可以提升你的产品开发效率,而这正是优秀的产品经理需要做的事情。 比如,我常常对工程师说:“现在有哪些工作是你不喜欢做的,告诉我,无论是脏活累活,我来帮你做”。其实,这也是一个帮助你和工程师建立信任关系的过程。

怎么催工程师加快进度?

这个问题是很多刚入行的产品经理最担心的,我的建议是,让工程师先自己估计需要的工期,然后再设定截止日期。如果他们预估的工期太长,我可能会提出一些问题,弄清楚为什么需要这么长时间,看看哪些部分可以砍掉,到底值不值得为截止日期砍掉这些功能。

工程师估计完自己需要的时间后,我会和工程师说明我们的发布计划, 比如某月某日营销团队会开始宣传产品功能、 某月某日我们需要开始运营工作等等,这样可以让工程师了解其他部门的进度,增强他们的归属感。

刚入行不久的工程师估计工期的能力比较差,如果他们的工期估计得太长,我就会想方设法让他们告诉我工期是怎么估计出来的,然后跟他一起讨论,哪些部分可以用现成的API,哪些部分可以少花一些时间。

如果遇到确实要将截止日期提前的情况,我会告诉工程师需要提前的详细原因。这样做的目的是,让工程师觉得你和他是一起的,让他感觉到你的信任、你在思考如何一起解决工期提前的问题。

所以,我一般不会直接说要花多长时间,而是让工程师先估计工期,如果我觉得估计得过长,我会诚恳地告诉他我们需要加快进度,看看有没有什么方式能够重新组合一些计划,以加快工期。

在这里,一定要让工程师觉得自己是有掌控权的,而不是产品经理一拍脑袋,就决定个截止日期。 就算这个截止日期是你自己拍脑袋决定或者老板要求的,在表达日期的时候也要尽量体现出对工程师的尊重,用问问题的形式表达自己的看法,积极地和工程师一起寻求提前工期的方式。

产品经理常见的棘手问题:需要改需求怎么办?

改产品需求是一个非常常见的过程,有些时候前期计划做得很好,开始Beta测试时却发现,用户对某个功能根本不理解,还是需要改动。

其实,开发本来就是一个不断迭代的过程,所以应该首先认识到,产品开发不是产品经理闷头花几个星期写一个文档, 然后再抛给工程师让他们按照这个文档执行的过程。

但是,改需求并不代表产品经理可以在产品需求文档上胡写乱写,做出一些不靠谱的决定,这是在浪费工程师的时间。这里我就跟你说说有哪些方式能够避免在开发后期改需求,如果真的要改需求,如何和工程师有效沟通。

  1. 尽早和工程师进行产品功能设计的讨论,让他们提前了解各种背景信息。我平时的工作方式是,先在产品需求文档中写明需要解决的问题、如何判断成功,并写几个产品方案的初稿,和工程师、设计师们进行讨论,回答他们的问题,让他们一开始就参与进来。通过这个讨论过程,我可以知道有什么技术上的局限性,然后根据大家的反馈修改产品需求文档。这样可以避免在工程师花费大量时间后才发现问题,然后重新来过,导致工程师做无用功。
  2. 如果确实需要让工程师们重新写已经写好的东西, 或者砍掉他们已经写好的东西,一定要积极承担责任。 这种情况,可能是因为你作为产品经理少考虑了某些情况,也可能是突然发生了一些变故,比如公司改变了策略、竞争对手突然“搞事情”。虽然这并不一定是你的责任,但是这时你还是应该积极和工程师交流,主动承担责任,告诉他们:“这个赖我,辛苦你了”。

其实很多时候,就算产品经理自己主动承担责任,工程师也不会“顺杆爬”埋怨你,他们反而觉得你是个靠得住的好产品经理,甚至会过来安慰你。

积极承担责任,说句“抱歉,辛苦了”,虽然对你来说就是一句话的事儿,但这可以很好地安抚已经努力工作了一个月、每天加班加点儿的工程师。很多时候,给工程师们一些鼓励和温暖,虽然看上去微不足道,但却能让他们干劲儿百倍,对你死心塌地。

总结

最后,我来给你提炼一下今天的要点。

要做到和工程师的有效沟通,你作为产品经理需要做到:第一,知道这个工程师在乎的是什么;第二,知道怎么和工程师沟通最有效率;第三,弄清楚什么决定需要自己领导大家做,什么决定可以放心地交给工程师们做;第四,帮助工程师解决开发过程中遇到的困难。

接下来,我还跟你分享了怎么催工程师加快进度,以及怎么处理改产品需求这种常见的棘手问题,归纳起来不外乎这几点:第一,尽早和工程师进行产品功能设计的讨论,让他们提前了解各种背景信息;第二,积极承担责任,把过错往自己的身上揽,而不要抛给工程师;第三,要让工程师觉得自己是有掌控权的,而不是产品经理一拍脑袋就决定了截止日期和产品的需求。

思考题

  1. 你的一个工程师平日少言寡语,从不会主动表达自己的想法,会议的时候也不怎么发言,但是你在产品开发的过程中发现,他并不完全同意大家的决定,所以也不能很顺畅地执行,那么你作为产品经理应该怎么做?
  2. 你的一个产品功能,因为测试的体验太差,有被砍掉的风险,而这个主意是你自己提出来的,你会怎么和工程师沟通这个糟糕的结果?
  3. 你的一个工程师鄙视你没有工程背景,在做决定的时候并不信任你提出的建议,你该怎么取得他的信任?

欢迎你给我留言。