我曾在航空航天、电信、电子商务和SaaS领域的大中小型公司工作。作为一名工程师，一名经理，现在是一家小公司的C级。
几乎每一个我工作过的地方都至少提到过，而且很多人都尝试过实施某种OKR或其他正式的绩效评估过程，但都没有成功。
成功是指实施，并且坚持了一个多季度。
我不是特别喜欢这些系统，因为（根据我的经验）它们往往不能准确地量化大多数人对公司的价值，也不能捕捉到公司的目标，因此在很大程度上被忽视并最终被抛弃。
另外，对于新公司来说，目标可能会经常发生变化，以至于现在设定的OKRs在一两个季度后就会变得无关紧要。
例如，在一个新的创业公司成立3个月后，一个公司的前任C级人员想要预测出未来两年的OKRs。我说不可能为一个3个月前还不存在的公司制定那么远的目标，于是这个想法就理所当然地（在我看来）消失了。
这是否只是一个糟糕的实施方法造成的糟糕结果？
有没有一些OKR流程的好例子，既能准确衡量绩效，又能为员工和管理层提供真正的价值？
回答：
一般来说，OKRs或者不管你怎么称呼你的目标，以及关键指标，都是一种工具，而不是目的本身。
它们被用来确保你在重要的事情上朝着正确的方向前进。
但是，由于长期以来无法预测未来的问题，在你到达之前，风向变了，潮汐变了，目的地也变了。
这很正常。处理这个问题的最好方法是经常故意问："这些目标仍然正确吗？"
如果不是，就改变它们。或者改变你所测量的东西。让这些工具为你工作，而不是反过来。
这并不意味着它们一定是无效的。
把它们看作是对某些指标的稳定性和进展的衡量，而不是作为实现特定业务目标的手段，可能是一个更好的方法。
回答2：
问题的很大一部分是，管理层想说的公司目标，往往与真正的公司目标不一致。
而且，管理层希望在任何时候都能自由地改变这些目标，或者在感觉对他们的商业目标有限制的情况下放弃这些目标。
举个例子，他们可能会说，公司有一个问题，就是外部支持问题需要X分钟才能得到回应，所以创建了一个OKR来减少Y%的回应时间。
听起来是一个合理的目标。有一些方法可以让这个目标得以实现。
但是，管理层会做出一个决定，比如为了销售而过早地推出一个新功能，或者同意在内部接纳一个困难的新客户，从而导致支持和工程方面的负担大量增加。因此，很明显，这个OKR因为他们无法控制的事情而被打破，因此被忽略了。
每个部门的每个目标都是如此。
销售可能是个例外，其目标与管理层的真正目标更为接近，因此不太可能改变。
我再举一个例子。在我去过的一个地方，产品人员有他们自己的OKRs，而工程师则有另一套。主要是因为这是以公司的组织结构图为模型。所以我的产品负责人和他所负责的团队有不同的目标。
他的目标是提供新功能，我们的目标是减少现有功能的支持负担。
我们正在为整个组织建立一个内部配置仪表板。它很糟糕，人们需要不断的支持来使用它，并解决各种问题。
但是这些对产品负责人来说都不重要。
这在SRE的结构中其实很常见，SRE的目标是稳定性，而开发团队的目标是增加可能影响稳定性的新东西。
按照SRE的原则，如果错误预算用完了，那么他们可以冻结功能进入prod。
这在本质上违背了业务目标，因为业务通常希望尽快获得新的功能。