Our real problem is periods of inactivity, not slow activities.——Donald Reinertsen
产品开发思想领袖Danald Reinertsen的这句精辟的总结，点明了一个十分重要的但反直觉的“真相”：在大多数情况下，产品开发中真正的问题，并不在于干活时的“产能”不够高，而在于没有干活时的“等待”。遗憾的是，根据统计数字，98%的产品开发者，并没有真正关注和度量等待队列。
今天，你关注了吗？如果没有，请搭载本文的列车，将从生活中和产品开发中的例子出发，全面了解及思考等待队列的后果、起因、意义和应对方法。Ready？Let's Go！
生活中的例子
等待队列的例子，在我们的生活中俯拾皆是。例如：
产品开发中的例子
在产品开发中，等待队列同样无处不在。但是，让我们麻痹的是，它们并不是以某种有形的形式（例如排成长龙的人队、车队）存在，而是潜藏在我们忙碌的开发过程的背后，因而很容易被忽视。典型的等待队列存在的场景如：
等待测试的队列。从开发人员编码完成，到测试人员开始测试之间，往往存在一个等待队列，尤其是在串行工作、或角色职责界限分明的团队中。
等待沟通的队列。对于异地团队，地理的距离容易产生心理的距离，随时随地的沟通受到压制，团队成员倾向于积攒沟通内容、拉长沟通间隔，形成了带沟通信息的等待队列。尤其当远程会议室的申请也存在等待队列的时候……
等待专职角色评审的队列。在很多建立了标准化流程的大公司中，产品的很多评审（如架构、安全、部署）通常需要第3方的专职角色参与把控，申请这些专职角色的请求形成等待队列。
申请项目资源的队列。在矩阵型的项目管理架构中，项目经理需要向公共资源池的经理申请项目资源，资源池通常都不足以支撑所有项目的资源申请，这些资源申请形成等待队列。
等待队列的后果
等待队列的存在是不可避免的，但是，队列长度长、持续时间长的等待，会造成严重的后果。等待队列引起以下后果：
拉长周期时间：根据利特尔法则，当请求处理速率相对固定时，在队列中的等待时间（Queue Time）与等待队列的长度（Queue Size）成正比。
增大市场风险：随着时间的流逝，市场环境在发生变化，队列中的请求存在“腐烂”的风险，可能错失市场机会。
放大不确定性：随机发生的等待，并不会随机的自行消逝，反而很有可能急剧恶化（后面会再说明）。
增加管理消耗：举个例子，当有100个bug排队等待时，当出现第101个bug时，光是查看这个bug是否已经在前面100个中已经出现过，就要耗费很多的精力。
质量难以保证：上游环节无法得到下游环节的及时反馈，时间越长，记忆越衰减，诊断、定位、解决问题的变得愈加困难
降低人员士气：想象你在银行站立排队了2个小时，一个冗长的等待过程足以把客户的耐心消磨殆尽，而客户的抱怨又反过来让银行职员降低工作热忱。
我们再从经济上，来考量一下等待队列造成的成本损失，看看下面这个例子：
假设我们1年有8个产品，平均每个产品每延期1周会造成10万美元的损失（即”延期成本“），而我们的产品等待队列的平均长度是3周。这样一算，1年我们就会有2400万的损失！
有效的前置指标
与其他指标相比，等待队列长度（Queue Size）是一个首选的过程管理指标。最明显的一个优势是：提前预防周期时间拉长。等待队列能够最早感知系统中出现的变化，而周期时间需要滞后一段时间才能反映出来。参见下图：
在时间点21，突然来了一大批乘客，排队人数（Cumulative Quantity）迅速增长5倍，而等到时间点41，周期时间（Cycle Time）才开始增长到2倍。
因此，如果我们有效的监控队列长度，就能够第一时间掌握情况并采取合适的应对行动。如同在一些管理比较到位的超市，有专人监控现有收费通道排队人数，当人数达到一定规模时，就会临时增开新的收费通道。
产生等待队列的原因
等待队列的产生，最主要来自2个原因：
1、请求的变异性。请求到来的时间、数量、大小、复杂度都可能是随机分布且难以精确预测的，如果超市里完成购物进入收费通道的人群，这这不可避免的会在某些时间形成等待队列。
2、过高的资源利用率。资源利用率是导致等待队列的另一个决定性因素，参见下图，当资源利用率升高到一定比例时，对新请求的响应能力急剧下降，队列长度将呈指数级上升。
管理等待队列
既然等待队列造成这么多的问题，我们是否应该“秋风扫落叶”般的消灭队列等待呢？其实不然。完全的消除等待队列，从经济上并不划算。合理的队列长度，需要平衡冗余的资源成本、与等待造成的延期成本，来找到一个“U型曲线”底部的合理的平衡点。
那么，对无法避免其存在的等待队列，“既来之，则安之”，我们该如何来管理它呢？
1、可视化等待队列。累积流图（Cumulative Flow Diagram）是可视化等待队列的好工具，在产品开发过程中，建议每日更新。
2、果断而快速响应。前面提到，随机发生的等待，并不会随机的自行消逝，反而很有可能急剧恶化，因此，必须采取果断而快速的响应措施。这个道理可以参见著名的硬币实验，每扔1次硬币，正面朝上记1分，反面朝上记-1分，当你扔1000次硬币的时候，累积结果之和会趋向于零吗？实验的结果是反直觉的！
3、降低批量。大的批量会导致长、久的等待队列，因而降低批量，可以直接降低等待队列。这正是各种敏捷、精益软件开发方法所共同遵循的原则，显著区别于瀑布式开发方式下的大批量流转。
4、避免过高的资源利用率。避免设定过高的资源利用率目标（包括机器和人员），关注等待队列、关注周期时间，胜于关注资源利用率。
5、建立弹性资源池。例如，运营部门面向不同业务线的事件处理、服务请求处理人力，可以整合形成弹性资源池，来中和掉不同来源的事件、请求的变异性。
6、设定合理的队列规则。对等待队列的处理顺序，设定最经济合理的处理策略，例如优先处理延期成本高的请求、来降低市场风险。
本次列车到站。明天，你会开始关注等待队列吗？
网友评论