如何与不同类型的技术人员沟通-摘抄

如何与不同类型的技术人员沟通

发表时间：2010-3-11 1:16:22  发表者：罗旋




产品经理如何与不同类型的技术人员沟通


【摘要】产品经理在日常的工作中，我个人认为，接触最多的就应该是技术团队的同事了，大到新产品需求的商讨，小到一个产品bug的提交，每天至少要花40%以上的时间在这个方面，尤其是到了产品研发阶段，花的时间就更多了。

大家都说做技术的人虽然执着但是产品视野不够宽广，精于技术但是对市场不够敏感，尤其是在打交道的时候，总是在这方面发生争执。

那么，技术团队的同事都有什么样的特点呢？我们应该如何进行沟通才最有效呢？

我总结了一些个人的体会，和各位朋友交流一下。

1、闷头干活型：

先看一个案例：

PM：这是用户提出的要修改的一个地方，你看能做吗？

Looking……

程序员：能做！

PM：今天下班前能完成吗？

程序员：能！

PM：不影响现在的项目吧？

程序员：没事，我加班做吧！

……

然后开始做，再不多说一句话，即使下班前没做完，也会真的去加班赶工。

这就是典型的“蒙头干活型”的技术人员，这类技术人员最大的一个特点就是“一切按照安排做，几乎不发表个人意见”。

其实遇到这样的技术人员，对于产品经理来说，是比较幸运的，因为这样的技术人员从项目管理的角度来说，就意味着“放心”，第一，他们一切按照公司安排来进行工作，第二，他们会努力按照要求的时间完成工作，即使加班加点也要完成。

这点是产品经理最愿意看到的，在产品团队里，多几个这样的技术人员，通常就决定了产品项目周期是否能按时完成。

但是，从另一方面来说，这样的技术人员也存在一个严重的问题：就是足够努力，但是不够灵活。

对安排下来的工作，没得说，肯定按照要求按时按质完成，但是很少能从整体去合理安排自己的时间，毕竟产品经理不了解你手中的工作进展是怎样的，突然临时给你加了一个活，也不重新评估一下个人项目时间，或者是知道对现有项目会有影响，但是憋在心里不说，直到最后影响到现有项目了，只能自己一个人去加班加点去做，想想，也挺难为这些同事的了。

作为产品经理，如果遇到这种类型的技术人员，需要用“抛砖引玉”的方式来确定他的工作时间，例如可以这样问：

PM：这是用户提出的要修改的一个地方，你看能做吗？

Looking……

程序员：能做！

PM：你现在手里还有什么项目吗？

程序员：有XXXX，XXXX！

PM：是比较着急的项目吗？

程序员：XXXX要求明天下班之前完成的。

PM：你估计我现在给你的这个活需要花多长时间呢？

程序员：我估计怎么也得半天吧。

PM：这样吧，这个活先放到你这里，我去和你们的经理协调一下，然后再通知你，怎么样？

程序员：行！

……

刚才说到了，这类技术人员的特点就是“一切按照安排做，几乎不发表个人意见”，也就是说无论是产品经理安排的，还是部门经理安排的，或者是其他人安排的，只要是涉及到技术方面的工作，他都会无一例外的重视，而这种重视很大成份上是无原则的，即没有项目级别的思想，安排什么，马上做什么，好的说是 “负责”，不好的说是“死板”。

因此，建议通过引导的方式来确认项目的时间安排，这是因为他们不一定没有想法，或许是有想法但是不愿表露，也许是性格决定的，也许是职业压力决定的，但无论怎样，一定要让他们说出来。

这种类型存在于两类技术人员中：第一是参加工作时间不长的；二就是完全性格内向的。

2、技术痴狂型：

先看一个案例：

PM：这是用户提出的要修改的一个地方，你看能做吗？

Looking……

程序员：我觉的这个地方有些问题呀？

PM：哪里有问题？

程序员：你看，这个地方我觉的这样做不合适，应该……

开始讲解他认为最好的方法。

PM：那如果按照你认为的方法做的话，需要多长时间呢？

程序员：我也说不好，这种方法我没用过，不过我可以试一下，这样吧，等做完了，我通知你吧！

PM：……

这是典型的技术人员，这种类型的技术人员天生就是做技术的料，他们对于解决问题所涉及到的技术的痴迷要远远大于项目、产品、市场本身。

