团队管理：任务管理的分析授权以及执行监控模型

最近经过几乎崩溃的忙碌后，终于有时间来复盘一下这一段时间的工作，其中一个非常明显的问题就是，任务管理差点失控。

我带领的团队负责的领域很广，又在公司数字化转型的关键时期，所以每一个领域的工作任务都几乎多的超出掌控。

虽然最终撑下来了，也做的还行，但是我自己非常不满意。

可以说，我自己都陷入了繁杂的工作中，没有定目标、没有规划，完全的是靠个人能力去carry，这一段时间的工作方式，并不能算合格。

作为一个leader，最重要的三件事是：管理规划（方向）、团队建设（带人）、任务管理（做事）。

今天主要说的“任务管理”这个层面的事情。

所有的管理规划或者团队建设，最终都要落地到任务管理上，因为所有的事情都要去执行实施。

并且，管理规划、团队建设都是面向不确定性的工作，而任务管理却是一个非常明确的有套路可参考的确定性工作。

但是要注意的是，不能随意的口头吩咐一声，然后就等着结果，完全成了发号施令型的boss，没有丝毫的思考分析。

一直在给团队成员强调，不要把工作做成了“狗熊掰棒子”，一定要有积累有成长。

其实对于自己也是这样，做的事情一定要有目的计划性，在leader职位上一定要考虑ROI。

还是那个老问题，如果自己的团队是个创业公司，你会怎么考虑使用每一分的人力、时间、精力等资源？

超越任务管理的分析思考

业界有非常多开源或者商业化的任务管理软件，但往往都侧重任务的创建、分享、执行流程可视化等协作流程。

或者有一些条目名称、任务截止时间、甘特图……笔者也一直用AbstractSpoon的todolist软件做任务管理。

这当然非常有价值，可是作为技术管理者当然不能只看到这一点，最重要的还是任务协作过程背后的价值分析决策过程，以及从任务执行过程中获得的洞见。

例如：

Why。分配这个任务的目的、理念。
How。具体的操作方法和措施。这一点就是所有任务管理软件都有的。
What。这个任务完成后的现象、成果。这一点是要事前思考的。

这是一个简单的黄金思考圈模型的思维方式，但是实际上，作为管理者必须从任务价值、工作授权、人员培养洞察、流程机制等各个维度去思考。

任务执行只是一个最基础的维度，如何保障任务执行，以及上面提到的各个方面都说明，作为技术管理者必须通过多维思考模型来进行任务管理。

从笔者自己的经验，结合给我极大帮助的极客时间课程《技术管理实践36讲》，给大家分享一下自己的认知。

任务的价值分析

除非是部门安排的非常细碎的事务性工作，对于任务管理的第一步，应该是价值分析。

技术管理者虽然在做技术，但是也应该跳出包工头思维，在做任何一件任务之前，应该先进行“商业分析”，而不是盲目的去做“交付”。

商业分析当然有非常多的形式，但是对于技术管理者来说，还需要考虑操作成本，建议先用简单的方式进行记录。

从笔者的经验来说，可以先从下面两个维度，然后根据实际进行扩展或者变更。

ROI-投资回报率

这件事项，首先要问一下自己，做的话收益是什么，如果不做的话损失是什么，而在有损失的情况下，如何最大化的规避损失？

还要考虑这件事的复杂程度，来进行判断需要投入的资源，一般的复杂程度类型有：

时间复杂度。即任务需要持续的时间、时效要求。
规模复杂度。对于技术开发团队来说，涉及到多少个系统模块，跨越多少部门，需要多少的沟通协调。
业务复杂度。业务需求是否明确，是只需要实施，还是需要几乎从混沌状态开始进行分析。业务变化的快速，能否获取非常明确透明的信息，是否有一些显而易见的黑天鹅事件。是否已经多个团队拒绝接手？
实施复杂度。这件事情本事实施起来的技术难度，是否需要新的技能要求、技术体系？现有的技术平台是否能够支撑？
组织复杂度。在组织内的重视程度，以及各相关方的私下态度等等。

还有许多的维度，可能只有重大的任务才需要这么去分析。一般都会根据任务的重要性进行裁剪。

价值意义

其实从上面几个维度的分析，就基本上有了一个大概的认知判断。

这个时候，就需要进行价值分析的结论：

重要紧急程度。
对于组织战略，对于团队发展，对于个人绩效，对于影响力，对于成员培养……各个方面的一个权衡比较，这个事情是那个类别的事项。
价值意义描述。

如果决定要做了，一定要给这个任务找到价值意义，与组织战略、发展方向结合起来。

这样就能与目标方向一致，然后进行工作沟通授权的时候，也可以激励员工。

这一步的商业分析，应该是技术管理者的思考分析以及决策的过程。非常重要，却常常被忽略。

现在没找到比较好的软件进行记录，只是用了一个excel表格来记录：

任务的工作授权

在完成上一步的分析决策后，下一步需要做的，就是工作授权。

这一步决不仅仅是一封邮件的转发，或者口头的任务吩咐，其中蕴含了很大的学问。

具体的话，可以参照《技术管理实践36讲》中的详细解答。

这是一个比较完善的模型，其中最吸引我的一点，就是“克制”。

例如“一条改进“，然我猛然惊醒，我自己每次都恨不得将自己所知道的内容，全部灌输给别人，然后一劳永逸。

却忽略了员工的接受程度，信息误差，甚至在批评状态下产生的情绪干扰以及噪声。

当然，还有一种简化的叫做“五遍布置工作法”：

说清楚任务背景、工作内容、结果目标和时间要求，让员工知道你到底期望从他们那里得到什么结果。
请员工将所交代的任务重复出来，了解其对任务的理解程度
请员工谈谈完成该任务是要达到什么目的，判断其是否知道为什么要执行该任务
请员工分析任务执行过程中会遇到什么困难，发生什么样的状况，哪些情况需要汇报？哪些情况可以自己决定
请员工谈谈对该任务有哪些不同的观点或不同的实施方法。

实际上这一个是事前的安排工作需要问的问题。

从另外一个角度讲，这个模型给定重要节点非常细致，不能靠脑子去记忆，所以还是要去使用模板。

任务的有效执行

在进行了任务的授权以后，还有一个问题。

团队越来越大，负责的领域越来越多，必须找到一个负责人，还要有一个监督人，监控任务的执行。

否则，leader忙死了，还不会产生较好的效果，并且极有可能成为瓶颈。

有四个维度的要点需要注意：

目标明确。
首先，目标的描述一定要符合SMART原则。另外，在描述的时候，一定要明确出来具体的场景，以及提炼出来详细的要点。
例如，要说：如果想要完成一份结构化的产品需求方案，有哪些关键点？而不是直接说，请完成一个需求方案文档。另外还要有效的传达给相关人，一定要听他聊一下对这个任务的认知、大致方案设想等。
责任明确。
除非特别的场景，技术管理者一定要给出明确的要求，以及明确的主体牵头责任人以及配合方责任人，不能出现推诿职责不清的情况。
并且，还需要注意的是，这个责任明确，并不是说管理者自己知道了就行，而是要让相关方都认可！
机制健全。
在明确了责任后，要分析出来这个事项的关键节点，明确谁来监督检查确保工作的执行到位。
沟通到位。
一定要做到积极主动的沟通，而不是除了问题后去协调解决问题的被动式沟通。在达成移植后，及时通过会议纪要等方式通报。
还有一个需要关注的点，沟通是一个闭环，不能是一个“通知”发送的动作。也就是说，一定要拿到被沟通方的明确反馈。