研究任务管理，就是为了把事情做出来，产出实实在在的业绩和成果；

做事是管理中非常重要的事情，做事是一个过程，那么我们可以分为事前、事中、事后三个阶段来讨论：

• 在做事之前，我们需要回答的问题是：要做哪些事？先做哪件，后做哪件？也就是分清楚轻重缓急，也叫优先级梳理。

• 在做事过程中，我们要确保事情的进展按照计划推进，尽在掌握之中，也就是有效地推进执行。

• 在做事之后，我们要复盘做事的整个过程，并从过去的经验之中抽取一些流程机制，以便以后在类似的场景下也可以做得更好、更顺畅；

因此，我们把事前的轻重缓急、事中的有效执行和事后的流程机制，称为任务管理三要素

多任务并行如何应对?

排项目优先级是管理中必备的技能，我们常见的是：重要紧急四象限，即分为重要紧急、重要不紧急、紧急不重要、不重要不紧急；

当面对问题时如何判断事情是否重要紧急，可以采取如下自问的策略：

• 如果做，收益是否很大？收益越大，这个事情就越重要；
• 如果不做，损失是否很大？损失越大，这个事情就越紧急；

在实际的工作中，我们经常做的并不是梳理轻重缓急四象限，更常见的情形是，我们要把日常的工作分为两种情况：

• 一种是计划内的，也就是按照我们的规划进行的；
• 另外一种是计划外的，即突发的情况和任务；

应对策略其实非常简单：

• 对于计划内的工作，我们更关注它在一个规划周期内的价值和收益有多大。我们会把价值足够大的任务安排进来，并持续地往前推进；
• 对于计划外的工作，由于是一种突发情况，是否要中断既有安排来高优先级跟进呢？中断既有安排一定是会影响正常推进的收益的，所以我们要做的决定是，是否要立刻跟进？如果不立刻跟进，带来的损失有多大？我们是否愿意并能够承担？如果不能，那就立即跟进。如果可以不立即跟进，那就转化为一个可以安排到“计划内”的工作，并参考第 1 条的策略就可以了；

总结起来，对于任何工作任务，决策的步骤就两步：

• 对于“计划内工作”，看收益是否足够大。收益越大就越重要，也就越需要给予相匹配的优先级、资源和关注度；收益相对不大，就放入“To do list”，作为待办任务处理
• 对于“计划外的工作”，看损失是否足够大。损失够大，就按照紧急任务安排，以止损为核心目的；如果损失可控，就放入“计划内工作”列表

可以通过看收益来判断重要性，通过看损失来判断紧急性，那么这个四象限我们就可以调整如下：

需要注意的几个点

• 目标是需要一以贯之的；目标的设定和评估贯穿着整个管理工作的全过程，目标越明确，在关键时刻我们的方向感就越强；反之，我们就会瞻前顾后，反复掂量却不得要领。所以，好的决断力，往往基于明确的诉求和目标；
• 任务安排是弹性的：对于一个任务来说，其进度、质量和效果这三个要素是可以此消彼长的，所以在拆解任务的时候，对进度的预期不同，对质量的要求不同，对效果的期待不同，都会导致时间预算和优先级的变化，因此不能用固化的视角看待一个任务，每一个任务其实都是可以弹性安排的
• 沟通是不可或缺的。虽然排优先级主要是管理者来做，但是这并不意味着排好优先级之后就大功告成了。只有和所有相关的人员充分沟通了之后，才算是调整完毕，尤其是和自己的上级，一定要和他沟通新的工作安排方案。告诉他，你优先保证了什么，从而可能会影响什么

如何确保项目有效的执行

项目执行过程中常见的问题

1、目标不明确

• 虽然你很清楚做某项目的初衷，但是并没有去设定可以衡量的目标。比如某次技术重构、某个模块性能优化等。也就是说，虽然你知道自己想要什么，但是不知道出于什么原因，你没有设定一个清晰可衡量的目标，而目标不够清晰的话，必然会引发时间预算、人力预算，以及优先级决策的模糊；
• 虽然在你眼中目标很清晰，比如“到年底某模块单机性能达到 500qps”，但是负责项目实施的员工并不知道该从哪里下手去执行；
• 在你看起来，两周能搞定的事情，员工却花了 3 周时间。诚然，完成质量的确很高，可是和质量比起来，你更希望在 2 周内发布；
• 项目交付时间提前到这个周末了，员工没有完成，可他为什么还一副很无辜的样子呢？
• 项目是如期发布了，可是这不是你想要的效果啊！

上述问题共同点：

• 目标不够明确具体，至少没有具体到执行人员可以执行的程度；
• 上、下级对目标的理解看似一致，实则有偏差，尤其是对进度、质量和效果的拿捏上；
• 目标发生变化了，没有及时同步给相关的人员；

2、责任不明确

• 这个项目涉及到的各个相关团队，是否都有一个明确的负责人呢？
• 这个负责人和所有项目组成员，是否都清楚各方面的负责人呢？
• 这个项目是否有唯一的总负责人，以及总负责人是否有效呢？

