《看板方法：科技企业渐进变革成功之道》-读书笔记15-第4章 在五个季度内，从最差变为最好-1
以下文章选自《无以名之》
《看板方法：科技企业渐进变革成功之道》
「20201028」今日音频
015-看板方法：渐进变革-第4章 在五个季度内，从最差变为最好-1
来自无以名之
00:00
05:10
音频内容：第4章 在五个季度内，从最差变为最好，4.1 问题，4.2 可视化工作流程。
第4章 在五个季度内，从最差变为最好
2004 年 10 月，扎格斯・杜米特（Dragos Dumitriu）是微软公司的一名程序经理。他刚接管一个在微软公司所有 IT 部门里口碑最差的部门的工作。
微软公司的“程序经理”一职，很像其他公司的项目经理，而且通常还需要承担分析和架构方面的一些职责。程序经理会被安排到一些刚起步的项目或产品上，负责一个特性或一级特性的开发交付。为了完成工作任务，程序经理会从开发和测试等职能领域招聘新的成员加入团队。扎格斯的团队负责 XIT 事业部的软件维护工作。团队的主要成员来自印象一家评级为 CMMI 5级的供应商，包括 3 名开发人员、3 名测试人员和 1 名当地管理人员。他们负责为 80 多个跨职能的 IT 应用进行小规模升级开发和产品缺陷修复的工作，这些应用供微软公司全球员工使用。
4.1 问题
扎格斯是主动申请负责带领这个团队的。作为变革推动者，他决心解决前置时间过长以及团队目标设置方面很糟糕的问题，但他的工作颇受公司内部政治气氛的约束。该职位的几位前任程序经理，仍是同一个业务部门内的同事，只是在负责其他项目的工作。他们也有顾虑，一旦该团队的交通在扎格斯的领导下得到提升，就会显得他们的能力不足。
当时，微软公司在合同中明确要求，为微软公司工作的程序员和测试人员都要遵循软件工程研究所（SEI）的个人软件过程/团队软件过程（PSP/TSP）方法。这意味着，扎格斯想要改变使用的软件开发生命周期方法（SDLC）是不可能的。
扎格斯意识到，无论是PSP/TSP方法，还是供应商的CMMI 评级，都不是问题的根源所在。事实上，该小组的产品并不比所要求的少，而且质量也很高。然而，他们的变更请求（change request）前置时间却长达 5 个月，随着请求待办项列表（request backlog）堆积的越来越长，情况逐渐变得不可控制。外部对这个团队产生一种成见，认为这个团队的组织和管理十分糟糕。因此，高层管理人员也没有意向提供更多的经费来解决这个问题。
变革受到来自政治、财务和公司政策等多方面因素的制约。于是，扎格斯来征询本书作者（大卫）的建议。
4.2 可视化工作流程
大卫要求扎格斯画出工作流程图。图4.2 是 XIT 维护工程：最初的工作流程，展示了所需的前置时间。（图省略）
请求的到达是不受控制的。4名产品经理分别代表各自的客户并负责控制预算，这些客户是 XIT 维护的应用软件的所有者。他们会提出新的请求，包括遗留的（在使用现场才发现的）产品缺陷。这些缺陷是应用程序开发团队在产品开发过程中产生的。新系统发布一个月后，这些应用程序开发团队一般都会解散，而源代码则转交到维护团队手上。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。
如果你觉得本文有用，欢迎分享给其他人。谢谢。
《看板方法：科技企业渐进变革成功之道》
「20201028」今日音频
015-看板方法：渐进变革-第4章 在五个季度内，从最差变为最好-1
来自无以名之
00:00
05:10
音频内容：第4章 在五个季度内，从最差变为最好，4.1 问题，4.2 可视化工作流程。
第4章 在五个季度内，从最差变为最好
2004 年 10 月，扎格斯・杜米特（Dragos Dumitriu）是微软公司的一名程序经理。他刚接管一个在微软公司所有 IT 部门里口碑最差的部门的工作。
微软公司的“程序经理”一职，很像其他公司的项目经理，而且通常还需要承担分析和架构方面的一些职责。程序经理会被安排到一些刚起步的项目或产品上，负责一个特性或一级特性的开发交付。为了完成工作任务，程序经理会从开发和测试等职能领域招聘新的成员加入团队。扎格斯的团队负责 XIT 事业部的软件维护工作。团队的主要成员来自印象一家评级为 CMMI 5级的供应商，包括 3 名开发人员、3 名测试人员和 1 名当地管理人员。他们负责为 80 多个跨职能的 IT 应用进行小规模升级开发和产品缺陷修复的工作，这些应用供微软公司全球员工使用。
4.1 问题
扎格斯是主动申请负责带领这个团队的。作为变革推动者，他决心解决前置时间过长以及团队目标设置方面很糟糕的问题，但他的工作颇受公司内部政治气氛的约束。该职位的几位前任程序经理，仍是同一个业务部门内的同事，只是在负责其他项目的工作。他们也有顾虑，一旦该团队的交通在扎格斯的领导下得到提升，就会显得他们的能力不足。
当时，微软公司在合同中明确要求，为微软公司工作的程序员和测试人员都要遵循软件工程研究所（SEI）的个人软件过程/团队软件过程（PSP/TSP）方法。这意味着，扎格斯想要改变使用的软件开发生命周期方法（SDLC）是不可能的。
扎格斯意识到，无论是PSP/TSP方法，还是供应商的CMMI 评级，都不是问题的根源所在。事实上，该小组的产品并不比所要求的少，而且质量也很高。然而，他们的变更请求（change request）前置时间却长达 5 个月，随着请求待办项列表（request backlog）堆积的越来越长，情况逐渐变得不可控制。外部对这个团队产生一种成见，认为这个团队的组织和管理十分糟糕。因此，高层管理人员也没有意向提供更多的经费来解决这个问题。
变革受到来自政治、财务和公司政策等多方面因素的制约。于是，扎格斯来征询本书作者（大卫）的建议。
4.2 可视化工作流程
大卫要求扎格斯画出工作流程图。图4.2 是 XIT 维护工程：最初的工作流程，展示了所需的前置时间。（图省略）
请求的到达是不受控制的。4名产品经理分别代表各自的客户并负责控制预算，这些客户是 XIT 维护的应用软件的所有者。他们会提出新的请求，包括遗留的（在使用现场才发现的）产品缺陷。这些缺陷是应用程序开发团队在产品开发过程中产生的。新系统发布一个月后，这些应用程序开发团队一般都会解散，而源代码则转交到维护团队手上。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。
如果你觉得本文有用，欢迎分享给其他人。谢谢。
