博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
PM如何突破工程师心防
阅读量:6534 次
发布时间:2019-06-24

本文共 2189 字,大约阅读时间需要 7 分钟。

PM 常常遇到一个难题,就是有好多东西想要做,到无奈什麼事都得透过工程师,没办法自己动手,於是因为和工程师不太美好的关系,最后实际的產品都没有设计时看起来好。我这边讲的是「网路公司」的状态,PM 泛指那些规划出产品的人。其他产业也许也有类似情形,以下这些「教战手则」,提供给正在摸索自己生存之道的 PM 一些参考。

PM 如何突破工程師心防?

0、先弄清什么做得出来、什么做不出来:

常常有 PM 会提出一些天马行空的 idea,以致有时候让工程师觉得合作起来相当吃力。这是由于并不知道什么可以做什么不能做。以网站来说,这其实很容易知道,不需要太多的学习和知识。如果有一个功能,你在两、三个网站都看得到,99% 它是做得出来的。例如你想要有一个页面,填地址时选完「县市」,下一个选单就会载入你选的这个县市的行政区。如果你做些功课,就可以发现这样的表单在很多网站都出现过。那 99% 就是做得出来。如果你想出一种呈现的方式,从来没在任何地看过,那就比较有可能是做不出来的。在对工程师沟通时,假如你想做一个像这种选「县市」的下拉选单,你最好请工程师去看别人的那个网页,而不是用你自己的方式描述。工程师通常有不想输的性格,如果别的网站做得出来,他不会想要自己做不出来。

1、永远不要和工师辩论任何和技术有关的东西:

当 PM 能学一点点网页的概念是好的,但跟工程师合作,你可能常常会听到「这很难做」的 feedback。它可能代表几种不同的意思。可能代表真的很难做,也可能代表他不想帮你做。如果是第二种,有很多种方法可以让他妥协。但戳破他和找他辩论绝对是最差劲的方法。当他说这个技术上有困难时,绝对不要跟他说「这个只要… 就可以了呀!」这样也许让自己看起来比较聪明,但你们的关系已经完蛋了。而且工程师的性格容易有非常强的自尊心,所以千万别这么做。而且,technical 的领域,你可能永远也辩不赢他。很多「这个不能做」的问题,不是来自于理性,而是来自于不想、不愿意、觉得这个没意义、或真的很花时间。真的要做的话,99% 的东西大概都可以做。因此当这种看起来由 technical 角度来拒绝你的状况发生,如果你真的很想坚持你的想法做下去,请试著脱离 technical 的讨论,你该了解他所提出 technical 的障碍,但绝对不要和他在这个领域上辩论。因為你辩赢或输都没有任何好处。

2、工程师喜欢你去求他:

工程师很容易有某一种性格,是坐在那边希望大家都去拜拖他。所以你不难想像要让这种人帮你做事的方法就是你要放低你的姿态。你要让他觉得是你需要他,不是他一定要帮你。即使你心里一直想「公司付你钱来上班本来就是要做这些的…」放低姿态。也许身为 PM 的你,在每个 project 有进展的时候和卡住没进展的时刻,拿饮料点的 menu 去问工程师要喝什麼是个好方法。

3、把所有 credit 归给工程师:

在公司里,因為很多产品是由 PM 规划的。因此 project 的成功,大家很容易觉得是 PM 的功劳。请努力在任何公开的场合、email,把这些 credit 归给和你一起合作的工程师。同样一个 spec,一个心情好的工程师,可以把它做成 100 分。一个心情不好的工程师,可以把它做成 60 分。两个都可以 100% 符合你的 spec,但是一个可以烂到有无数问题。因為软体不是事前可以想清楚的。所以一个不开心的工程师,可以看到许多问题但「视而不见」,也不主动来跟你说,那你就完了。所以一定要让全公司的人都觉得这些成就属於工程师的。你把 credit 拿走一次,下一次你就完了,因為没有人想為你卖命了。

4、不要轻视「工程师的 project」

你合作的工程师可能说他现很忙,因为他正在「重写一些 function」或是「让资料库的速度快一点点」。很多 PM 在听到这些的时候,并没有很知道他们在做什么,於是表现出来的会是对这些 project 没那麼在乎或甚至不觉得他们重要。通常工程师最喜欢做这种隐性的 project。因為他们可以不用听 PM 的指挥。对於一个健康的公司来说,一定会有一定比例的资源投在这些 project。要不要做通常是由老板,或更懂得这些东西的人来决定。但你一定要在工程师的面前让大家觉得你看起来对这些非常认同。

5、姿态放软,但不能失去主导权

虽然前面说你姿态要软,但你绝对不能把你的 project 交给工程师后,你就失去了主导权。因为这样会让你在老板面前,看起来变得没有太多价值。你最少要继续掌握你 project 的「时程」和「内容」。也就是你一定要维持你的「主导权」,对该坚持的东西继续坚持,对一些东西妥协,但不能全交给工程师决定。

6、不要 finalize 所有设计后,再交给工程师

绝大多数的工程师对这样的流程很反感,所以请想办法在设计阶段,就去请教一下工程师的意见。他也许说他很忙,你想就好。即使只是得到这句话,都有很大的价值。这表示他放弃了他未来因为你在 project 早期没找他先过过,以致他责怪你的权利。

总之,因为工程师的心情很难捉摸。所以「情绪」的处理问题,可能比「技术」、「功能」上的讨论都更为重要。

来自:

转载于:https://www.cnblogs.com/yboy/archive/2012/04/16/2451302.html

你可能感兴趣的文章
git push被忽略的文件 处理
查看>>
C#中用ILMerge将所有引用的DLL打成一个DLL文件
查看>>
PHP生成HTML静态页面
查看>>
服务器启动django
查看>>
Makefile 中:= ?= += =的区别【转】
查看>>
使用makecontext实现用户线程【转】
查看>>
Comet:基于 HTTP 长连接的“服务器推”技术
查看>>
BZOJ 2733: [HNOI2012]永无乡 启发式合并treap
查看>>
四种方法校验数组中是否包含某个指定的字符串
查看>>
29、Java并发性和多线程-非阻塞算法
查看>>
安装OpenResty开发环境
查看>>
第0课 从0开始
查看>>
python class和class(object)用法区别
查看>>
hadoop无法启动DataNode问题
查看>>
java泛型中<?>和<T>区别
查看>>
这里是指推送通知跟NSNotification有区别:
查看>>
Linux中断(interrupt)子系统之一:中断系统基本原理【转】
查看>>
用户ID的代码生成
查看>>
win7经常出现“关闭xxxx前您必须关闭所有会话框”
查看>>
SNMP安全配置的两种方法(也可同一时候兼顾配置两种方法)
查看>>