前言
Preface
在任何一种项目的生命周期里面，琐碎的，突发的任务是不可避免，无论我们怎么试图控制，它们都是一定会发生的，区别只是出现频率的大小和影响的大小。这是一个有很多解决方案，却未必能真得到解决的问题。
这这类任务之所以讨厌，是因为它的出现可能打乱你原来的计划，增加额外的工作量和工作复杂度，让你手忙脚乱，影响主要任务的进度。还会引发降低工作效率，降低工作积极性，影响客户满意度等连锁反应。
敏捷团队更加不喜欢这类任务，因为他们遵循1-2周一个迭代的开发节奏，出现一个突发性任务，哪怕只是占用了一个人/天，也有可能导致当前迭代目标无法完成。
正是因为琐碎的，突发的任务不可避免的发生，而且会带来负面影响，所以大家都想找出“最佳实践”去管理它，降低它带来的损失。
事实上这方面也不缺管理实践，每次在一些讨论群里抛出这个话题，总能让平时安静的讨论群瞬间热闹起来，平时不太发言的人都会冒出来各抒己见。这种时候我就会觉得很厌倦，因为每次讨论都会从七嘴八舌开始演变到唇枪舌剑和针锋相对舌战群儒，最后以大家都说累了告终。
为什么会这样？因为如何管理突发性，琐碎性任务，是一个复杂问题，根据严重程度不同，试图解决问题的人能力不同，项目所在的周期不同等等，解决方案方案会千差万别。没有普世的解决方案。脱离具体情形，你讲任何一个方法，我都能举出一系列它不适用的情形。
下面列举了一些经常发生的具体情形和解决思路：
不如不管
情景一：每一个迭代都会出现一些琐碎的突发的任务，如果大部分迭代中，突发性的任务的工作量占比不到迭代工作量的10%，大部分情况下没有影响团队完成迭代目标。时不时有团队成员觉得有点烦，但还不至于太影响团队的积极性。
情景二：一个季度中偶尔有一个或两个迭代（迭代不超过两周）突发任务比较多，导致不能完成目标，对团队效率影响较大。但其他大部分迭代的突发任务则在可控范围内。
以上这两种情形下，通过任何方法来减少这些琐碎突发任务，带来的收益都不算太大。但不管使用何种方法，都需要付出基本的沟通和协调管理成本。有时候解决突发任务或者琐碎任务，还可以帮你巩固跟客户的关系，收获一些好的反馈。
所以如果处于这两种情形，从cost/benefit角度衡量，最好的方案就是承担这些突发任务和琐碎任务。
情景三：如果日常迭代中，琐碎的，突发性的任务占比到了70%以上。
这种情形下，团队工作的主要性质是任务驱动的。如果团队在使用Scrum的话，应该立刻停止，转而采用精益看板方式来管理工作。即使有少量的计划性工作，也可以分解成任务，放在看板里统一管理。
情景四：如果在一个项目的初始阶段，那么需求变化可能比较频繁，并带来架构和技术的一些不确定性。这种时候会经常出现未预料到的工作，优先级也会频繁变化，今天重要的明天就不重要了， 甚至有些东西刚开始做就被通知方案变了要停止。
这种情形下，琐碎和突发性的工作正是我们欢迎的。敏捷方法是围绕用户痛点，通过实验性的方式让最佳方案涌现出来的过程。在实验性的初期，变化是最频繁的，也要求我们随时根据客户的反馈抛弃已有的观点和计划，形成新的观点和计划。
每一次变化和突发，都是确认了“什么不是客户要的”，离“什么是客户最终要的”更进一步的过程。 随着最合适方案的逐渐浮现出来，这种突发和琐碎的任务是逐渐减少的。
如果你希望项目开始时一切都是确定的，客户签字同意，不会改动，团队可以按部就班往下做，没有什么突发的变化， 那么这种传统项目管理方式，结果会是什么样我们也都知道。
如果你的情况不属于上面四种情形之一，那我们可以讨论一下一些通用方案了。
敏捷方法中的“优先级排序&短迭代”的设计就是为了减少琐碎突发性任务对团队效率的影响。
“优先级排序“和”短迭代“要同时具备才能最大限度发挥威力。一个琐碎的或者突发的任务，如果能被排在待办事项中优先级较高的位置，下一个迭代就能开始做，而且下一个迭代最长两周后就能开始，这种安排被客户接受的可能性会大大提升。
而且当你的突发紧急任务越多，那意味着你应该选择更短的迭代时间，提升客户愿意等到下个迭代的几率。
还有一种常见情形，就是研发的团队常年处于一边开发，一边修生产环境上的突发bug的情形，工作计划总是被bug打断。
根据我们上面所列的方法， 如果修bug的工作量占比不到10%，或者bug集中爆发的迭代平均每个季度只有一次，那就接受，因为试图避免的成本更高。如果修bug工作量占比70% 以上了，就要切换到看板。然后维护待办事项良好的优先级排序，选择合适的迭代长短，也可以减少一些不紧急的bug对当前迭代造成的困扰。
如果是根据经验长期有琐碎突发任务，并且对团队专注度和效率造成影响了，就一定要在sprint planning的时候留好buffer，不要过度承诺。
所以，应对琐碎的突发性的任务时，要从其发生的频率，项目所处的阶段，对团队实际影响的大小等多个纬度进行评估，然后决定是选择接受，控制，还是与之共舞。
另外，还可以在团队内部单独拨出一个员工，专门处理琐碎的突发的工作，其他人聚焦在迭代目标上。关于这个建议，我分享过几次，一般会收到以下后续的问题：
问：迭代中琐碎和突发任务不够1个人的工作量怎么办？
答：在这个人在完成琐碎任务或突发任务的间隙，如果有空闲，可以从看板上捡一个Story来做。但是这要基于他自己对工作量和是否影响他的工作效率的判断来决定，别人不应该建议或者命令他做多少任务。
问：拨出一个人来处理琐碎突发任务，影响这个人在主要业务上的学习，或者觉得不受重视怎么办。
答：这其实是一个角色，团队成员可以轮流承担这个角色，按迭代轮换或者按月轮换。
问：琐碎和突发任务可能需要多种技能，单个成员只具备一种技能，很少有人能独立应付各种突发任务怎么办？
答：一边灵活应用上面所列的各种情景下的解决方案适当减少迭代过程中的突发任务，一边提升团队成员的技能多样性，一边忍耐琐碎突发任务的骚扰。
问：短时间无法提升团队成员的技能多样性怎么办？
答：走不了就忍着
在回答这类问题的过程中，我发现不管你出什么样的方法，总有人问那如果xx怎么办。
类似的情况还有讲到和PO或者干系人沟通的话题时，即使列举了一堆可行的方法解答了大部分的疑惑，最后总有人会问“如果他就是不配合怎么办？”。讲激励团队的办法时，最后也总有人问“他就是不受激励怎么办”？
排除猎奇心理，这种不断的提出意外情况，问有没有其他方法的的人，主要是在之前讨论中没有找到适合自己的方案。
我经常会遇到那种问能不能介绍一个适合自己情况的办法。其实他们寻找的的“适合自己”，需要满足以下三点：
1:根据自己的问题的具体上下文定制的。
2:在自己能力范围内能实施的。
3:满足前两点的前提下最好能再简单一点的。
如果不满足这三点的方案，对听众的潜意识就会觉得不太适合自己，就忍不住继续追加一些场景问解决方案，甚至一直问到极端的，几乎很少发生的情况。
但是人遇到的困难，往往是一面镜子，反应的是个人能力的不足。所以你觉得简单，轻易能做到，愿意去接受的方法，往往不能帮你解决问题，真正能解决问题的方法，一定是你听起来不那么舒服的，不那么容易做到的。
有效的方法是需要提升能力来驾驭的。
举个例子，上面列“优先级排序&短迭代”的方式经常被一些咨询师提起，但是它背后涉及到去跟干系人沟通，晓以利弊，把不紧急的适当推后，关键时候Say No这些讨价还价的过程。
这个方法提升了干系人接受你建议的程度，而不能保证他们会每次都接受。方法能起多大作用，还取决于具体的干系人对这种任务的态度，对团队的态度， 以及，重点是，你的沟通能力能多大程度上改变他们的态度。
上面列举的边修bug边开发的团队例子也很常见，虽然我给了解题思路，但是效果有限，突发bug的根本还是质量问题或者历史遗留问题，没有能力解决根本问题，也没有什么方法能管理他们的突发任务。
你看，方法很多，但未必有合适你的方法。人们追问适合自己的方法，这种态度让我觉得厌倦和浪费时间。
我喜欢选个看起来有道理的方案， 思考一下自己落地这个方案的话困难在哪里，然后静下心来尝试解决这个困难。
管婷婷，敏捷教练。关注公众号，阅读更多作者在敏捷，DevOps，敏捷绩效，企业管理等方面等观点。
网友评论