|
想要大规模推广敏捷模式，企业就要打破业务部门与IT部门之间以及内部各自为政的状态。事实上，多数企业都长期深受此问题困扰。但其实，公司可以指定具备专业知识和权威的优秀产品负责人为敏捷组长，让他们与I T 人员合作，为产品功能做优先级排序，从而实现更加高效、紧密的合作。 在多数传统企业，来自业务部门的敏捷组长只会偶尔参与软件开发，按需提供帮助。为了弥补这一人手不够的情况，IT部门往往会指定一名本部门员工作为敏捷组长。这种安排在短期内或许有效，但长期来看只会起阻碍作用。由于组织架构的限制，IT部门的“敏捷组长”很难近距离接触用户，并且也没有决策的权限或威望。由此造成的方向不明、优先次序不清晰和问责制度缺失，会导致敏捷开发停滞不前，而团队也将面临大量的返工与浪费。 相比之下，优秀的敏捷组长对产品有着深刻的理刻，他们能接触客户、了解客户，并可全权作出决策。高效的决策流程能够消除开发阶段的瓶颈并提高生产力。 某家SaaS(软件即服务)供应商，曾面临产品难以及时交付的问题。当时，决策流程明显滞后，IT部门与业务部门之间也缺乏清晰的沟通路径。2 0 1 4 年，公司采用了三层架构:一名敏捷部门领导管理整个产品业务;一名敏捷项目经理管理其中一条产品线;数名敏捷组长与Scrum团队分工协作。新结构加强了IT部门与业务部门之间的互动，沟通路径也变得更加清晰。公司决策速度加快，各产品开发团队内部以及彼此之间也沟通顺畅、合作协调。结构调整后，公司每季度都能推出新产品，有时还会逐月推出。而此前，公司每年只能推出一到两款新产品。 3.重新定义管理人员的角色与责任 在麦肯锡调查的企业中，约有一半都调整了管理人员的角色与责任，以凸显敏捷模式的优势。在瀑布模式下，项目经理需要协调各应用开发团队和数据库团队的一系列任务。而在敏捷模式下，任务的数量(以及对协调的需求)被降至最低，仅存的任务会由权责明确的敏捷组长或敏捷团队自行处理。同样，此前由项目经理负责的流程管理任务(如发现和解决依赖问题、任务分配等)，则会由专注于产品的、自组织的敏捷团队负责。 非洲一家大型银行就调整了部分管理角色的沟通路径和职责，以大规模推广敏捷模式。之前，银行的软件开发团队需要与数名技术主管合作才能了解架构师对技术规格的要求。采用了敏捷模式后，技术主管的职责被架空，该岗位不复存在。开发人员可以直接与架构师和敏捷组长对话，因此能更好地理解用户需求，并针对这些需求开发软件。当然，直线经理仍承担重要职责，如提供职业发展方面的支持，以及进行相关的专业指导。但他们的职责经过了重新定义，并在组织内部进行了清晰传达。这样，团队成员便能知道彼此的职责，以及特定情况下应该向谁求助。 根据麦肯锡的观察，成功推广了敏捷模式的企业都高度透明。在决策权限的划定上，他们的指导原则十分明确。团队拥有适度的决策权，既能承担一定的责任，又不会因权限过大而闯祸。 4.调整预算和规划模型 IT部门通常会逐年制定预算和工作计划，这通常会导致两种结果:1) 各个技术项目间存在矛盾和冲突;2)大量的返工和浪费。 对想要大规模推广敏捷模式的组织而言，这种方法简直是个诅咒。有些企业打破了这种模式，总预算仍逐年制定，但会逐月或逐季度回顾工作路线图和计划，并持续对各项目的优先次序进行调整。 欧洲一家大型保险公司调整了预算制定流程，为每个产品领域都分配了一定比例的年度预算，供敏捷领导者使用，同时保留部分预算作为必要的维护费用。预算权责主要有三方面:1)业务和IT管理人员组成开发委员会，每月开会决定各个项目实施与否;2)敏捷领导者负责合理分配预算(例如出现新商机时快速决策)，并且不定期开会，随时调整预算的分配;3)敏捷组长则负责确保软件开发任务的及时执行，管理维护任务和积压任务，并持续进行评估。工作方法的转变使得公司预算流程的灵活性得到提升，响应能力也大幅改善。 了解到敏捷模式的精髓后，部分企业开始探索一种“风投式”的预算模型:先为最小可行产品提供初始资金，基于用户反馈改进后，再重新投放市场，后续资金支持则视MVP的市场表现而定。 在这种模式下，MVP会受到密切监控，而开发任务的优先次序也会不断调整，因此项目失败的风险会大大降低。这样，产品经理的工作会变得更加透明，无用功也会减少，企业也更容易终止那些没有前景的项目。 选择正确的实施方法 调整运营模式是一项浩大的工程。在向新模式转型的过程中，会有很多颠覆性挑战需要克服。一如任何大规模变革管理举措，这种转型需要全体员工的长期投入。在调查中，我们发现企业有几种改变运营模式的方法。 有些企业采用了敏捷试验室，即单独设立一个部门，作为贯彻敏捷模式的专项试点，试验成功后再进行大规模推广。若公司高层愿意给予的支持有限，且需要在短时间内看到变革的必要性，那采取这种方法无可厚非。但很多时候，这种敏捷试验室会始终游离在外，难以为整个企业带来变革。 有些企业则过于激进，企图一次性改造所有职能部门和业务部门，实现敏捷转型和流程提速。在这种模式下，成功的前提是高层领导自始至终都全力以赴，但能做到这一点的企业已是凤毛麟角。 上述两种做法都较为极端。其实，逐波推进才是大规模推动敏捷变革的最好方法。在这种模式下，各团队会有序分批向敏捷模式进发，在每一批次的末尾，管理者提出新的运营要求。例如，一家大型技术解决方案供应商曾需要快速提升数字化能力。由于项目的规模、复杂程度和数量都在与日俱增，IT部门在产品交付上遇到了很大困难。 该公司将产品开发团队分批改造为敏捷团队:第一批培训和部署5支团队，第二批则包括近2 0 支。每批团队成功转型后，公司都会收集相关反馈意见，编制和修订培训资料，以供下一批团队使用。此外，公司还委派了多名敏捷教练来指导团队。 敏捷转型开展到第6个月时，该公司采用了产品导向型组织架构，让业务单元领导者、开发人员、工程师及IT人员组成一个个“部落”。几个月过后，公司又开始专注于IT部门与业务部门之间的互动。公司调整了运营模式，以增强产品开发团队与I T 运维团队的合作，真正进入D e v O p s 模式。这些调整极大提升了产品上市速度，残次品数量和需要返工的情况也显著减少。 |
