如何与不同类型的技术人员沟通
http://luoxuan.cto.csdn.net/Article.aspx?Name=luoxuan&pointid=2499
产品经理如何与不同类型的技术人员沟通
【摘要】产品经理在日常的工作中，我个人认为，接触最多的就应该是技术团队的同事了，大到新产品需求的商讨，小到一个产品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是老大，我们就是老二。
因此，作为产品经理，完全没有必要去硬碰硬，可以把矛盾的主要方面转移成部门冲突，让上级领导去协调此事即可，不过，这个时候需要注意一点的是： 一定要把握住冲突的主题，是因公而生的冲突，而不是个人冲突的升级。
如果说前三种情况中，遇到的技术人员还是容易沟通的，那么，第四种就很难沟通了，因为，在他们心目中，什么产品经理，不就是一个写文档的吗，懂什 么技术呀，这种心中的地位落差就已经决定了你不可能和他们平等的对话。
最后做个小结：
第一种：蒙头干活型，采用“抛砖引玉”的方法；
第二种：技术痴狂型，采用“借刀杀人”的方法；
第三种：好为人师型，采用“欲擒故纵”的方法；
第四种：自以为是型，采用“金蝉脱壳”的方法。
其实在产品经理与技术人员打交道的经历中，远不止这四种类型，不过因为我个人经验有限，只能总结这么多出来，也不知道大家是否有同感，当然，大家 可以都做一些总结，提供一些方法，这样，咱们多多交流，肯定能把工作做的更好。