4月26日，在
KnowledgeConf 2019会议上，发表了“性能审查和秘密知识的识别”报告。 通常，我们谈论技术，但是，要发展成为一家公司，我们远远不能做到这一点。 专门针对工程师及其开发的演示文稿就是一个很好的例子。 如果您是团队负责人或考虑如何确保团队中员工的成长，那么本文（以及报告本身）可能会很有用。
按照传统，我们很高兴向您展示
报告的
视频 （50分钟，比文章多得多），下面是其文本形式的压缩内容，其中包含了报告本身未曾听到的一些细节。
为什么要进行绩效审查？
加入Flant之前，我是开发公司的CTO。 我希望团队发展壮大，能够解决越来越复杂的任务，并提高员工的技能。 为此，需要做两件事：
- 透明的增长规则。
- 反馈。
有必要制定一些规则，使员工可以在公司中发展，并有可能及时给他反馈，以帮助解决过程中的问题。
建立职业阶梯容易吗？
事实证明，没有。 即使您拥有较高级别员工的职位描述，也不能仅仅从中获取一组关键字，并说这些是提高您职业生涯的必要步骤。 如果您告诉员工：“学习Symfony 4，PostgreSQL和MySQL”，对他没有多大帮助。 不要教他
整个 MySQL！ 细节很重要，因此需要一些方法来衡量一个人的技能……类似
尺子 。
想象一下一个标尺，但是它不是分工，而是具有定性的技能水平，可以自然地加以区分。 如果我们有这样一条路线，我们可以将实际任务，真实经验和特定的培训材料与之联系在一起。 那呢
不幸的是，没有：在实践中，这样的界线实际上是“圣战”的一个单独主题，因为不可能精确地说出一个人是否知道如何实现复杂的业务逻辑。 但是有个好消息：在相同的实践中，
数学精度不是那么必要 。 您可以使用专家评估的方法：为最有经验和最沉迷于这种情况的员工提供机会，以决定是否属于技能水平，并以此为基础。
我们将不得不对准确性低，方法的中等可伸缩性以及其他方面视而不见，但是与此同时，我们可以承认这种方法可以很好地应对其任务。 不仅如此-到目前为止，它已在很多地方使用。 通常，团队领导者很可能会在自己的团队中扮演“专家”的角色，大约是。
反馈容易吗？
您需要定期（例如，每季度一次）与员工见面并提供反馈，这听起来合乎逻辑。 并尝试将其组织起来，以使过程充满意义，而不是一种货物崇拜。 将我们的“专长”与技能相结合似乎是一个好主意：
...从他们那里组织一个N维空间，并告诉该人他在该空间中的位置，然后就他将继续前进的位置达成协议：
N维空间很难想象，因此我们可以将表格用于这些目的。 行中将是我们的技能，列中将是我们的技能发展水平。 如果我们举行两次这样的会议，我们可以大致看到以下图片：
……这似乎会使我们相信所选择的路径和所选择的工具的真实性-毕竟，人们正在发展。 而且，当关键人数发生变化时，您可以提高员工的薪水并更改其职位的铭牌，例如，说他现在是中级PHP开发人员。
但是在实践中一切如何发生？
从理论上讲，这听起来很酷而且透明。 我尝试以这种形式启动该机制-坦率地说，它们并非如此。 我知道，我的同事在研讨会上的尝试也没有启发。 主要问题是：
- 并非所有员工对反馈的反应都一样好。 在缺乏权限的问题急剧出现的情况下，很容易发现自己，在这种情况下，很难进行专家评估。
- 在实践中，突出用于评估它们的关键技能实在是不平凡的故事-尤其是如果您是一个耕from的人。 很难忽略细节并在准确性和概括性之间取得平衡。
- 这种“反馈”和“阶梯”的存在与员工的动力无关 。 如果他们发展了，那就与该体系背道而驰了。
Flant的绩效考核需求
当我来到Flant时，发现了许多使我想到Performance Review的问题，即：
- 工程师对为什么要增长，应该朝哪个方向发展并不了解。 有时有人提出这个问题，但很少能获得明确的答案。
- 工程师没有感觉到公司的参与，也没有感觉到公司的回报及其对职业的参与。
- 公司开始积极发展，在这种情况下，特别有必要建立可理解的工作机制，以将新手转变为经验丰富的工程师和经理。
因此，我真的很想强调每个职位所需的技能，并为职业发展创造条件。
但是一切都不那么明显...
寻找技能清单
事实证明，没有人能够强调DevOps工程师的技能要求，并且通常都不能强调任何“技能水平”。 这个位置最接近的描述是在不朽的罗伯特·海因莱因中：
任何人都应该能够更换尿布，计划入侵，屠宰猪，建造建筑物，控制船，写十四行诗，记账，筑墙，设置骨头，编程计算机，美味地做饭，打得好，值得死。
也就是说，团队负责人期望并提升了他们作为全职工程师的能力，能够正确地找到有关任务的详细信息并解决所有技术问题，并将其投入生产。
当然，这启发了我。 在一家每个人都是通用战斗机，多才多艺的人和优秀的工程师的公司里工作真是太好了！ 只有一切都看起来像是一个
巨大的黑暗洞穴，上面藏着秘密知识，这才使人蒙上阴影。 我不想注定工程师去这样的旅行。
正如您可能已经猜到的那样，数十种具有数百种细微差别的技术已经面目全非。 我们不限制客户选择适合其应用的技术堆栈，因此我们的工程师面临各种各样的数据库，队列服务器，框架和语言，诊断，开发和调试工具以及不同数据中心和平台的功能。在过去的5年中，我目睹了一个根本性的变化：如果更早之前，技术总监说：“我们在带有数据库Y的X平台上工作，而我们将不做其他任何事情，那几乎被视为规范，”现在有些服务站甚至可以放手堆栈控制，依靠微服务和（
颇有争议的 ）口号：“如果中断，从头开始重写所有内容会更容易。”
在这种情况下，编制
用于评估员工的技术清单并不是一件容易的事。 并且使其保持最新状态太费力且难以组织。 因此，我们试图找到一种解决方案并希望共享它。
重新思考公关
我们决定尝试不同的方法，但首先，请重新考虑我们的行动和期望。 通过启动“评论”，我们将：
- ...试图衡量员工的绩效；
- ...与他们交谈；
- ...希望最终他们会变得更快乐，更好地了解自己的前景和预期的职业发展。
我们花了大约一个半月的时间来重新考虑这些观点，下面我将告诉您结果。
性能等级
我碰巧看着这样的东西，试图了解这里可能出了什么问题：
在某个时候，一个有趣的想法出现了：这里描述了过多的信息。 实际上，特定的“部门”并不是那么重要-图片可以简化为：
我们对发展的
速度感兴趣，而不是对一个人已经达到特定水平的事实感兴趣。 有什么发展吗？ 有很多人学到的还是很少？ 这才是真正的指标！
调查技能清单的秘密
早先，我们得出的结论是，技能列表对我们来说是一个秘密知识：工程师能够做某事，每天都要做某事，但是很难确切地表述什么。
揭示秘密知识的一种方法是“醒来”，即：修复正在发生的事情，然后对其进行分析。
正如我们可以追踪发现松鼠，狐狸和熊的森林足迹一样，我们将尝试揭示秘密知识...
试点项目
蒂姆利德·彼得（Timlid Peter）同意参加试点项目，以更新的形式启动《评论》。 彼得深入研究想法，我们计划与员工开会。 经过自我准备，Peter提出了有关他的一位工程师Leonid的反馈：
这是质量低劣的反馈的一个示例：如果您以这种表述方式听说过自己，那么对您几乎没有帮助。 即使将所有内容清楚地表述在子的头部（完全不是事实），以这种形式记录信息也不是很有用，因为六个月后，这种“痕迹”将不会带来任何好处-甚至作者也不会记住它的含义。
我们希望反馈尽可能客观，礼貌，而不是作为一种“激励”手段，有助于彼此了解更多。
领先的公关培训
因此，我们制定了以下规则来准备团队负责人的PR：
- 在每次审阅之前，您需要分配半小时到一个半小时来准备。 最好在前一天而不是在同一天进行准备。
- 浏览所有跟踪器（票务系统，信使，业力系统等），即使领导者过于懒惰并且反抗，也可以吸引他的美好回忆。 查看来自先前评论的笔记。
- 写一些要讨论的要点。 这些摘要必须包含：
- 事实，以与跟踪器链接的形式证明其合理性；
- 审稿人的个人态度：解释为什么他（a）强调（a）该项目，以及该项目中有何重要之处。
顺便说一下，我们在这里张贴了措辞不好的例子。公关流程
审查本身
始终是
全职的 。 尽管我们的工作地点很遥远，但毫无疑问可以通过文件/问卷/服务进行任何审查。 在我们的案例中，交流是通过Google环聊进行的，团队领导，工程师，人力资源以及其他相关方（如有必要）也要进行交流。
审查经历了以下几个阶段：
- 谈论分散注意力的话题。
- 一个人做得很好的故事，为此我要感谢他并解释为什么这很重要。 毕竟，我们希望进一步做到这一点？
- 明确表示不好 ：违反协议，纪律和其他您认为不可原谅且无可争辩的事物。
- 根据以下规则讨论难以理解或有争议的内容：
- 确定事实和对这些事实的个人态度。
- 提出一个一般性问题（例如“您对此有何看法？”），以便从员工那里获得有关该问题的更多信息。
- 问一个问题：员工是否认为有问题？ 事实证明，出于某些个人原因，他并不认为这很重要。 我们需要确保他认同我们的看法。
- 问一个问题：员工本人到底将做什么来解决问题？
- 如果员工不同意您的问题，请提供明确的解决方案-他很可能不会对此做任何事情。 在这种情况下向他施加压力是没有意义的-最好尝试理解为什么会这样。
- 要求员工提供反馈 。 在此期间他在公司的生活是否符合他的期望？ 如果您以前真的能够进行对话，那么在此阶段，您会得到反馈，而不是像通常那样的mo昧。
- 谈论薪水 ：您是否提高薪水 ，如果没有，则需要特别确定要提高的薪水 。 薪水问题非常重要和复杂，通常是员工参加绩效评估的主要动机。 有一种怀疑是，如果这不会影响工资，但是尝试启动一些审查程序几乎没有意义，但这并不是100％...
总计：
第一年的成绩
对第一年积累的记录进行的分析帮助我们：
- 打开我们工程师身份保密的面纱；
- 向知识库中补充对员工造成最多问题的说明和信息；
- 改善团队的气氛。
工程师开始
切实，快速地增长 ，他们对职业发展的方向有所了解。
其他重要时刻：
- 初学者适应时开始以更具建设性的方式解决问题：管理者突然发现自己可以与新来者谈论问题，而他会得到纠正！
- 越来越清楚我们在公司中等待什么样的员工，因此对招聘要求进行了调整。
- 对于员工自己来说，他们可能想要什么以及他们拥有什么样的发展前景变得更加明显。
- 草图出现在能力矩阵上，并且有一种不断更新的机制。
工程师肖像
例如，看起来工程师似乎很应该真正热爱自己的工作并喜欢工作...无论如何-事实证明，这是最需要的四种技能（很大范围）：
其他重要技能证明是：
让我们尝试找出第二年
同时，
细心的读者可能会注意到我们并没有非常衡量绩效……也许，随着时间的流逝，技能列表会逐渐减少，并且会形成合适的能力矩阵，或者我们会引入一些其他的评分系统。
此外，目前，我们正在寻找在管理人员之间进行培训的培训方法-我们还没有现成的解决方案。
一个不太容易形式化的单独的复杂问题是评估系统与员工工资问题之间的关系。 在我们看来，这个问题直接由公司的业务模式决定，针对一项业务的解决方案可能不太适合另一项业务。 （我们
已经在枢纽
谈论过我们的模型：我们的建设几乎像一家专营店，随着团队效率和能力的增长，它也有薪水的钱。）
影片和幻灯片
表演视频（〜50分钟）：
报告介绍：
聚苯乙烯
您可能也对以下出版物感兴趣：
在我们博客上的其他报告中：