说一个我们容易犯的错 — 刚接触 OKR 时，容易把 OKR 写成任务清单。这是绝对错误的，这个阶段要改进的核心不是 OKR 要如何写，而是要明确自己中长期的价值和短期目标。
任务清单的本质问题是想到什么做什么。就像人肉手动的工厂一样，当面对大量订单的时候，一个简单粗暴的方法就是拼命地加人和拼命地工作来换取更大的生产力，只有当人手实在不够或是人力成本高到不可接受的极端情况下，才会去想是不是可以优化一下，长期下来，导致了自己再也不会思考，导致了只会使用人肉解决问题，如果只有当问题暴露的足够痛时才被重视，比如网站/App挂掉，实在是敏感度太低了。
任务清单第二个问题是落地效率低。我们每天都会遇到各种各样的问题，也每天都在处理各种各样的问题，但即使我们每天都在努力解决各种问题，问题也永远都不会被完全消灭，而且周围的环境也是在不断变化，所以总是会不断的产生新的问题。任务清单不能帮我们聚焦，在落地过程中容易偏离原本的目标，想想我们有没有类似的经历“计划这周要做 xxx，但由于 xxx 问题的出现，所以延到下周”。我们需要更「聪明」一些的做法，识别出哪些是本质问题、哪些是重要问题、哪些是伪问题，或许需要花很大精力去识别出核心本质问题，因为可能在解决了核心本质问题后其他很多问题都不存在了，但是往往核心本质问题不是那么的好解决，比如我们可能会把很多问题归结为自己领导力不足、团队比较弱，这类问题的特点是都没办法短期被解决掉，要做好分阶段解决、长期存在的心理预期，但可能在当下只需要做到60分就能解决很大问题了。最可怕的是伪问题，创业公司的资源是极度紧缺的，根本不可能有资源和时间供你铺开很宽的战线，而大量供团队解决的伪问题，除了让开发人员忙碌，对最终的效果没有半点作用。
第三个问题是规划不明确。未来要如何迭代？怎么避免走到进化的死胡同？下次有新需求时，半年/一年后会不会再重构一次？就算架构设计方案明确，仍然存在落地过程中因变形导致异构情形的出现，不明确更严重，规划不明确不是未来不会生长，而是意味着把生长方向的决定权交给了未知。完善的规划、机制和系统的建立不是一下就能彻底的想清楚的，往往需要不断的探索，但起码要先有最内核的 MVP 版本，再不断的完善周边细节。很多时候我们认为「不就是 xxx 嘛」或者「我已经想的很清楚了就差落地了」的想法，实际上是因为我们没有深入的洞察才导致我们产生了这类想法。就像前几年有个「万事俱备只差一个牛逼的程序员了」段子。
很多事情能做到什么程度，其实在思想的源头就被决定了，因为它会绝大程度地受到思考问题的出发点、思维方式、格局观、价值观等因素的影响。
避免任务清单的思路是要对所做的事具备足够的洞察。不能只会增加东西，而不会舍弃东西，如果因为看不懂重心在哪里，往往也害怕因为自己的舍弃而丢失掉重要的东西。我们要做的每一件事肯定都有针对特定的痛点，比如围绕需求/市场/提效来做，但需要思考我们到底能做成什么，背后的道理很简单，如果一件事谁都能做，且都能做成，那未免也太天真了，那样的话只要开个咨询公司出出方案或者找个咨询公司买买方案就能成功，现实肯定不是这样，同样一件事别人能做成不代表我们能做成，甚至同一件事同一个团队重新做一次也不一定能做成。结合我们自身的资源限制条件，并深入思考问题本身，才有可能对一件事形成自己的洞察。形成的洞察的好处在于，眼里并不是只有 0 和 1 两个极端，而是看清了 1，但只做 0.3，有了舍弃，技术随团队一起成长，不断地给团队带来积极反馈。
阶段性的总结：只有了解当下要解决的最高优问题，以及结合现阶段的发展情况，才能具备制定合理目标的能力。而要做到保质、高效交付，则要基于对问题的洞察，对落地过程进行合理的规划。
再探讨下如何进行合理规划。
首先要认识到条件受限是好事，因为条件受限可以让你小材大用。当其他人用蛮力完成工作，而你靠知识密集型的解决方案来更聪明的解决问题时，你的价值很容易在团队中体现，小团队与大团队竞争的关键也在于此，在信息流动愈快的今天，竞争比的是理解能力和落地能力。其次，要明确技术的立足点是什么：
- 是业务支撑？ - 满足业务快速迭代的要求，解决「有 or 没有」的问题
- 是性能优化？ - 为产品提供更好的用户体验，在「有」的基础上做到更「好」
- 是架构优化？ - 构建 or 重构，「让研发跑得更快 or 为未来做储备」
- …
合理规划的前提是对要解决的问题、目标、长短期的计划都有更深入的思考。如果只是说要去做这件事情，并没有真正的去想一下如何去做，也没评估成本会怎么样，但是会感觉成本比较高，以至于一直没有具体的落地动作，这样的话，无论用不用 OKR 这样的工具一样是搞不定的。此外，规划阶段的权衡要从多个维度考虑，比如一个模块的粒度是大一点好还是小一点好，模块粒度大意味着复用性大、使用成本低，但其使用范围可能越小，当面对快速变化的需求时，就会越不适用；模块粒度小虽然更灵活，但接口数量过多造成使用门槛高，管理起来也就越复杂。一个工程项目不可能从单一维度的好坏推断出项目本身的好坏，只有通过我们权衡自身的能力和资源做出的规划，才能让项目有更全面和深入的发展。
分享：