不要把时间浪费在努力工作中
丰田在生产线上曾提出7大浪费，“质量返工、没用的搬运、过度生产、不增值的工艺、无谓的等待、堆积的库存、多余的动作”
丰田说的是生产线的浪费，其实，我们在经历过，工作中过程中的时间浪费。
第一种， “完美主义”
“60分万岁是个好哲学”，拼多多的黄峥曾表达过类似的观点，它不代表我们做事苟且和马虎，而是对事情有一个很好的判断。如果一件事只需要做到60分，你把它做到100分，看似非常努力，但这种努力，则要牺牲另外七八件事为代价。
另外，一旦你真的“完美”了一次，就相当于拉高了大家对您的期望，而你下一次稍微差一点，大家就会非常失望。
第二种，范围蔓延
通俗来讲，就是做了自己范围职责以外的事，比如乙方面对甲方的时候，下级面对上级的时候，很容易出现讨好的情况。
做了职场的老好人，在工作中不断让步，把自己的工作范围增加了，工作量也增加了，而这种让步，一旦迈出第一步，对方就会习以为常。
我刚出来工作时，是个“范围蔓延”的失控者，客户让我帮忙录入软件资料，没问题，录。同事让我帮忙改下PPT，没问题，改！慢慢地，自己的本职工作没搞好，反而身心疲惫。
第三种，返工
出现这种情况是很糟糕的，会非常沮丧。笔者曾经历过，为了赶一个解决方案，连续加了两天的夜班，等提交给需求方的时候，结果却不符合对方的要去。可能是之前没沟通过方案大纲，大家对于整体思路没有共识。这就意味者，需要重新返工重做。
对于上面三种情况，我都归纳为“把时间浪费到努力工作中‘，却没有产出有价值成果，要避免这种情况，我们更需要一套：敏捷工作法
敏捷工作法，核心是一种不断迭代的工作方式
它不提倡“一步到位”，它提倡持续调整、适应、逐步地达到目标。
好比有两间餐厅，一间是传统意义上的餐厅，一口气做完10道菜，然后一起上菜。这时候客户因等待的时间太长，并且饿得不行，体验非常不友好。而且，如果客户说上的菜太咸或者太辣，那么就没有调整的余地。
另外一种敏捷式上菜方式，点了10道菜，做完一道菜就上一道菜，让客户先垫垫肚子，让客户缩短等待时间，一边吃一边等，如果口味不对还可以马上调整，提升用户体验。
说到敏捷工作法，它有两个要点，“最小可交付成果、持续迭代”，最小可交付，就是上的第一道菜，持续迭代，就是后面上的一道道菜。
建立“最小可交付成果”意识
掌握敏捷工作法，首先先建立“最小交付”的意识
知识工作者不同于传统的工作者，它没有更多“实物”的载体来呈现工作成果。一项工作，你花费了很大时间、精力，但是没有呈现“交付物”，在旁人看来，你是没有产出的。
我们可以把工作分为输入、加工、输出，我们每一个“输入和加工”，都是为了“输出”。
举个例子，我们要演示"行业的解决方案"这件事，前期的搜集资料、背景调研、以及竟品分析，都是信息的输入，而当我们提炼出有效的信息，提取适应于方案部分的资料，这个阶段是加工，做到这两步，你的工作其实还未完成，你只是完成了输入和加工，我们还要把处理过的信息整合，形成一个解决方案PPT才算是“输出”了“交付物”。
这里的“交付”有两层含义，一个是输出的交付物，一个是交付的对象
在搜集资料，或者加工信息的阶段，始终要想着汇报的对象，“交付物”的接受者是谁，也就决定者我们要输出怎样的“交付物”。
为什么要强调“最小交付”呢？
我们常说，计划赶不上变化，这是因为，外部环境在变，想法在变，或者其它因素在不断变化，而我们无法在事前就100%完成规划，需要在做的过程中不断调整。就算是老板，也无法100%看准一个方向。
更多的时候，需求方自己也并没有完全想清楚自己要的是什么。笔者深有体会，比如客户说了一个目标，而里面很多细节和实现路径则自己就要搞清楚。当我们最终产出一些东西的时候，客户才知道这个是想要的，那个是不想要的。
因此，在早期的时候，我们就能给需求方看到一个初级的版本了，它“拿得出手，但不会很复杂”，它是“最可小交付物”，它可以拿来跟需求方一起讨论，用来确认最终的需求。避免推倒重来的风险。
计划交付的节点，建议是前紧后松
而在计划时间交付的时候，我们要适当的预留缓冲时间，用来应对风险。建议前面紧一点，后面松一点的工作节奏。
假如一件事，有一个月的时间准备，那么建议第一周就交付2次你的方案，根据前面两次的交付物和需求方进行沟通和确认，把整体思路定下来，后面可以一周一次迭代。
所以，当接到一项任务的时候，第一步不是向需求方承诺最终的交付时间，而是承诺第一次交付时间。
比如，当上级要求你出一份方案，更加敏捷式的回答是“我今天就去准备，明天下午班前给你一次反馈”，而不是“两个星期后我给你一份完整的方案”。
持续迭代，始终只留一只猴子
迭代，通俗点说，就是一次比一次更好的“交付“。
这里需要寻求他人的反馈，它可能来自你的老板、同事，或者你的客户。你可以把1.0版本发给他们，然后他们交给你反馈，你再进行改进。这样，你就源源不断把活交付出去，这也是我们处理多并发任务时的秘籍。
活交出去，对方就需要处理、加工、或者反馈。这个时间，你可以继续下一个活。
这样的好处，一方面，你源源不断有产出，需求方也同样处于一个合理的忙碌状态，而不是大家都等待你全部搞出来了，再进行工作。万一你憋了半天，出来的东西不是他们想要的，团队的效率就被你拖垮了。
另一方面，每一次你都是“刚好就好”的状态，你的时间没有被浪费掉。
比尔翁肯 (Bill Oncken)曾发明一个有趣的理论—「背上的猴子」，一个个任务就像我们背上的猴子，当我们处理一个任务时，就要把之前的猴子赶走，背上始终只保留一只猴子，这样才不会被累垮。
而当我们处于多项目并发的时候，我有这样的一个心得，
重要的事情多迭代，紧急的事情先迭代
比如，两个星期后要到客户现场演讲解决方案，两天后要完成项目进度计划。按照事情的四大象限划分，演讲方案属于重要不紧急，完成项目进度计划，属于重要紧急。不管先做哪个，都会惦记者另外一个。
根据重要的事情多迭代，紧急的事情先迭代的原则。可以把项目进度计划完成1.0版本，开会讨论然后发出去，听听大家的意见。这个时间，可以把项目进度计划放在一边，全力搞解决方案，接下来再根据领导的反馈，进行2.0、3.0慢慢迭代，甚至迭代到10.0。
而项目进度计划，因为本身没那么复杂，最终可能就迭代到2.0就完成了。
需要强调的是，敏捷工作法，并不提倡同时进行多任务。
我认为对于大部分人来说，在小块的时间同时进行多任务是不现实的，人的大脑是有容量的，好比电脑，同时运作5个浏览器、6个软件，7个文档，肯定会慢起来。
虽然敏捷的结果，看起来可以同时推进多个项目，但其实你是把不同项目不同版本，不断交付出去，背上始终只留一只猴子。
机械式和敏捷式管理时间的不同
时间4大象限管理法，相信大家都很熟悉了。传统的机械式时间管理办法，第一步先划分事情的重要紧急程序，然后按照顺序进行处理：先做重要紧急，再处理重要不紧急、然后是不重要紧急、不重要不紧急。
而这样的处理方式，事实上，我们可能都在处理重要紧急的事情，永远处于“救火”的状态。比如跟客户沟通方案，它是一个重要紧急的事情，比如读书提升产品设计能力，它是重要不紧急的事情，但它就要排到后面了，或者渐渐地就被忽略了。
而当我们用敏捷式的时间管理法，核心在于“版本”意识，每个阶段，都理清我们的版本目标是什么，这个版本，可能涉及的事项有重要紧急，也可能有重要不紧急，甚至有不重要不紧急。核心在于，版本的目标始终服务我们的终局目标的，而每推进一个版本，则离我们的终局目标更进一步。