《看板方法：科技企业渐进变革成功之道》-读书笔记16-第4章 在五个季度内，从最差变为最好-2
以下文章选自《无以名之》
《看板方法：科技企业渐进变革成功之道》
「20201029」今日音频
016-看板方法：渐进变革-第4章 在五个季度内，从最差变为最好-2
来自无以名之
00:00
05:39
音频内容：4.3 影响效能的因素，4.4 明确过程策略，4.5 估算是一种浪费。
4.3 影响效能的因素
当请求到达时，扎格斯会将其发送到印度进行估算。估算的规则是，必须在 48 小时内完成并返回估算结果给业务方。这将有助于业务方进行投资回报率（ROI）计算，然后决定是否要提交这个请求以进行后续处理。扎格斯每个月会和产品经理及其他相关方（stakeholders）会面一次，调整待办项优先级，并根据排序结果创建一个项目计划。
每月可以完成处理的请求项大约为7个，待办项列表中的请求项有80多个且数目还在持续增长。这意味着，每个月需要对其中70多个请求项重新进行优先级排序和重新制订计划，而这些请求项平均需要4个多月才能处理完。这是导致客户满意度下降的根本原因。不断地重新排列优先级，也意味着请求者将屡次失望。
这些请求项是通过一个称为 Product Studio 的工具进行跟踪的。该工作的升级版本，就是后来公开发行的Team Foundation Server工作项跟踪系统。有很多类似 XIT 这样的团队，虽然拥有大量的数据，但却从来不使用这些数据。扎格斯开始对数据进行挖掘，发现：一个请求项所需的工程处理时间平均是11天。但是，前置时间一般却需要125~155天。超过 90%的前置时间花在排队等待（queuing）和其他形式的浪费上了。
团队花了很多精力对加入的新需求进行估算，因为尽管声明仅是精力量级估算（rough order of magnitude, ROM），但客户却将之视为非常精确的估算，这迫使团队成员不得不做出充分准备和谨慎的估算——每个开发人员和测试人员都会花大约一天时间进行估算。快速计算一下可知：单消耗在估算上的开销，占去整体产能的 33%，甚至40%。这些产能被优先分配用于估算工作，而非编码和测试工作。另外，对新请求的估算也很容易导致该月份的既定计划被打乱。
除了变更请求，团队还要处理另一种类型的工作：产品文本变更（production text change, PTC），主要是图形与文本的修改，或一些涉及表格或 XML 文件中的数值修改。这些变更通常是由业务负责人、产品经理或程序经理来完成，但也需要通过正规的测试，因此会影响到测试人员。
PTC 工作的到达，事前是没有征兆的，通常而言，完成 PTC 工作会比完成其他工作或估算工作要快得多。但PTC工作通常是零星地分批抵达，它们也会导致该月份的其他计划变得紊乱。
图 4.3 包含粗略量级估算（ROM）和产品文本变更（PTC）输入的工作流程（图省略）
4.4 明确过程策略
该小组遵循规定的过程要求，在这个过程中，包含许多由各级管理者做出的糟糕的策略决策（policy decision）。将过程视为主导行为的一组策略，是很重要的一种视角。这些策略是由管理层来管控的。有些高层所设置的策略是很难甚至不可能改变的。但也有一些策略是由团队内部制定的，这些策略在最初实施的时候可能是合情合理的，而当环境发生变化时，却没有精力去检查和更新这些主导团队运行方式的相关策略。
4.5 估算是一种浪费
扎格斯在与同事们讨论之后决定优先实施两项管理变化。首先，团队将停止估算活动。将产能用于软件开发和测试工作。消除因估算导致的计划紊乱现象，也能提高预测性。
然而，取消估算也存在问题，这将影响投资回报率的计算，客户也可能会因此做出糟糕的优先级选择。估算是有利于方便地进行跨部门的成本核算和预算转移的。估算也被用于实施一种治理策略（governance policy）：只允许将小的请求归属为系统维护的需求；那些超过 15 个开发或测试天数的较大请求，必须作为正式项目提交立项，按项目管理办公室（PMO）正规的项目组合管理流程。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。
如果你觉得本文有用，欢迎分享给其他人。谢谢。
《看板方法：科技企业渐进变革成功之道》
「20201029」今日音频
016-看板方法：渐进变革-第4章 在五个季度内，从最差变为最好-2
来自无以名之
00:00
05:39
音频内容：4.3 影响效能的因素，4.4 明确过程策略，4.5 估算是一种浪费。
4.3 影响效能的因素
当请求到达时，扎格斯会将其发送到印度进行估算。估算的规则是，必须在 48 小时内完成并返回估算结果给业务方。这将有助于业务方进行投资回报率（ROI）计算，然后决定是否要提交这个请求以进行后续处理。扎格斯每个月会和产品经理及其他相关方（stakeholders）会面一次，调整待办项优先级，并根据排序结果创建一个项目计划。
每月可以完成处理的请求项大约为7个，待办项列表中的请求项有80多个且数目还在持续增长。这意味着，每个月需要对其中70多个请求项重新进行优先级排序和重新制订计划，而这些请求项平均需要4个多月才能处理完。这是导致客户满意度下降的根本原因。不断地重新排列优先级，也意味着请求者将屡次失望。
这些请求项是通过一个称为 Product Studio 的工具进行跟踪的。该工作的升级版本，就是后来公开发行的Team Foundation Server工作项跟踪系统。有很多类似 XIT 这样的团队，虽然拥有大量的数据，但却从来不使用这些数据。扎格斯开始对数据进行挖掘，发现：一个请求项所需的工程处理时间平均是11天。但是，前置时间一般却需要125~155天。超过 90%的前置时间花在排队等待（queuing）和其他形式的浪费上了。
团队花了很多精力对加入的新需求进行估算，因为尽管声明仅是精力量级估算（rough order of magnitude, ROM），但客户却将之视为非常精确的估算，这迫使团队成员不得不做出充分准备和谨慎的估算——每个开发人员和测试人员都会花大约一天时间进行估算。快速计算一下可知：单消耗在估算上的开销，占去整体产能的 33%，甚至40%。这些产能被优先分配用于估算工作，而非编码和测试工作。另外，对新请求的估算也很容易导致该月份的既定计划被打乱。
除了变更请求，团队还要处理另一种类型的工作：产品文本变更（production text change, PTC），主要是图形与文本的修改，或一些涉及表格或 XML 文件中的数值修改。这些变更通常是由业务负责人、产品经理或程序经理来完成，但也需要通过正规的测试，因此会影响到测试人员。
PTC 工作的到达，事前是没有征兆的，通常而言，完成 PTC 工作会比完成其他工作或估算工作要快得多。但PTC工作通常是零星地分批抵达，它们也会导致该月份的其他计划变得紊乱。
图 4.3 包含粗略量级估算（ROM）和产品文本变更（PTC）输入的工作流程（图省略）
4.4 明确过程策略
该小组遵循规定的过程要求，在这个过程中，包含许多由各级管理者做出的糟糕的策略决策（policy decision）。将过程视为主导行为的一组策略，是很重要的一种视角。这些策略是由管理层来管控的。有些高层所设置的策略是很难甚至不可能改变的。但也有一些策略是由团队内部制定的，这些策略在最初实施的时候可能是合情合理的，而当环境发生变化时，却没有精力去检查和更新这些主导团队运行方式的相关策略。
4.5 估算是一种浪费
扎格斯在与同事们讨论之后决定优先实施两项管理变化。首先，团队将停止估算活动。将产能用于软件开发和测试工作。消除因估算导致的计划紊乱现象，也能提高预测性。
然而，取消估算也存在问题，这将影响投资回报率的计算，客户也可能会因此做出糟糕的优先级选择。估算是有利于方便地进行跨部门的成本核算和预算转移的。估算也被用于实施一种治理策略（governance policy）：只允许将小的请求归属为系统维护的需求；那些超过 15 个开发或测试天数的较大请求，必须作为正式项目提交立项，按项目管理办公室（PMO）正规的项目组合管理流程。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。
如果你觉得本文有用，欢迎分享给其他人。谢谢。