他们可以花一个晚上的时间去研究如何解决一个问题，他们喜欢在技术上的挑战，喜欢采用自己在理论证实可行的方法来实践，但是恰恰忽略了他们做的是产品，是要用来为公司盈利的商品，产品是不过是提升他们实力，验证他们技术理论的平台而已。

他们始终追求的是“最好”，而不是“最合适”。

可惜中国大部分的IT企业不是微软，不是google，在微软和google有专门的部门来负责新技术的研发，也就是实验室，而大部分的技术人员还是需要按部就班的去按照公司计划去执行开发任务。

这类技术人员其实就是没有给自己一个很好的定位和角色调整。

在公司，你就是程序员，就是按照公司计划和安排去做技术工作，在工作之余，你花多少时间去研究新技术，新应用，都是可以的。但是一定要知道角色的转换，每天早上打完卡，你首要考虑的就是“我今天要做PRD中的那个功能？还有多长时间项目结束？”，而不是去用连自己都不确定的思路去做项目。

因此，对于这种类型的技术人员，应该用“借刀杀人”的方式来让他按照时间安排来做。

例如可以这样说：

PM：这是用户提出的要修改的一个地方，你看能做吗？

Looking……

程序员：我觉的这个地方有些问题呀？

PM：哪里有问题？

程序员：你看，这个地方我觉的这样做不合适，应该……

开始讲解他认为最好的方法。

PM：那如果按照你认为的方法做的话，需要多长时间呢？

程序员：我也说不好，这种方法我没用过，不过我可以试一下，这样吧，等做完了，我通知你吧！

PM：这个问题是用户非常急迫要求修改的，我必须知道一个确切的时间，否则无法向用户说明。

程序员沉思中

程序员：好吧，其实有种方法也可以实现，今天下班前我尽力做完，做完了，我通知你。

……

对于一个公司来说，天大地大，用户最大，在公司内的任何一个人，都不敢不把用户的要求放在次要位置的，一旦遇到这种情况，你用用户来胁迫，十有九个会就范的。

3、好为人师型：

先看一个案例：

PM：这是用户提出的要修改的一个地方，你看能做吗？

Looking……

程序员：这个问题是什么用户提的呀？

PM：是咱们的一个XXXX用户提得。

程序员：靠，我看这用户什么也不懂，这也能叫做问题！

PM迷茫中。

程序员：你看，用户之所以出现这个问题，是因为……

大概讲了几十分钟后，看着PM，带着满足的眼光问道：你知道了吧，这都是用户太笨，不懂计算机，你去和他们说一下，这种问题就不用改了。如果还有不清楚的，可以来问我，以后不要什么问题都改，我那有那么多时间。

PM彻底晕倒。

这类技术人员最大的特点就是认为“从我手里出来的产品就是最好的，不会用那是因为你笨，而不是我笨”。

因此，这类技术人员在遇到这种情况的时候，通常立刻转化角色，把自己当成一个诲人不倦的老师，一步一步地告诉你应该怎样去做，然后让你去告诉用户应该如何去做。

说实话，这类技术人员不去做客服真的是浪费了，这种耐心简直让人佩服万分，可惜的是，有剖析用户问题，嘲笑用户使用技能，教授如何使用的时间，我想也应该把要修改的问题做完了吧。

因此，对于这类技术人员，要采用“欲擒故纵”的方式来让他认清自己应该做什么。

可以这样去说：

PM：这是用户提出的要修改的一个地方，你看能做吗？

Looking……

程序员：这个问题是什么用户提的呀？

PM：是咱们的一个XXXX用户提得。

程序员：靠，我看这用户什么也不懂，这也能叫做问题！

PM不做回答，故做迷茫，听他解释。

PM：你看，用户之所以出现这个问题，是因为……

大概讲了几十分钟后，看着PM，带着满足的眼光问道：你知道了吧，这都是用户太笨，不懂计算机，你去和他们说一下，这种问题就不用改了。如果还有不清楚的，可以来问我，以后不要什么问题都改，我那有那么多时间。

PM：是呀，是呀，我也知道这些都是小问题，好多都是用户使用不当造成的，这样吧，我就按照你的建议去和用户说清楚，希望能有帮助吧，不过这个单子市场已经下了，我就按照你的建议去和他们说，要是再有用户问，我就让市场的人直接找你了，行吗？

程序员思考中……

程序员：你先把单子留下吧，我再看看，和我们经理商量一下，一会通知你。

……

