简介

珍妮尔兴奋极了。 她即将与老板金女士进行一年一度的绩效面谈（1:1会议），而她坚信这次谈话会非常顺利。就在去年这个时候，她在上一次绩效评估中告诉金女士，自己希望成为一名高级软件工程师。金女士当时的回应是：“很好啊！只要证明你具备高级软件工程师应有的能力，我就准备提拔你。”

于是，去年她与市场部合作解决了他们网站的诸多问题（那些烦人的CSS问题），六个月前还编写了一段Ruby脚本，帮助团队轻松地将新版本发布到公司仅存的几个本地部署服务上。此外，在过去四个月里，她还指导了团队的新成员迈克尔，协助他完成了几项任务。总体而言，她觉得自己正在做着自己观察到其他高级软件工程师常做的事，因此对本季度的表现感到相当满意。

金女士一如既往地迟到了几分钟。“嗨，珍妮尔，抱歉来晚了，你知道的，总是这样。” 珍妮尔点点头，还没来得及回应，金女士便继续说道：“既然这次1:1是绩效回顾，我想先告诉你，我跟丹聊过——他是我的上级，也是你的跨级主管——我们一致认为，你本季度的表现平平。我们原本期待你能展现出更多超出当前水平的能力。”

珍妮尔顿时感觉所有的热情都瞬间被抽空。她的表情一定出卖了内心，因为金女士略带疲惫地笑了笑：“我们依然喜欢你，珍妮尔，当然不会开除你。只是……我知道你非常渴望晋升为高级工程师，但目前来看，你还没有达到我们对高级工程师应有的标准。”

珍妮尔摇了摇头：“我不明白。我指导过迈克尔，和市场部协作过，还写了发布脚本……这些不都是我经常看到同组的高级工程师古拉夫在做的事吗？”

金女士叹了口气：“是的，但这些并不是我们真正期望高级工程师去做的事情。我们需要高级软件工程师成为技术决策者，而你并没有主动去学习我们正在探索的新技术。此外，我们特别需要团队中的高级工程师更积极地参与项目干系人沟通、主持演示等事务。你现在明白了吗？”

不， 珍妮尔心想，但这有什么区别呢？

许多，甚至大多数软件开发者都曾经历过珍妮尔这样的处境。他们自认为清楚晋升的路径——那些被明示或暗示需要完成的任务——却在绩效评估时发现，真正决定晋升的并非这些事。这本质上和“范围蔓延”一样：你以为终点线在这里，结果却发现它其实在那边。而且，你还得在改变方向的同时，穿过一堆意想不到的障碍。

说它令人沮丧，简直轻描淡写了。

用敏捷开发的角度来理解这个问题。我们之所以采用迭代和冲刺模式，核心目的就是获取频繁的客户反馈。一些敏捷方法甚至主张每个冲刺结束时都要“交付”成果，哪怕第一个冲刺也不例外。每个冲刺开始前，我们会规划要交付的内容，以便在冲刺结束时向客户展示成果，并获得他们的认可。如果客户总是在冲刺结束时突然改口说“我之前的意思不是这个”……那恐怕没人会惊讶于这个团队最终纷纷另谋出路。

而这正是员工面对珍妮尔这种境况时的真实反应。

避免这种情况的关键，和冲刺流程一样：设定清晰的目标，反复迭代调整，并通过数据点和其他证据来验证或否定成果是否达成目标。在本章中，我们将探讨“设定清晰期望”究竟意味着什么。特别是，我们需要努力制定出明确、相对客观的期望，同时保留一定的灵活性。

理想的目标： 讽刺的是，“期望”这个词并不适合我们这里所讨论的内容。大多数词典对“期望”的定义都带有强烈的“预期”意味——即当某人“期望”某事发生时，通常意味着这件事大概率会发生。相比之下，“目标”或“指标”这类词汇可能更贴切。但不知为何，人力资源领域偏偏选择了“期望”这个词。