快速前进！但如何做到？映射您的产品开发过程如何帮助您打造一个高效能的组织 云企业战略博客
更快的前进方法：通过映射产品开发流程来提升组织效能
作者：Tom Godden，发布于2022年10月4日
主要要点
产品开发流程的映射有助于组织提升效率。清晰的目标及客户导向是高效开发的关键。消除浪费和不必要的流程，以达到快速迭代。推广自动化工具和自主团队操作以减少协作瓶颈。如何成为一个高效能的软件组织？仅仅通过实施新的工具来管理你的持续集成/持续部署/持续测试CI/CD/CT流程是不够的。这就像是把学会骑自行车的技术搬到F1赛车一样，无法奏效。真正的改进需要新的思维方式、新的能力，并且需对产品开发流程的敏捷性进行转变。首先，你需要清楚知道自己当前的位置，然后通过使用新工具和创建新行为来简化你的流程。
目标是形成一个强大且以客户为中心的产品开发周期，无缝地结合产品负责人、利益相关者、工程师以及质量专家和合规性团队的努力。当这一过程运行良好时，组织可以在高速度下专注于质量和价值交付。
开发流程图
价值流映射VSM最初是为制造业和精益生产/六西格玛开发的，但它在理解软件开发中的产品流方面也十分有效。VSM的目标是通过理解每一步的角色来优化整个开发过程，然后进行优化，在满足客户价值需求的前提下，尽可能地减少资源时间、成本和人力的使用。
第一步：反向工作
首先明确你想要解决的问题或挑战。你的目标是什么：希望更快速？提高交付速度？客户是否担心质量或新功能的发布速度？让你的新流程明确地针对这些需求来设计。
第二步：绘制当前状态图
从新想法经过批准、设计、开发、测试、构建、发布、部署到运行及事件响应，将整个产品开发过程绘制出来。你应该有足够的详细步骤来提供清晰度，但也要注意效率；通常二十到二十五个步骤是比较理想的。但要避免过于细化或过于简化。
在绘图中包括以下内容：
所有控制点和合规审查与批准如安全和监管项目审查委员会PRB，负责批准新想法并分配项目资源协调更大范围部门协作的投资组合审查定期状态报告交付物变更控制委员会CAB，管理产品的生产过程架构审查委员会ARB，负责批准新设计、新架构以及新技术其他检查点或签字针对每一步骤，识别以下内容：
启动步骤的请求者或发起者如客户、产品开发或软件工程输入的内容如工作产品、文档或票据信息负责完成步骤的角色/人员所执行的工作类型如决策/签字、活动或控制该步骤的输出，包括根据通过/失败可能的后续步骤
创建包含这些信息的价值流图，然后在寻求进一步优化的过程中增加细节；例如，捕捉完成每一步所需的时间以及步骤之间的时间。映射开始后，快速改进是完全可能的。我发现使用简单的泳道图来映射各个角色的步骤流非常直观、简单且容易被接受。
我们的感知和目标往往并不反映现实。确保你并非根据自己的愿望或期望来捕捉当前的状态，而是基于真实的观察。这通常需要通过多个利益相关者的观察、收集不同观点和偏差，来建立共识。
第三步：识别并消除浪费
当当前流程图准备好后，你可以开始找出流程中的浪费。目标是通过减少或完全消除添加浪费的步骤，或以新的更有效的方式完成必要的步骤来提升产品开发的有效性。
消除不必要的步骤每一步在未来的方向下是否仍然必要？这一过程中是否存在历史遗留的步骤已不再需要？也许这步骤在以往需要购置和安装硬件时是必要的，又或者当时与特定GSI伙伴合作时才需要。
鲤鱼加速器每天签到消除交接交接会导致很多低效。在亚马逊，我们努力通过自给自足和自主的两披萨团队来最大限度地减少交接。当团队无需协调工作时，就能消除误解的可能性，从而减少缺陷的产生。此外，当不需要团队之间的协作时，工作流程可以不受阻碍地进行。这意味著你不再需要依赖虽然出于好意但最终是失败的投资组合规划会议来协调工作。
如果可能，通过让发起团队尽量执行更多工作来消除交接。有时候这仅仅意味著允许A团队执行第四步和第五步，而以前他们并不被允许执行第五步。有时则意味著通过自助方法让A团队执行第五步，但B团队依旧保持控制。这可能是基于管理范围的问题。最终，这一能力也可以自动化，让前一步完成后，自动执行此步骤。
什么可以自动化？几乎每一步的产品开发流程都可以受益于某种形式的自动化，无论是完全集成的DevSecOps管道自动构建、测试和部署代码，还是通过基础设施代码来采购新的实例。
向左移动发现问题的最昂贵且具破坏性的阶段往往是在流程的末尾，但这通常是组织投入资源进行最终监督和进行安全合规性审查的地方。高效能组织会在流程的最早阶段进行这些控制步骤并将其与开发过程整合。例如，预配置的实例类型可以在为一个通用映像时已设置安全设置。
对于其他需要进行验证的控制，目标是在流程中寻找可以应用控制的最早时期。例如，如何重新构思需求流程，以同时满足工程团队和合规团队的需求？如何重新思考测试和测试矩阵以确保测试是否能为合规团队提供所需的证据？
消除监管委员会我曾经建立并领导过不少的PRB、CAB和ARB。它们都有良好的意图，但我不确定是否真的达到了最初的目标。在当今敏捷的产品开发流程中，这些会议通常会拖慢进度并增加额外的工作量。
我使用的一种良好方法是，与团队一起在CAB、PRB或ARB会议结束时提出我们为什么需要这个会议，我们未来有什么可以改变的地方，以免赖上这次会议？ 结果会产生一个需要解决的问题清单，帮助你消除会议的必要性。这可能需要对产品开发流程进行进一步的精细调整，帮助人们增强对发布管理的信心，或者让大家意识到不需要让所有人都了解计划中的所有发布。
通常这些会议是过去做法的保留，存在只是为了让人感到安心。问问自己最近有多少次变更在CAB上被拒绝？我猜不常见。CAB曾经是为了协调大型发布，因为当时软件是按照大型单体架构设计的，这样的发布范围是很大的，因此需要大量的测试和计划。如果你的组织使用微服务和API进行所有操作，且应用程序编程接口API具有保证的合同，则CAB通知其他团队即将发布的必要性将大幅降低。
绘制新流程
一旦你评估了价值流中的每一步，将你的新产品开发流程绘制出来，并开始制定实施计划。实施某些新的自助服务步骤和必需的自动化，可能需要经过数个步骤。花时间培训人们掌握流程，桌面演练是一种很好的做法，既能教学，也能很好地发现流程仍可进一步改进之处。
你应持续检查你的产品开发流程，因为任何流程都会随著时间而衰退。定期进行，以确保：
人们遵循流程流程按设计运行充分利用任何新技术或控制方式所带来的进展标签：敏捷、最佳实践、文化、数字转型、入门指南
Tom Godden
Tom Godden是亚马逊网络服务AWS的企业战略家和宣传者。在加入AWS之前，Tom曾担任Foundation Medicine的首席信息官，帮助建立世界领先的FDA监管癌症基因组学诊断、研究和患者预后平台，以改善疗效并推动下一代精准医疗的发展。Tom还曾担任Wolters Kluwer的多个高级技术领导职位，拥有17年以上的医疗保健及生命科学行业经验。Tom拥有亚利桑那州立大学的学士学位。
