这里一共提到3个原则：分别是化难为易、化整为零和化繁为简。
什么叫化难为易，就是将困难的任务转化为相对容易的任务；在讲化难为易之前，我们先分析下困难是什么。
简单说：困难是因为当事人当前的认知、能力不具备理解和解决具体问题的条件而造成的。有人会说，可能还会有环境不具备，流程不合理、资源紧缺、时间太紧张等各种客观原因啊，你应该考虑这些客观因素啊。但其实在我看来，困难只和当事人的认知和能力有关，和其他无关；因为当事人是可以通过沟通、协作和管理将所有的客观原因都解决掉的，而这些因素都解决掉，这个问题就会成为容易的问题了吗？也许会，也许不会。所以，我们定性一个任务困难并不是因为它所需的客观条件不具备，而是因为人的认知不具备，我们或者不能解决它需要引用外部力量；或者虽然能解决，但是很低效或者成本高昂。
这里我们不讨论那种即使依靠外部力量也解决不了的困难，那是天灾我们只能尽量绕开。我们只探讨如下两种困难：
一种是我们引用了外部力量就可以解决的困难，那么我们需要做的事情至少是管理好它，控制好它，比如我在之前的一家公司，公司有一个项目要做，一开始没有开发资源，那怎么办，找外包呗，我负责验收，那我怎么验收呢，第一步，先收源码，我搭建了svn，让外包的同事将源码传到svn；第二步，因为我们的项目是app，移动端和后台全都外包，需要联调工作，那我买了一台阿里云服务器，搭建了联调环境；第三步，为了帮助他们快速部署，我又部署了jenkins，配置了持续部署任务，帮助他们把后台服务及时部署到阿里云服务器；第四步，我们重新过需求，针对核心业务流程重构了测试用例，并请外包的同事进行了确认，达成了验收标准。这样我用环境、工具和流程基本形成了一套闭环可以反复迭代，只要我确认svn的代码经常有更新，jenkins的部署任务在执行，联调环境服务日志在滚动那么就可以知道对方有在正常工作；如果他们通过了我们的测试，那么他们的工作就可以交付，而且因为源码都在我们的svn服务器，那么我们不仅确保了源码在我们手里，而且源码的变化我们也都很好控制起来，另外这套系统经过了基本的验收测试，质量上也就有了一定保证。
还有一种困难是那种虽然能解决，但是很低效或者成本高昂，对于这种困难，其实我们可以持续优化我们的解决方案，不断提高效率和降低成本。我们可以通过观察、沟通、学习、实践、分析、总结等各种手段加深我们对这个困难的问题理解，千方百计地去提高效率和降低成本。一旦我们对问题的认识更加深刻，那么任务至少会相对变得容易。
接下来讲什么叫化整为零，从字面上理解就是将一件任务分解为多个任务，并行推进。具体操作上，有两种分解方式：
1、按照结构拆分，整体拆成部分。当我们面对一个整体任务的时候，它的复杂度、难度都很难评估；但一旦它被拆开成不同的子任务，那么每个子任务的复杂度和难度都会相对降低，且不同类型的任务也会对具体执行人有不同的能力要求，这样，我们就可以按照子任务的复杂度、难度和对具体执行人不同的能力要求，重新调配资源，将每个子任务分配给适合的人去做；比如我们在手机客户端研发项目中，经常会将开发团队分为至少两个部分，一部分同事专门做手机客户端，一部分同事专职做后台服务，他们其实就是按任务类型进行的分工，这种分工本质上是基于工程师掌握不同领域的技能进行的分工，是社会化分工不断细化在软件研发流域的一个体现；至于再如何基于难度和复杂度进行分工，这个就涉及到具体工程师的级别和职责了。
2、按照阶段拆分，将一个整体目标拆分成若干个分目标；比如一个普遍的现象：很多人觉得任务太难了完不成，于是产生了焦虑心理，只好选择暂时逃避，明天再做吧。明日复明日，一拖再拖；而一旦把任务分成比较容易的小块，化整为零，降低任务难度，推迟自己要放弃的心态，则每天能完成更多的任务。有段时间我很喜欢去健身房跑步，一般是跑40分钟，其实我刚开始跑得时候，很难坚持下来。后来我找到一种办法，就是我把40分钟的目标，分解成两个阶段目标，第一个目标就是我要先跑20分钟，第二个目标就是我要跑完后续的20分钟，当我在前一个阶段的时候，我会想我已经跑了多少分钟，马上就要20分钟了，就能实现自己的目标，放弃可惜；当我跑完第一个20分钟的时候，我会不断对自己说我还剩多长时间就可以跑完全程了，放弃可惜。就这样，我通过设置两个阶段性的小目标，并且在不同的阶段运用不同的策略进行自我驱动最终实现了自己的大目标。
最后我们来讲一下化繁为简，即把复杂的事情化解为简单的事情。
我理解的复杂事情主要是指两种，一种是需要协作，不能一个人独立完成的工作，有时是外部协作，有时是内部协作，对于这种事情，我们可以通过明确岗位职责、划分分工界面，约定交付物标准和交付周期、建立沟通机制的方式来解决，一旦这个机制建立，并且运作良好，那么无非就是大家各自做好自己的事情即可。还有一种复杂的事情，是不需要协作，只是系统流程冗长，步骤繁多，细节琐碎的事情，这类事情在我们系统开发过程中可谓比比皆是，比如我们需要在表里增加一个字段，那么我们需要配套的代码改动包括调整持久层代码、业务层代码、控制器代码和前端代码，这些改动分布在代码各层，改动起来不难，但是颇为繁杂；还有就是我们的开发活动，往细了再分就是修改代码，编译，编译、单元测试，测试成功后要做集成，集成后要打包部署到联调环境、测试环境等，显然开发活动本身就是一个复杂的事情，那么我们如何化繁为简呢，我的原则是当这个事情一旦是一个需要频繁执行事情的话，那我就会把这个事情的处理尽量流程化、流水化、自动化；比如引入自动化测试，比如引入jenkins做持续集成、持续部署等等。
一件事情复杂，并不能简单表明你需要付出很高的工作量，它们之间没有必然联系，你需要通过仔细地分析找出出哪些部分才是你真正需要投入时间去完成的工作。这里可以参考基于协作的一种工作分类方法基于协作的一种工作分类方法。
评论区