如果上述问题有两个比较模糊的地方，就会让问题失控

• 第一个地方是：各负责人对于“负责”的理解常常是不一致的：很多负责开发的工程师，他们认为的“负责”就是承担自己份内的开发工作，而项目某一角色的负责人是指对该项目中所有涉及项目执行和协调的问题都要负责；
• 第二个地方是：总负责人无效。即，虽然有名义上的总负责人，但是总负责人顾不过来也好、自己不认同也好，都会在项目执行过程中“缺位”；

3、流程不健全

• “如果 A 也像 B 那么积极主动，这个项目就不会出问题了，所以 A，你能不能更主动一些呢？”；
• “我们明明约好了有问题及时通报，为啥总有些人不通报呢！”；
• “我们各种各样的流程都有，很完整也很系统，但是大家就是不按照流程办事……”；

于是很多管理者就制定了全套的流程让团队遵循，但由于学习和执行成本很高，员工遵循起来非常痛苦，因此就干脆让流程机制去“睡大觉”。这也是很多团队的真实情况，他们有很多流程机制、规章制度的页面，但是还是做不好项目。

归结起来，这类问题主要体现为：

• 过于依赖人的主动性，缺乏基本的流程和机制；
• 虽然有机制，但是没有人监督执行；
• 虽然机制有人监督执行，但是大家依然不愿意执行

4、沟通不到位

• “我通知了啊，为啥他们就是不听呢？”
• “对方有问题不主动找我沟通，关我什么事！”
• “我不知道啊！什么时候变更的？”
• “不是说好了周五交付的吗，他们没有如期交付啊！”

这类情况就是“信息不对称”，大家在一些事情上没有达成共识，由此产生了协作上的偏差和误会。原因可能是对信息本身的理解就不一致，也可能是没有有效传递和同步，总之在沟通这个问题上有诸多的不顺畅，归结起来就是：

• 主动意识不足，沟通不够主动。
• 通报意识不足，没有知会到所有相关人员。
• 闭环意识不足，广播出去了，就默认对方收到了；

如何有效执行任务

通过上面的内容可以看出，这四类问题的钥匙归结为“有效执行四要素”，即目标清晰、责任明确、机制健全和沟通到位，以方便我们梳理和诊断执行问题。

这四个要素扩展为 12 个问题，如果你对某个项目的执行不够满意，又想了解到底是哪里出了问题的时候，就可以参照这个“问题清单”检查一下

如何让流程机制有效的执行

要让员工分担我们手头上的工作，要么靠梯队，要么靠机制：

• 所谓靠梯队，就是团队里有胜任度非常好的人，可以帮我们搞定这件事，并且这个人已经是这方面可靠的梯队人才；
• 所谓靠机制，就是设计一套方案，来专门应对某个场景出现的问题，这套方案可以指导和“搀扶着”员工做好这类工作

如何建立机制?

• 首先要明确该机制要解决什么场景下的什么问题，即明确目标：机制的一大特点，就是场景化特性非常明显，因为它们都是为了应对好特定场景下的问题而产生的。比如服务报警响应机制、公- 关事件应对机制、新人入职培养机制、项目沟通机制等等；
• 提炼应对该场景的关键点：从你和其他经验丰富的人身上提炼出应对该场景的关键环节，因此当有成功经验时，这些关键点的提炼会容易得多；
  明确由谁来确保机制的执行，即谁在什么时候检查什么关键点：每个流程和机制的执行情况如何，谁来检查和确认呢？如果少了这个监督者，流程和机制的有效性就得不到保证。所以，每个机制，都要设立监督者或检查者；
• 确认操作成本：即，确认该机制对于执行者来说是可操作的。你建立机制是为了简化工作，最好能够做到“自动驾驶”，如果建立的机制反而给执行者带来更大的操作成本，那你就得反思这个机制建立的必要性；
• 沟通，并和其他执行人取得共识：由于机制的制定者和执行者常常不是同一个人，所以，该机制是否有效，以及能否实施，需要和其他执行人沟通，并达成一致；

建立机制时还要遵循如下的四个原则：

• 可操作，即简单原则：也就是说，机制要以最小的学习成本和操作成本为原则，这是最首要的原则；
• 只打关节点，即关键原则：建立一套机制，不必要对所有的细节进行完整的描述，没有人喜欢看长篇大论的文字，你只要告诉大家，在哪几个最关键的节点，做什么样的动作即可，而且这样的关键点也不能太多，以不超过 5 个为宜；
• 明确到人，即问责原则：在各个关键点由谁来跟进呢？这个问题要有明确的约定，不能完全靠人的自觉性；
• 从 case 中来，到 case 中去即实用原则：千万不要为了建机制而建机制，每一个机制都要有实用价值。由于机制都是有场景化特性的，当场景发生了变化，机制也要随着升级，而对于机制的重新审视和学习都意味着额外的开销，所以，每个机制的维护都是有成本的。