TODO一切？待办任务在业务系统中的泛化和归一

【本文内容思维导图】

TODO的前世今生

国人大概较早从Outlokk的首页，开始接触日程和任务。

日程：只关注时间（datetime）,不关注执行状态和结果。最早在Outlook中就有这个功能。

任务：更像是拆分到子项目中的一项具体事务，倾向于内容。例如看板，输入一个内容就行，无需时间、执行人。

TODO：中文名：待办（task），最基本的元素：从A到B，一个待办的传递；有任务要求；执行结果。A可以等于B，有的待办支持子项，支持嵌套关系……会更复杂。

TODO的发展，是对日程与任务的沿袭。

TODO泛化到业务场景

借用微积分的奥义：让复杂的难题简单化——在面对一些不可控的问题或者事物时，微积分最核心的解决思路是：切分与组合。TODO基于任务做拆分，将业务拆分成任务，要协作各种任务，这类似于切分；另外，TODO这一载体，承载了多种管理对象的推进，形成组合。

待办的执行逻辑：发起人、执行人、要求、完成状态、deadline，这些元素决定了在业务场景中都能覆盖到它们的任务传递要求。企业的日常运营，是一件一件的事按照计划执行。计划可以是工作范畴，这件事由谁负责。将企业中的事拆分到可落实给责任人的时候，就是TODO的运行。

【超兔CRM：一个待办任务的创建】

Todo的高级形态：项目，是一种高阶复杂的由反向WBS构成的结构化子任务。常用甘特图，项目中的所有任务，有并行（A和B同时做），有串行（先完成A再完成B），有条件约束，有资源占用。将待办任务这一原子，以项目做主线抽取，形成的时间与时序，就会形成甘特图视角。

不仅仅是项目，TODO这个载体完全可以承载起企业日常业务的执行推进，凡是落实到责任人的执行，都可以扔到TODO里。在超兔CRM中，TODO的管理主体覆盖：客户，项目，机会，订单；以及SFA（自动化引擎）。

【超兔CRM：SFA】

泛化的边界

在超兔CRM，TODO的泛化并不能覆盖全部业务。例如，出库、发货、回款等，就没有泛化到待办。这是为什么？因为待办本身承载不了复杂的业务细节数据。举个简单例子，用户在出库单点出库执行的时候会确定SKU、批次、动态成本、序列号等……

这些业务细节数据，必须与出库单的原单有基于业务的数据关系对应。这也是为什么大多数管理系统使用关系型数据库，因为数据之间的链接实现了业务关系的管理。不管是和客户沟通后，对实际的出库产品做了更改；还是出库后引起的库存变化……这背后一系列的数据执行逻辑，不能简单地用待办来解决。待办任务往往具象到明确的文字要求，而不做数据推演的业务逻辑，因此，泛化是有边界的。

归一

一个TODO可以承载各种业务，本身就是一种归一。

另外，超兔使用IM的方式对TODO做简化，简化执行逻辑。

面向角色分析。待办中发起人对执行人的情况：

情况1，A到B。一对一。

情况2， A到B，C。一对多。

情况3， A到A。我给自己。

情况2相对复杂，它又存在2种情况：

1）都执行完，算结束；

2）只要有一个人执行完，便算结束。

如何过程管控？

沟通工具，在一线中是最简化的管理工具。边沟通，边执行，是大多数TODO的常态。超兔CRM待办全部进入快协作，即待办之内自由沟通，优势明显：

1）强化沟通/保留过程：走形的概率最低，效率最高。

2）随时拉人：@其他人 进群沟通，沟通内容可以回溯。

如何控制结果？

阶段1:日常工作中我们判断完成情况，主要通过执行人反馈来了解，但是，经常存在执行人不做主动回复。这种数据逻辑清晰明确，但是和用户的常识有偏差。管理系统的作用就是要消除这种管理不畅，所以，我们在待办中可以设置反馈。

阶段2:超兔在一对多的设计中，加入了【完成】与【结束】的概念，用以区分待办的完成情况。先不说2种概念过于模糊，一旦分支过多，带给用户的负担越重。如果加入防呆设计提醒用户，效率又会打折扣。

阶段3:为了让用户真正实现无脑操作，超兔只保留了一个【结束】按钮。事实上，我们对完成情况的判断，目的是为了控制结果。要是对任务结果不满意怎么办？只要给任务创建人单独保留一个【恢复执行】按钮，一切问题迎刃而解。

【超兔CRM：待办恢复执行】