|
“拿出成果” vs “人来上班”
人来到公司上班并不代表他真的做了工作。你运营的是公司而不是高中体育课。出勤率并不能保证他获得高分。
基于产出的评价将会是一个更加健康的模式：某个员工本周完成了多少功能的开发？他修复了几个bug？他们和客户完成了几次交易？他的程序运行速度有多快？占用内存有多小？维护难度有多大？
在Discourse，我们通常会根据员工的GitHub日志来评定其工作质量的优劣。或许你还可以借助Asana或者Basecamp等流程分析工具进行分析。
对于我而言，最重要的是：
让员工把他们所做的有用的部分展示出来。我需要看到的是done的部分，而非to do的部分。
我不在乎员工何时进行工作或者他们自己的日程安排情况。我不在乎他们生活在哪个国家。我不在乎他们特有的工作方式。我不是一个微观的管理者。如果你真的招到了最好的员工，他们就应该通过自己的工作成果向你验证你的判断。
你怎么确定哪些人更加合适呢？当你的员工主动指出产品的问题并独力给出解决方案时你就能确认这一点了。这时，你就能够更加放心的把产品的改动权（以及犯错权）交完全交给这些员工了。
以实战演习来招人
假定某个背景不错的候选人已经通过了初期的筛选。现在，要进入面对面的对话时间了吧？
我曾经不止一次的看到过通过了以上流程筛选的候选人在入职之后完全无法完成职务的职责需求。即便是你曾经和一个人面对面的对谈过，要想最他的职业道德和专注度做出判断仍然是一个及其困难的事情。
如果你真的想看看某位候选人的真实水准，在他和你团队中的其他成员接触之前就给他一个项目测测他。我所说的不是那种一般性、抽象性的问题。我说的是你正在处理的项目中所遇到的真正问题。你应该把这个问题抛给他，看他的反应和做法。这是一个本应由现有员工解决的问题。
理想中，你的演习项目应该是那种有着明确目标完成定义和完成截止时间的咨询项目。给候选人一个可以在几天内完成的小型项目。是来公司还是在家远程工作则由他自行决定。
我知道并非所有的公司都能从整体流程中随时拿出一个小型的项目供外界解决。但是如果你做不到这一点，你的公司在现有结构下在运营流程上可能是缺乏结构性的。
在Stack Overflow，我们有一些开源组件，在招聘时，我们会让候选人针对这些组件独立开发我们想要但还没做的一些功能元素。如果候选人能够独立工作，能够与我们清晰沟通并且按时提交要求中的作品，那么他就是一个合适的入职者。
（责任编辑：职场达人） |
