以下是Steve面试问题的整理。

Steve：“你好，很高兴认识你。请先介绍一下你的工作经历和教育背景吧。”

Steve：“你刚才提到的那个任务，我想详细了解一下你具体都做了什么，有什么量化的结果。”

Steve：“在这份工作中，你认为做的最好的是什么？”

Steve：“你有没有做过什么项目，是你觉得最有挑战的？你是怎么做的，最后结果是什么？”

Steve：“你的工作经历中，A项现在的这个岗位不涉及，你能跟我说一下B项你具体是怎么做的么？”

Steve：“你觉得，你对原来的公司最大的贡献是什么？”

Steve：“如果让你来做这个岗位，你会怎么做？”

Steve：“你对我有什么问题吗？”

Anna：“之前关于这个岗位的工作任务，没有说的很具体，猎头说您了解具体情况，可以跟我说明一下吗？”

Steve：“这个问题没有说明吗？我只能告诉你我对整个营销部门的要求，具体这个岗位要问营销总监。” 

Steve并不知道这个岗位的具体工作内容，自然也就不可能清楚这个岗位的胜任力要求。在不知道做什么的情况下，他反复问Anna的三个问题——“做过什么”“怎么做的”“结果如何”——跟这个岗位的工作目标如何关联呢？

我们之前谈到过目标驱动度量管理，从今天起，我要陆续开始谈另外一个观点：胜任力驱动的人员管理。

用大白话来说，所谓胜任力，就是用来描述“怎么才能干好活”。这一点，一直都是PM的心病。而根治它，除了要不断完善项目管理的能力外，还要不断加强团队人员执行项目过程的能力。因此，就算PM没有把“胜任力”挂在嘴边，也一直在项目中，践行着胜任力的相关实践。

 “胜任力”的概念，于1973年，由哈佛大学教授——戴维·麦克利兰（David McClelland）最早提出，是指能将某一工作中有卓越成就者与普通者区分开来的个人的深层次特征。它可以是动机😕、特质😟、自我形象😣、态度或价值观😖、某领域知识、认知或行为技能😫等，任何可以被可靠测量📐或计数🔢的，并且能显著区分优秀与一般绩效的个体特征。🙄🙄🙄🙄🙄

嗯🤔……大师提到的这些，确实会对胜任力有影响。可作为PM，满心满眼的只有按时结项，什么动机啊，价值观啊，自我形象啊，根本就顾不上。如此构建项目团队的胜任力，还不如省下时间做做项目。那么对PM来说，有没有更具操作性的胜任力呢？

当然！

胜任力= 知识 + 技能 + 过程能力

知识是指成功完成工作所必须具备的信息和理解

技能是指为了达成工作所要执行的行为

过程能力是指执行工作过程的能力，即在组织的协作活动中，以特定的次序或方法运用知识和技能的能力

Fancier凡奉信息版权所有

描述不同的胜任力的颗粒度不尽相同，但这样的胜任力，就是将大师定义中，除了知识、技能外的其他部分，全部以工作过程为落脚点，让胜任力直接服务于工作过程。

在招聘、团队组建和职业发展等过程中，PM的惯性思维是关注技能（顺便也包含知识），但却往往忽视了过程能力这个部分。

前面例子中的Steve，尽管已经从CTO变成了CEO，还是在面试的时候，专注于通过“怎么做的”和“结果如何”，来判断和验证Anna的“技术”水平。其实在Steve心中，对胜任力是有模糊概念的。他的面试问题的出发点，无非是希望在Anna的过往工作经验中，找到与招聘岗位之间的共通点。由于缺乏对共通点的明确定义，也就惯性地将面试焦点集中在了技能层面，而没有着重评判Anna是否能胜任这个岗位的工作过程。

Steve的面试思路，也是很多PM在进行人员配置时的惯性思路。做过什么项目啊？运用过那些技术啊？解决过什么难题啊？……这样的思路，如果用在常规的、成熟的项目上，看不出什么大毛病，可一旦遇到全新、创新的项目，而团队人员又不见得有过类似经验时，就不好使了。

软件开发，是个关联性极强的系统化的过程。无论是老项目还是新项目，开发这个过程本身才是核心。我们对软件开发进行管理，期望的是整个工作过程的性能越来越高；但是，却忽视了理想中设计的过程，与现实中执行的过程之间的差距。因此，在胜任力的概念中，明确提出过程能力，就是从人的层面，深化过程性能的改善，填补这个漏洞。

一旦，通过对过程的分析，清晰的定义了人员的胜任力后，你就会发现，哪些人小材大用，需要发展胜任力；哪些人大材小用，需要调整工作安排。以胜任力为依据，调整团队的人员配置，不仅能改善项目的完成情况，还能合理化项目的人力成本。为PM控制项目的质量、成本和进度，提供有力的抓手。