|
除了IT领导之外，传统公司中很难找到熟悉敏捷工作方式的管理者。为了融入高度独立的团队，大多数管理者需要外界的帮助来学会如何围绕产品而非流程进行思考，如何指导团队制定业绩目标而非工作计划，如何自我定位为管家而非上级。高管层有义务给予团队管理者相应的机会来培养这种行为和思维习惯。可以采取的方法有:支持他们学习使用协作软件、分析引擎之类的新工具;鼓励他们与不同的独立团队合作完成任务、不断学习;安排他们和更有敏捷团队经验的同事合作以吸取同辈经验;还可以调整对他们业绩的评估方式，着重考察提高可量化成果，并360度全方位评估这些成果的影响。 业界享有盛誉的企业史学家阿尔弗雷德·钱德勒(Alfred Chandler)曾提出著名的“架构跟随战略”理论:公司制定自己的战略，然后根据战略调整组织架构，从而使战略得以充分实施。然而，在数字原生企业快速发展和老牌机构纷纷进行数字化转型的双重夹击之下，传统企业面临着巨大压力，这意味着他们不再有充裕的时间重新思考战略，更无法每隔几年对架构做出调整。为了提高企业敏捷性，越来越多的公司选择将小型团队作为基本组织单位。然而，当公司不能给予小型团队足够自主权和决策速度时，问题将会一一浮现。对此，高管有诸多解决方法，如:提供团队所需资源、消除繁文缛节以鼓励团队管理者积极学习使用更为灵活的敏捷组织管理方法。沿着这条道路前行的高管将会发现，麾下的小型团队会变得更加独立、更有创意，其业绩也会随之攀升，最终在竞争中一马当先。 大规模敏捷转型的先决条件不少企业已成功在小范围内进行敏捷模式试点，但要推广至整个企业，就必须在工作流程、组织架构和内部关系等方面进行4 项调整。 在敏捷模式下，许多数字化企业能更高效、更可靠地交付新产品。通过大范围推广敏捷模式，数字化巨头得以迅速设计和打造产品的新功能，让客户试用，并通过快速迭代对性能进行微调和更新。 相比之下，很多线上和线下相结合的传统企业并未大规模启用敏捷模式。例如，很多银行都设有数字化团队，负责移动app和网站开发。但小到办公位置，大到战略制定，他们都游走于企业其他部门之外，甚至独立于IT部门的其他团队。 研究表明:许多传统企业在相互独立的试点项目中尝试推广敏捷模式。这虽大有裨益，但只有不到20%的企业认为，已将敏捷模式推广到全局层面1。而据麦肯锡观察，大规模推广敏捷模式最多可使创新速度提高80%。 传统企业未能大规模推广敏捷模式，这一现象背后有诸多原因。但在麦肯锡看来，传统企业转型的最大障碍，还在于其现有运营模式和组织架构。 几乎所有传统企业的软件和产品开发流程都很分散、复杂。很多时候，连开发一个新的网站功能都会牵扯多个团队，但团队本身又各自为政，导致大量的重复性工作。比如，甲队负责前端应用，乙队负责相关服务器和数据库的更新，丙队则负责协调甲乙两队的工作。此外，IT与业务部门的支持性业务流程(包括预算、规划和外包)，以及职位和职责设置，都还在沿用原有的瀑布式方法2。 因此，即便小规模试点项目再成功，企业如不做结构性调整，也很难将敏捷模式推广到组织层面。 麦肯锡帮助许多组织在IT部门与业务团队中普及了敏捷模式。在此基础上，麦肯锡最近又深度剖析了1 3 个大规模推广敏捷模式的传统组织，这些企业都调整了运营模式，以促进敏捷模式的大规模推广。这些调整主要集中在4个方面:1)调整组织架构，更加注重产品;2)加强业务部门与I T 部门间的互动;3 )重新定义业务部门与I T 部门内的不同角色;4)调整预算和规划模型(见图)。
变革之路上的先行者已有了不小的收获。例如，某公司已将其运营模式由项目导向转变为产品导向。在客户引导阶段，该公司会依据客户整体体验而非单个应用所需的I T 技术，来部署人才与I T 资源。该企业过去一年仅发布4种新功能，而进行调整后，一个月内就能上线4种新功能。企业若能认真思索如何循序渐进地转变运营模式，就将大大提升向敏捷模式转型的成功几率。 扩大敏捷实践规模 敏捷模式的益处已广为人知。在该模式下，IT部门和产品开发团队会与业务部门一起打造产品与服务，这会避免瀑布开发模式所产生的敷衍了事与各自为政的问题。团队可以先行设计最小可行产品(MVP)，并不断测试和改进，数日或数周就能交付新产品，而不用再等好几年。麦肯锡观察走在敏捷模式最前沿的公司发现，只要企业循序渐进地调整运营模式和组织架构，IT与业务人员就能在更广的层面上合作，也能更快地协作开发产品。在此过程中，企业需要遵循4条原则: 1.组织架构以产品为导向传统企业往往会根据应用或项目调配IT资源，导致整个开发过程过于分散。正确的做法是围绕产品来分配I T 资源，集业务领导、开发人员和组织内其他成员之力，组成稳定的端到端团队，专注于特定业务成果的交付。这种结构会颠覆传统的项目制，也不再需要“项目管理办公室”。 在敏捷模式已得到大规模推广的环境中，产品不再只是某种商品，而是多种服务(如薪资管理服务)、多个客户体验(如线上购物旅程的方方面面)、多支产品团队共享的IT系统(如即时生成报价的定价软件)之和。因此，业务部门与IT部门的领导者必须重新定义交付内容。这一步完成后，企业必须指定一支或几支敏捷团队，由他们负责产品的开发和维护。团队通常包含开发人员、测试人员和敏捷组长等，他们可以从专家团队那里获取额外支持，比如有关安全、用户体验和企业I T 架构等方面的帮助。 通过调整组织架构，某大型医疗器械制造商大幅缩短了产品上市时间。由于产品之间依赖度很高，原先发布一款新产品或一个新功能，可能会在业务部门与技术部门间折腾20个来回。领导层发现这点后，意识到仅在单一业务团队或技术团队采用敏捷模式远远不够。2 0 1 5 年，该企业调整了原有的产品开发权限，使得业务部门的敏捷组长能绕开组织层级，直接向敏捷团队下达指令。经过这番调整，该企业成功缩短了产品上市时间。结构调整还促成了新团体的兴起。这些基于特定职能或业务主题的团体(或称“行会”)是敏捷组织内的重要平台，能让团队成员彼此交流知识，促进团队与职能部门间的协作，持续推动绩效改善。 2.业务部门与IT部门加强互动 |
