PMCAFF（www.pmcaff.com）
：最大互联网产品社区，是百度，腾讯，阿里等产品经理的学习交流平台。定期出品深度产品观察，互联产品研究首选。
外包大师（www.waibaodashi.com）
：
要外包，找大师。PMCAFF旗下高质量互联网外包解决方案提供商。外包大师服务号：waibaodashi365
作者
：鲍捷 文因互联CEO
编者按：
今天我们推送一篇适合周一阅读的文章，周一可能是上班族们最不喜欢的日子了，上周的工作完成得怎么样了，本周新的工作开展了么，所有工作上需要考虑的计划、需要跟踪的进度、需要复盘的总结都将在这一天展开。所以你可能需要这篇文章。
本文的作者是来自文因互联的CEO鲍捷博士，他提到，
锻炼清晰的目标界定、目标分解、目标沟通的能力，是初创企业成员快速成长的最核心的能力之一。
其中写工作计划，最重要的不是罗列，而是先想清楚整体逻辑。最终写进OKR（目标和关键结果）的，只是一些点。如果心里没有逻辑，首先OKR就写不深，其次在执行中出了问题，就会不知所措，不知道该怎么修订计划。画虎要画骨不是画皮，写计划要先想逻辑再列条目。
他用这篇文章阐述了一名优秀的初创企业员工如何来做好工作计划。正文如下，欢迎阅读转发。
一句话总结任务分解和目标管理
“知所先后，则近道矣”
写OKR的深层次的问题就是掌握任务定义的一系列方法论。我这里列一个我自己觉得可行的分析框架。肯定不只这一种构造方法。
说一千道一万，任务分解和目标管理，就是一句话“知所先后，则近道矣”——就是搞清楚优先级。
锻炼清晰的目标界定、目标分解、目标沟通的能力，是初创企业成员快速成长的最核心的能力之一。
目标的管理，分为几个层次
-
自己知道目标
-
自己知道目标的实现路径
-
让别人知道目标和路径
-
知道相关的其他人的目标和路径
-
让其他人知道你知道他的目标和路径
推行OKR制度，并不是要追求形式主义，而是要减少做无用功。在创业公司，很容易忙、忙、忙，所谓的“用战术的勤劳掩盖战略的懒惰”。
负责人，一个月里有一天，甚至什么事都不干都可以，一定要想想这个部门或者小组的目标是什么，并用清晰的语言让所有人都知道。
部门负责人级别的人，则不仅要理解自己负责的事情的目标，还要把自己的防线外延一公里，理解友军的目标是什么，并让友军知道你的理解。
我把目标定义分为5个步骤：
-
范围确定
-
目标分解
-
优先级确定
-
可执行化任务分解
-
进入跟踪系统
本文只涉及计划（目标确定）的过程，对于跟踪、总结的过程，以后再详细讲。
范围确定
先把大框框定下来，要做什么，不要做什么。
例如，思考月核心任务的时候，先想我们面临的主要矛盾是什么？我们较长期的目标中间缺失的是什么？然后通过外延和内插来确定工作范围。
内插方法，是从更长期目标来倒推现在什么是重要的。
我司下一个最重要的阶段节点就是A，A最重要的就是B，次要目标是C。对产品而言，关键是什么？但是我们现在的设计，还缺少什么？那倒推出来，我们的核心任务就是什么？
外延方法，就是从过去已经发生的事情出发，来扩展现有的工作。
过去三个月，我们发现了什么问题？因此，在当期，我们要解决什么问题？
在任务思考时，最容易出现因为忙、忙、忙，就决定先不要改现在的计划，投入更多的资源（比如时间）在现有的计划里。
那样很容易陷入maintenance mode，就是疲于奔命而无法提高执行质量的状态。越忙，越需要停下来梳理主要矛盾和次要矛盾。
一个常见的范围确定困难是一件事是发展的，月初的时候很难预料月底达到什么状态。例如一些事，开始确实不知道本月要准备什么。而且，这种不确定性是会在未来反复发生的，那我们就应该生成一种“探索性预案”，也就是一套标准的分解探索性任务的方法。
如对做成某事，要针对不同人，可能分为A战略、B战略、C战略、D战略几个部分。如果这个月我们打算推进这件事，那可能需要我们主动准备其中一些组件。
例如A战略通常是一次讲座、对方某些人和我方某些人员的对接，B战略通常是一次需求访谈和产品原型展示，C战略可能是一次正式的路演。
我们这个月计划执行哪些技术动作？在不确定性任务中，总是会有一些我们可以有主动权的标准件。我们需要平常多总结，形成一套探索的标准流程。
所以，不仅解决问题是可以计划的，探索问题本身也是可以计划的。
计划赶不上变化，只要一开始的OKR是逻辑清晰、表达清晰的就行。
目标分解
定下来任务，下一步就是把任务拆分为更具体的结果。
理想的OKR里，每一个结果都是可以被量化的，诸如“xx率达到70%”这样。但是这往往是困难的，可能会让制定计划的时间过长。
我以为不必拘泥于形式，只要一个结果是可以被验证（validate，即可以知道是不是做了）和追责（accountable，也就是如果掉链子了我们可以找到当事人）就可以了。
例如如果我们说“进行xxx的设计”，这个是比较含糊的，因为无法精确定义什么叫“xxx”，但是我们在设计过程中必然会生成一些文档，这些文档是可以被验证和追责的。
我们中间的文档，这就是xxx设计的其中一步，到月底前，我们还会有更细化的设计文档——也许不是这个脑洞，但到月底会有一个可以执行的脑洞计划作为xxx的一部分。
在这一部分的任务分解里，还是比较粗的。我认为，大体上一个大目标可以分为3个小目标(more or less)，每个小目标也可以再细分为3个子目标。
再细就不合适了。如果列的很多，那说明这个目标太大，应该考虑进行组织的分解，用更精悍的小组去聚焦任务的执行。
世上无不可拆分的任务。如果发现事情搞不清楚，不妨先画个思维脑图出来，开始乱一点都没关系，花上半天时间去梳理，然后把小的聚类，大的分解，总是可以总结出来一个合理的分拆的。好的分解也都是总结出来的。
利用看板就是日常地锻炼自己的任务分解能力的一种工具。强迫自己把任务逐步拆解为以天甚至小时为单位的任务。也必然在执行的过程中，发现拆解的不合理。在逐级的细分中，自然会“涌现”事情内部的逻辑和优先级。
优先级确定
总是有很多杂七杂八的事情，不得不做，或者有些事情比较孤立，甚至不在核心目标里。在列目标的时候，心里想一下，哪些是must to have，哪些是nice to have。
凡是不在核心目标内的结果，就是nice to have。一些工作是可以推后的，虽然如果不推后会更好。
但是，作为部门负责人，必须有意识地推进一些重要而不紧急的事情。部门负责人必须有全局的视角，在更长期的执行尺度上来理解事情的优先级。
对于公司的长期发展，最核心的事情反而是重要而不紧急的事情。一些事，看起来不急，但是却是保障公司执行力的关键一环。部门负责人，要有意识地做一些有提前量的事情，而不是每个月忙着救火。
80-20法则，最重要的事情是20%的事情，虽然我们不一定能事先知道是哪20%。我们的计划，要允许一些事情做不完。
可执行化任务分解
OKR是一个目标沟通文档，OKR不是执行和日常跟踪文档。从OKR到可执行的计划，还需要一层更细粒度的分解。
我们用看板来做可执行任务的调度和跟踪。看板上的任务粒度，原则上不超过一个人天。每个人每天的工作，应该在看板上产生一个变化。同样，所有的任务都是可以可以拆分的。
用程序员熟悉的语言来说吧，大家都知道一个很长的函数是不好的，一个1000行的文件是不好的，写了一周的程序只有一个commit是不好的。我们总是有一些事务逻辑的分解方法，把一个大的任务拆分为小任务。
假如一个小组是3个人，OKR里可能列了5-10项可验证结果（如果是比较琐碎的结果10-20也可以接受），那在这个小组的看板上，就可能有60-80个小任务（因为有3*22=66个人天）。这种分解的粒度，让每个人每天都有进步（progress），对自己也是个小小的激励，对团队里其他人也是沟通的方法。
OKR不会变得太厉害，看板是可以频繁调整的。任务没有拆分好，随时可以改。
那能不能用看板来直接取代OKR中的目标设计呢？不能！OKR关注的是事情的逻辑和优先级，而不是具体执行层面的细节。而且看板是不断变化的。
OKR是要用来复盘的，所以当初的目标设计有一个静态的、简明的说明，对未来方案总结也有不可替代的价值。
进入跟踪系统