在这个以营销为主，客户为上帝的环境中，谁都知道，把你直接推到用户面前，都是对自身的一种考验，之所以他们能给你滔滔不绝的讲一堆东西，讽刺用户的使用技能不足，那是因为他们不用直接面对用户，因此才敢口无遮拦，并且他们也知道，你是PM，你就是他们和用户之间的防火墙，有什么话他们敢说，你 PM就不敢说，因此，一旦遇到这种情况，最好的方法就是看似尊重他们的意见，实则把自己这道防火墙关掉，直接让他们和用户面对面，我相信，这个时候，他们就得考虑一下，能否真能应付这些在背后不知被嘲笑了多少次的用户了。

4、自以为是型：

先看案例：

PM：这是用户提出的要修改的一个地方，你看能做吗？

Looking……

程序员：这个问题是什么用户提的呀？

PM：是咱们的一个XXXX用户提得。

程序员：这都什么问题呀，一看就不是咱们的最终用户，不要管他！

PM迷茫中。

PM：那这个问题也的修改呀，要不如何向用户说明呢？

程序员：我知道，我会改的，不能什么都按照用户的要求来做！

PM：那你打算怎么改呢？

程序员：这个你不用管！

PM：那什么时候能改完呢？

程序员：改完了，我会通知你的。

PM极度郁闷中。

……

这类技术人员是极度的自以为是，在他们的眼里，产品只是由技术构成的，技术和产品之间是划等号的。

任何不懂技术的人，从本质上来说，就是不懂产品，因此，你们提出的所有关于产品的问题，都是外行提出的，都是不专业的，也都是不需要你们去了解的，你们要做的，就是告诉我问题，至于怎么改，什么时候改完，这些，我都不需要告诉你们，因为说了也是白说。

这里的“你们”，自然包括产品经理。

遇到这种类型的技术人员，产品经理就不好对付了，通常这类人多少是真有两把刷子的，并且经历的也多，公司也有一定的名气，有一些还是担任一定职务的，因此，像前面使用的三种方法在这里就都不太好用了，但是这种情况肯定会遇到的，那怎么办呢？

我个人的方法是：金蝉脱壳

可以这样说：

PM：这是用户提出的要修改的一个地方，你看能做吗？

Looking……

程序员：这个问题是什么用户提的呀？

PM：是咱们的一个XXXX用户提得。

程序员：这都什么问题呀，一看就不是咱们的最终用户，不要管他！

PM：那这个问题也的修改呀，要不如何向用户说明呢？

程序员：我知道，我会改的，不能什么都按照用户的要求来做！

PM：那你打算怎么改呢？

程序员：这个你不用管！

PM：那什么时候能改完呢？

程序员：改完了，我会通知你的。

PM：好的，不过我认为我还是需要知道这些情况的，毕竟也得和上面交待，是吧？我要是说清楚，上面就不是怪罪我一个人了，对不对，你还是给我一个明确的答复吧，否则，那我就只好实话实说了。并且会和你们的经理进行说明的，让他来协调吧！

程序员：随便！

然后去找他们的经理进行说明。

……

其实遇到这种情况，就我目前个人的能力来说，只能依靠上一级的力量来协调此事了，因为，这种类型的技术人员，第一，知道公司起重他，有恃无恐，第二，经历的可能比你还多，根本不在乎你的各种手段，第三，尤其是在一些技术起家的公司，技术部门普遍具有优越感，CEO是老大，我们就是老二。

因此，作为产品经理，完全没有必要去硬碰硬，可以把矛盾的主要方面转移成部门冲突，让上级领导去协调此事即可，不过，这个时候需要注意一点的是：一定要把握住冲突的主题，是因公而生的冲突，而不是个人冲突的升级。

如果说前三种情况中，遇到的技术人员还是容易沟通的，那么，第四种就很难沟通了，因为，在他们心目中，什么产品经理，不就是一个写文档的吗，懂什么技术呀，这种心中的地位落差就已经决定了你不可能和他们平等的对话。

最后做个小结：

第一种：蒙头干活型，采用“抛砖引玉”的方法；

第二种：技术痴狂型，采用“借刀杀人”的方法；

第三种：好为人师型，采用“欲擒故纵”的方法；

第四种：自以为是型，采用“金蝉脱壳”的方法。

其实在产品经理与技术人员打交道的经历中，远不止这四种类型，不过因为我个人经验有限，只能总结这么多出来，也不知道大家是否有同感，当然，大家可以都做一些总结，提供一些方法，这样，咱们多多交流，肯定能把工作做的更好。