浅谈一下：如果交给你一件复杂的任务，要该如何处理？

一、前言

      毕业挺久了，随着自身和工龄的增长，不可避免地会遇到很多事情，简单的事情我们都可以轻松且高效地处理掉，但总有一些看似复杂实则确实复杂的任务落在我们的身上，让我们抓耳挠腮、苦思冥想。就此情况，分享一下我在工作中遇到一些“看似复杂的事情“时的一些处理经验，大家相互应证学习共勉。

二、处理模式（开发者视角）

当我们接到一件看着就很麻烦的任务的时候，不要慌张，冷静的头脑。有困难不怕，抽丝剥茧，先宏观后具体，先模糊后清晰，步步推进，处理办法总有迹可循。

2.1、心中要有一套完整的处理框架

     处理复杂的任务，需要严谨的流程才更容易把控住进度，否则容易因流程混乱而导致卡点，最后因众多因素导致任务延期或中断。

（纲领-->细节-->思想）

2.2、针对任务复杂程度的不同，可以视情况简化流程

主要围绕一个核心思想：“在确定了任务必做的前提下：做好风险评估&预警、方案拆分制定&评估、上下游协助把控、方案落地校验”。

2.3、评估需要群策群力，排除风险

       复杂的任务往往是组合协作完成的，不能只靠某一个人评估&决策，这样会存在“思维死角”导致方案存在漏洞，直接影响任务完成质量，需要运营侧、技术侧、测试侧，根据需求实际情况，多方一起进行评估。

核心思想：

• 在风险可控，影响面积能接受的范围内，向后推进节奏。
• 每往前推进一步，都要有计划和心里预期，并且有对应的验证措施。

注意⚠️：
有些任务不是特别复杂，很多评估操作，可能各方碰个头，经验丰富的同事，几句话就搞定了，但是这个评估思想，作为任务执行的当事人，必须心中有数，才能把控制任务执行节奏。

2.4、负有进度和风险周知，风险预警的责任

      作为任务实际执行人，在任务各个阶段中，不能一味赶路，也负有进度汇报，风险周知，风险预警的责任。复杂的事情一般周期相对较长，期间保不齐会出现意外情况，可能是业务变动，协作方变动，技术侧调整等等，需要不定期将风险周知道各个协作单元上，及时和任务发起人沟通&评估，任务目标的预期是否存在偏差，以此来把控整体进度，确保任务节奏。

在整个任务阶段，研发是负有主要责任的，不得不小心谨慎。

三、案例分享

    分享一个我所在组内涉及到的一个复杂一些的任务案例，其实也就是围绕着上述这套核心的思想来组织实施方案，并落地的。

需求背景：
     运维侧通过监控平台，收集到“文库侧OSS容量使用率较高”的信息，信息移交到文库服务侧，文库这边着手处理......

3.1、摸清楚发生了什么，分析处理的必要性？

3.1.1、从运维侧拿到文库侧相关oss的使用数据

3.1.2、找运维策咨询·目前OSS购买套餐、计费方式、计费标准信息

3.1.3、聚焦任务范围，选取核心处理目标

围绕着这2个Bucket，对文库侧所有的服务，涉及到上传、下载、更新、删除的业务和逻辑，逐步分析，想要弄清楚，涉及到的主核心业务逻辑、代码逻辑、用户操作行为上是否可能到冗余上传的可能性。

这里就会产生很多评估行为，不能觉得麻烦而不去做，很多复杂的事情，处理周期会很长，需要做好打持久战的准备，需要把每一步走夯实，才能推动下一步，不然举步维艰。

通过业务逻辑分析、代码逻辑复查、用户操作行为测试、脚本对多存储数据源的扫描比对。

得到一个结论：这是一个值得去优化处理，且长期坚持的事情。

3.2、明确处理目标

1、堵住增量场景：优化底层存储相关的逻辑，降低增量数据的冗余存储。

2、处理存量冗余：在保业务和服务不受影响的前提下，清理OSS冗余存储。

===》最终达到：降低OSS存储开支，实现降本增效的目标。

3.3、评估影响面积

• 文库侧：

     多服务，多语言，多核心业务场景，需要咨询梳理，谨慎评估

• 其他侧：

     运维侧，测试侧，SEO侧，搜推侧，审核侧.......都需要根据具体业务逻辑走向，去收集信息&核对&评估

评估期间，梳理出了很多核心要处理的具体事项，化整为零，落地到具体子任务上，如下：

3.4、拆解任务、逐步施行落地 + 方案优化调整落地

把精力放在影响权重较大的的事情上来，做复杂的事情时，着眼全局，抓重点，抓大放小，事情才能推进的下去。

3.5、结果检测

3.5.1、分批执行，统计执行结果

四、小结一下

        很多人都不喜欢做复杂的事情，但有些事情总会落在我们身上，在无可避免的情况，一套好的处理框架，可以辅助我们在复杂的信息中，找到一条有迹可循的道路，抽丝剥茧，条分缕析，步步为营，小心翼翼，总能攻克它，以上是我的一些浅见，与君学习共勉。