产品经理面试时如何考察技术素质

　　产品经理的基本定位，高巍认为是客户/用户/市场需求在企业的“内部代言人”，在企业中扮演了一个类似“甲方”角色。

　　对大公司，如果同时设置了项目经理(Project Manager/Project Leader)，关系就比较容易理顺，由他代表技术团队和产品经理进行沟通协调，他要懂技术，要理解技术团队做的技术决策和方案，能明确指出需求不可实现或实现很困难等关键点，加以说明和解释。

　　对小公司，职责划分都不是那么鲜明，产品经理常常兼着项目经理的部分职责，所以对产品经理的技术素质也有一定要求。

　　产品经理和技术团队最常见的冲突情境是，产品经理提出一项需求，但技术团队评估后表示实现代价比较大;而产品经理又觉得这个需求很重要，对用户价值和用户利益很大，坚持应该实现。

　　如果产品经理具备一定技术素质，可以与技术团队进行沟通和对话，请技术团队提出实现困难在什么关键环节。产品经理一旦理解了瓶颈所在，综合权衡后对原来需求做出调整、折衷，就可能达到一个双赢解决方案。

　　可能更重要的是考察产品经理的“功夫在诗外”的那些素质，如在大局观、整体意识下的沟通、体谅、甚至妥协，如Sympathy同理心，除了能从自己的角度和层次考虑问题，还能设身处地为其他成员考虑问题。

　　---------------------------------------------------------------

　　作者： 挑灯看剑(http://www.douban.com/people/flycondor/)

　　原文： http://www.douban.com/note/77760672/
　　豆瓣有个交叉面试的惯例，目前主要是在产品经理和工程师两个团队之间。 作为技术团队的代表，我经常和来应聘的产品经理聊聊，从以下两个方面给产品经理团队参考意见：

　　1、 面试者是否有足够的技术素质

　　2、 面试者是否具备和工程师协同工作的能力

　　第1点，假设是： 在一个以快速变化的技术为生产力的行业，如果技术方面的素质太差，能力会大受限制。

　　第2点，假设是： 工程师有独特的个性需要尊重和理解，产品经理如果了解不够，会增加很多工作中的障碍，甚至摩擦。

　　相对来说，第2点是比较容易考察的，从主观和客观两个角度来看即可。 主观方面，看他对合作过的工程师的看法、期望、评价。 客观方面，看他和工程师合作的细节，如流程、工具、交付物、解决争端的方法。

　　比较难的是第1点，很长时间我一直拿不准分寸。工程师们不愿意和完全不懂技术、不理解技术开发的规律、听不明白技术问题、会做出违反技术原则的产品决策的产品经理合作，但是怎么能在短短的面试中发现这些潜在的问题呢? 总不能要求人家会编程序吧!

　　在经历了若干次交叉面试之后，思路有点清晰了，大概应该从两个角度来看：

　　1、 好奇心： 平时是否关注技术发展，是否有从技术角度想问题的习惯

　　2、 理解力： 遇到一个全新的技术，能否快速理解，并说出它的优势、局限性、可能的用途

　　前者，可以用一些没有标准答案的开放性问题入手，看看他的思路会发散到什么方向去，有些人习惯于想到技术因素、领域，有些人总是回避技术，差别很明显。

　　后者，可以现场给他讲解一种算法、一个新出现的技术、一门新的编程语言、一种技术开发过程的常见问题，看他能理解到什么程度。

　　还是不完美，好在交叉面试只是提供参考意见，不是决定性的意见，我的压力没有面试工程师那么大。

　　---------------------------------------------------------------

　　豆瓣上另一位网友“无锋之刃(http://www.douban.com/people/bluntblade/)”的意见也值得参考：

　　Information Technology，这两个单词其实早已清晰地划分了产品经理与项目经理的定位与职责。如下图：

　　1. 产生需求 -> 2. 收集需求 -> 3. 分析需求 -> 4. 整合需求 -> 5. 实现需求 -> 6. 解决/满足需求

　　2、3、4这三步，需求主要表现为“Information”，那么作为与市场直接接触的前端，产品经理的定位和职责自然放在收集、分析和整合需求之上，所有工作内容均围绕这些活动展开。亦即，根据4W1H理论，产品经理首要处理“What”、“Why”和“When”三个问题。就这点来看，产品经理要解决工作中的问题，通常会使用非IT领域的技术工具，如统计、分析甚至策划、营销等。除了使用工具以外，产品经理还需要具备需求敏感能力、市场理解/沟通能力。这些都属于非IT技术领域的能力。由于专业性要求，在上述能力基础上同时要求产品经理很懂IT技术，跟得上技术的日新月异，确实是有点为难。

　　再来看项目经理。这一角色主要处理5和6两步，将需求转化为技术实现，以“Technology”的形式进行表述，最终满足市场需求。同样根据4W1H理解，这是在处理“Where”和“How”的问题。此时项目经理(及其代表的技术团队)侧重点会放在设计方案、实现功能、满足性能指标、验证需求是否满足。众所周知，IT技术，尤其是软件技术，发展速度和更新周期一直在不停地提升和缩短，跟得上变化已属高难，更别奢谈使用新技术正确地实现和解决需求。要求项目经理和技术团队去理解自身工作范畴以外的事情、具备相应的应对能力，同样是为难。

　　换句话说，由于工作内容和性质的不同，要让产品经理(代表市场团队)和项目经理(代表研发团队)真正做到完全地相互理解彼此的意图和想法，其实是相当困难的。作为需求从“Information”转变到“Technology”的关键环节，这两种角色不能轻视更不能忽略。在条件许可时，还是尽量把两者沿定位边界分开，有关联(信息交互)更有侧重(专业性)。而侧重不是最关键的，最关键的是关联，做不到这一点，前后端便不能高效地相互配合，最终很可能导致产品/项目的失败。

　　所以，在我的理解中，不管是产品经理也好，项目经理也好，除了具备专业领域内的能力，还应该具备一些非专业领域内的能力，重点有：沟通能力、理解能力、谈判能力、决策能力和妥协能力，以及好奇心(这一点同楼主)。这些能力保证了两者工作成果的关联性。

　　开发过(不止一个)中等规模系统的开发人员都知道，其实系统里最容易出问题的地方就是信息(数据)进行转换的地方，如从DBMS到业务逻辑层，再从业务逻辑层到内容表现层。同理可证，需求从“Information”转变到“Technology”，这种变化更需要接口进行严密的匹配。也就是说，产品经理和项目经理要能严密地匹配。而这匹配更多地由非专业技术能力来保证的，最少，也要有充分可用的沟通能力和理解能力，否则就是浪费时间和资源。将技术和能力排布在X轴，水平高低排布在Y轴，那么理想的经理们应该都是三角形分布，而不是T形分布。T形分布更适合专业人员，比如开发者。而作为系统接口的经理们，则应该是三角形分布。他们必须利用这种广泛而有相当深入程度的信息与知识来保证沟通是充分的、有效的，理解是能相互表述的，要知道前后端都在做什么事情，这些事情是如何解决需求问题的，从而实现工作成果的关联性。