- Dumitriu 和 Anderson 在与管理层和客户经理的讨论中坚持放弃 ROM 阶段。这些计算是在实施之前立即进行的，并且由同一个承包商进行，也就是说，它们仍然是“新鲜的”。
- 请求的优先排序不是在每月的会议上进行的，而是通过电话或电子邮件临时进行的。积压任务中的 80 项按照客户进行排序。后者被要求强调需要首先完成的主要请求。
- XIT 资金已经固定。
- 不再考虑请求的成本。
- PM 在看板上引入了缓冲区。开发人员从两个区域获取工作：已批准的任务和已完成的任务。缓冲区中有 6 个请求，其中 5 个已被处理。从“等待测试”缓冲区中选择的测试人员。一些不需要更改代码的任务绕过了开发人员。通过将请求分解为单任务流程，产品经理能够更好地控制情况并为客户提供透明度。缓冲区的引入减少了前置时间。在可预测的系统中，客户可以更好地确定下一个应该缓冲谁的请求。
- 对于过大或过昂贵的请求，会立即做出决定。如果开发人员确认他准备在 15 天内完成任务或这些更改值得，那么无论请求规模或成本如何，都会被纳入工作。
- 在观察了部门内的流程后，产品经理得出结论：应该改变人员结构，以有利于工作负担更重的开发人员。变动是按照 2:1 的比例进行的：4 名开发人员和 2 名测试人员开始在 XIT 工作。
截至2005年底，该部门的生产效率提高了155%。
为了进一步提高 XIT 的性能，我们雇用 西班牙 whatsapp 号码数据 了两名员工：一名开发人员和一名测试员。积压的请求数量下降到 10 个，并且一名开发人员开始每季度持续处理 11 个请求。平均每季度完成 56 个请求，而之前为 11 个。请求成本从 7,500 美元降至 2,900 美元。
在 Corbis 中的应用
在微软取得成功后，安德森于 2006 年开始应对新的挑战。现在他在尚未离开微软的比尔·盖茨的另一家公司Corbis任职。 Corbis 的活动之一是授权照片。当时，它是世界上第二大照片库，数据库包含约 3500 张照片。
安德森的工作是加快公司主要产品的发布。他们的发布间隔为三个月，甚至可能更长。仅讨论发布计划就花了管理层两周时间。有必要制定每两周发布一次小版本或更新的时间表。同时，必须将关键资源投入到主要项目的工作上。
Corbis 办公室里出现了一块看板，安德森每天都在这里与团队进行对话。 PM 的目的是提高对流程的视觉控制，促进自我组织和表演者的更大个人责任。看板系统还旨在减少管理监督并提高生产力。
除了五颜六色的卡片和图表外，板上还出现了一个“垃圾桶”——太大的任务就会被扔到里面。
图片来自官方介绍
David J Anderson 撰写的《软件系统 您发帖的目的和基调是什么 持续工程的看板系统》
看板系统可以清楚地显示流程何时不再顺畅以及何处发生了延迟（即所谓的瓶颈）。与团队的快速讨论有助于确定当前的问题。例如，测试持续了 3 天，这对发布日期产生了负面影响。三名员工齐心协力，找到了将时间缩短至一天的方法。
瓶颈是公司工作流程或算法的一部分，其中资源或人员的生产力限制会大大降低任务流的吞吐量。
工人短缺、网络不佳或主管休假都会阻碍或减慢任务的完成
看板卡的限制是根据经验设定的两次。在“准 白俄罗斯商业名录 备开发”一栏中，限制已经增加。还有一个新的专栏——“准备测试”。许多下游查询措辞不当，造成不必要的时间浪费。因此，PM调查了上部流程的运行并发现了错误。
处理请求可能需要 100 天，但仍然会按照计划每两周发布一次。关于该期刊内容的决定是在出版前5天做出的。就像微软的 XIT 部门那样，计数的做法被放弃了，以提高生产力。根据“延迟成本”或资源可用性对任务进行优先排序。
看板系统不仅帮助安德森实现了目标，还改善了团队的情绪。通过联合讨论和流程可视化，员工们彼此之间建立了信任。工作人员还了解了“改善”（kaizen），即持续改进的实践。