什么是任务
在互联网公司的项目管理中，我们会将目标宏大、耗时较长、以及复杂度高的工作进行拆分，将其拆分为许多个目标具体、时间可控并且复杂度可控的任务。这些任务互相关联，通过工作流程或者接口协议的方式组合起来，最终实现了我们最终的项目目标，同时这些任务之间又相互独立，独立到可以让一个人在一天或者两到三天完成，不需要两人共同完成。在有些公司或者在某些项目管理的工具中，我们也会称这些任务为story、task或者卡片。
任务的建立和管理是我们需求管理和产品设计范畴内的工作，非常重要，因为这是我们项目开发工作的源头。在任何一家互联网公司中，开发、测试以及上线、销售、运营等工作都是在此之后。如果我们在任务拆分和任务描述中出现任何细微的差错，最后都会被成百上千倍的映射到我们后续的工作中，这种影响与距离任务的工序长短正相关，如同我们甩鞭子时候，手部的动作不大，但是鞭子尾部的摆动幅度数倍于手部摆动幅度。这种现象被称为牛鞭效应。
这些任务做为我们项目开发中的最小组成单位，就是我们项目的细胞。犹如人体细胞分有益细胞和癌细胞一样，这些任务同样如此。对任务的合理划分、对任务高质量的描述和设计使我们生产出了有益细胞，确保了项目的稳定和质量。反之，混乱的任务划分、模糊不清以及错误的任务描述和设计就像癌细胞，只会让项目陷入困境，最终摧毁项目。
如何划分任务
对任务的拆分并没有定理或者公式，因为这并不属于一个客观世界的问题，有相当的主观性。同一个人不同项目中，或者不同的人相同项目中，任务的拆分结果都不一样。我们还是要结合项目团队成员数量、能力来定。不过，任务拆分的原则还是有的：
- 任务要拆分到只需要一个人来完成。
- 任务要拆分到在迭代周期内可完成，或者可以在1-3个工作日内完成。
- 所有的任务组合在一起能够实现项目的目标，也就是说，不能有遗漏。
- 在以上原则下，拆分的任务数量要尽可能的少，不能为了某种汇报或者邀功的目的而拆分出大量的任务。
总之，任务拆分要遵循8个字原则：不重不漏，不共不难。
如何管理任务
管理任务可以分为两个方面，一是描述任务，二是为了项目管理而进行的任务状态变更。
描述任务
描述任务指的是对任务进行分析，给出产品设计和开发计划等。在这些年的工作中，我个人最为常用或者喜欢的对任务的描述是按照以下结构进行的：
背景
收益
产品设计
测试点
详细设计
测试用例
背景的描述非常重要，一是为了让合作的其他同学能够快速了解为什么要做这个任务，同时在了解的过程中，其他同学也会逐渐具备行业知识；二是为了将来的查验或者其他新同学学习。
对我们个人或者公司来说，我们的时间或者资源永远都是优先的，因此每时每刻我们都在进行选择，选择使我们的收益最高、机会成本最低的事情或者工作。我们将基于何种规则进行选择呢？对于产品经理来说，就是每个任务可能获得的收益。所以，这一点的重要性不言而喻。
产品设计是产品经理的硬功夫，也是一个检验产品经理真伪的试金石，在这里我们会发现，真的不是人人都是产品经理。卖书的人这么说，买书的人就这么信，就too young too simple了。在这个部分，最值得我们思考的不是这个设计是否实现了需求（当然这是前提），而是为什么选择了这个设计。请注意，对成熟的产品经理而言，一个需求可以通过多个不同的设计来实现，如何选择最优的设计才是大牛级的产品经理最常面临的问题。
测试点是产品经理从业务需求的角度提出的需要特别注意的一些内容。
详细设计以及测试用例是围绕着任务实现需要开发及测试人员来进行思考和设计的内容。
任务管理
任务管理指的是任务的状态管理。在敏捷开发中，我们会对任务进行状态的划分，很多的项目管理工具都支持这种划分。虽然有的工具叫board、有的叫看板或者kanban，有的叫视图或者状态栏，名字不一样，但是管理思路都是一致的。所有的工具都会将任务分为以下状态：
to-do
doing
done
基于以往的工作经验以及项目管理的实践，我会将状态分为以下几种：
backlog
to-do
developing
ready to test
testing
ready to deploy
deployed