在职场奋斗了8年的我，从一线开发到现在做管理。遇到了很多形形色色的人，在这些人接触当中我发现很多人不会做任务拆解。
什么是任务拆解？简而言之就是将大任务进行不断的拆解使其变为小任务。乍一看这是一个很简单的事情，但是实际上这需要一个宏观判断如何去拆，不然最后可能会导致整体方向的偏差。下面我将用一个实践中的例子来讲解我的任务拆解思路。
一、背景
最近新接手一个大数据中台，在最初接受该产品时听到消息是在近一年中总是出现性能慢，卡顿的问题。在这里可以了解到解决的是一个性能问题。之后得到消息是这个团队的人员士气低落，其次这个性能慢和卡顿问题已经持续了有1年左右，由此又引发了前场团队对后场团队的技术信任问题。
二、解决思路
1. 信息收集整合
从背景中可以看出，目前已知信息是该团队的技术能力差。但是真实情况是怎么样的呢？首先我做了人员1v1对话沟通。从技术硬实力到沟通协调等软实力进行了摸底，简单的分为了技术深度、软能力、职业发展与目标、业务理解、创新与问题解决等几个维度，每个维度有不同的权重比重进行打分。
其次进行代码审查以及技术文档查看，发现代码质量差出现比如多层for循环，30w查询结果排序，所有对外接口都采用通用动态SQL方式，技术文档几乎为空或者不实用的情况，版本混乱等等。
最后收集领导对这个事情期望的方向，要稳扎稳打平稳过渡在此基础上尽快解决业务上的问题。（这里我要感谢我的老大，给了我全力的支持并为我拦住了大部分压力，谢谢）
2. 任务拆解
从信息收集上看，第一管理出现了问题，比如没有或少量的组织过程资产的留存，第二版本分支管理混乱，比如更新迭代只有一个版本，且有不同分支在生产运行且代码不一致无法兼容（生产的版本肯定要一致的）。第二技术实现出现了问题，比如嵌套循环（3层）、结果数据为30万数据需要先排序在取数（数据表为10T的数据表）。从这里其实就可以发现我把这个问题首先拆解为了两大类一大类为管理二大类为技术。
一大类管理再进一步拆分，如版本管理制度、技术流程规范、项目交接规范、Java开发规约以及后续实施步骤。第二大类为技术，在不断的深入过程中。陆续的发现了很多的问题，这里我就不一一赘述了。总体来说分为了两项硬件和软件，其中硬件是因为数据库选型为分布式数据库很吃硬件，而服务器硬件又用的是机械硬盘，这个必须升级提高IO的并发能力。软件又根据现实的情况列为API优化、Job优化、链路调用优化、架构优化等。其中架构优化为数据架构优化比如实现冷热数据分离、历史数据归档、数据均匀分布等等（这里我也很不理解，原团队Leader汇报说软件优化到了极致，很想问问冷热数据都不做，历史数据不归档。你就是选的数据库性能在强大也顶不住10T数据硬查，而且查的时候还要先排序。。。小小的吐个槽）。
三、总结
所以从真正的任务拆解来看，我这里的主要思路是先做信息收集列出目前具体有多少问题，之后在对问题进行分类细化，细化之后在针对每个问题出解决方案最后从方案回看是否可以解决问题，以此循环来解决具体问题。
