为你的组织设计自己的障碍消除流程【荐】.pdfVIP

为你的组织设计自己的障碍消除流程 许多精益主张的支持者是从关注浪费和消除浪费开始入手的。这至少要面临两大挑战： 第一，浪费的定义来自于20世纪生产行业，在精益软件的著作中一直沿用未做任何修改。 第二，浪费的暗喻手法由汽车制造业迁移到当今的知识性工作中也比较牵强，不太舒服。 如果在团队和组织工作中执行敏捷-精益方法，可以帮助你更好地关注以下的两个基本 问题： 1.你的团队和组织是用怎么样的流程来开展工作的？ 2.什么阻碍了工作的流程？ 本文主要关注的是第二个问题，以及如何去处理这些工作流程中的障碍。 在你的团队或组织中有没有以下类似的问题？ 你们发现自己总是在一遍一遍重复着相同的问题 你们发现正在反复地解决相同的问题 你们发现思考的问题只不过是一种表面现象 你们无法把控团队的速率 看上去要很长的时间才能解决这些问题 翻来覆去地变 尽管很努力，但缺陷率却仍在扶摇直上 特性的研发速率随历次的发布逐渐衰减 大家普遍对现状不满，却又没人采取行动 以上种种都暗示着你的团队和组织中出现了障碍。 精益产品开发关注的是系统端到端的工作流程。与其关注类似于产能使用率这些传统的度量，关 注工作在体系中如何开展会更加有效。时常听人提起消除障碍以完成到敏捷的转变。我发现这其实没 有太大的帮助。首先，过渡到最终状态是一种根深蒂固的错误观念；其次，这把焦点集中在了敏捷（或 者精益，或者两者都是）上，而不是业务目标上，比如为客户交付满意的产品和服务。我宁愿集中精 力去消除流程上有价值的障碍。为了做到这一点，就需要慎重、仔细地设计消除障碍的流程了。 1. 简介 梅里亚姆 ·韦伯斯特字典里对障碍有如下的定义：使某事难以去做或难以完成的任何事；妨碍活 动或流程的某些事。换句话说，障碍是妨碍流程的某些事。 我们先来看看工作在团队和组织体系中是如何运转的。当我首次关注精益并应用精益原则时，就 觉得把精益中浪费的概念直接套用到软件开发领域有些不对。这并不意味着消除浪费不重要，问题在 于，首先要承认在现代像软件开发之类脑力工作中浪费的界限并不明晰，它不像工业生产线和其他的 领域。 我发现为提升效率去关注工作流程是件非常自然的事，而不是总是刻意地去找出浪费和消除浪 费。从这个角度来看，有两个主要的问题。第一个问题是 “在我们的体系中是工作如何流转的”？对 于大家来说，流转图能够看清每个环节，它比那些仅仅存在于名义上的岗位职责会更加地清晰明了。 跨组织的管理者和领导者可以共同来创建这张图。第二个问题是“贯穿整个体系的工作流程有什么障 碍”？或者，换个问法， “工作流程中还有哪些改进的空间？” 至少从2010年开始，我的工作就遍布在世界各地了，主要分布在南美、欧洲、以色列、印度和 中国，在这些工作的过程中我深刻理解了工作中的障碍，并找到了解决的办法。我不仅是一个全球性 公司的全职员工，而且还取得了一个博士学位，重点研究对流程的理解和团队与组织中的障碍。非常 幸运的是，我的研究能够直接应用于我所在的团队和组织中。基于刊物和会议上的资料，我对此有了 全新的认识，并将它们写到了我的研究报告中。 2. 障碍的管理 2.1 障碍的认识 敏捷团队对此有着得天独厚的优势，因为在这个方法中涉及频繁的交流仪式和经常性的反思。 每日站立会。每日站立会是提出障碍的绝佳场合。举例来说，类似于日常性的Scrum“三个问题” 可以调整成有关障碍的询问。 Scrum-of-Scrums。当多个团队共同协作来处理一个大型问题时，关注障碍会给予你们非常大的 帮助。 回顾会。回顾会是一个不错的讨论场合，但它也容易形成一种定式。团队通常在回顾会中会陷入 到同一种形式中。总重复一种模式 （比如按常规的节奏重复单调的形式）会阻碍我们检视环境和探测 模式的能力：如果我们总是用一种方式去检视体系，那么意识上就容易麻痹，在问题出现之前无法发 现那些微弱的信号。大脑喜欢接收新奇和刺激的事物。我们要利用这一点更早地发现障碍。 自我评估。自我评估能够帮助团队识别障碍的来源。通常，障碍不会直接识别出来，而自我评估 能够暗示团队应该要引起警觉好好分析一下了。他们可以使用那些实践中的欠缺和记录下来的问题有 所关联的信息。 调查。调查是另一个很有用处的工具。我们直接用调查去发现组织中的障碍和导致障碍的原因。 自我评估在本质上更多的是定量分析，专注于特定的敏捷和精益实践