IT领导者分享了他们的经验和建议，以加快IT改革，包括削减项目、转向基于产品的交付以及促进文化转型。
IT在为业务提供技术支持的变革方面面临着前所未有的压力。然而，对IT的大量需求可能会使IT领导者难以将IT资源集中在正确的工作上。
在这种情况下，敏捷性至关重要，聪明的IT领导者正在加倍努力简化IT，无论是重新确定项目优先级和重新调整IT组合、合理化应用程序和追求云原生方法、通过采用DevOps或AIOps提高自动化，还是彻底改革IT运营结构。
本文中，4位IT领导者分享了他们精简IT以提高敏捷性的努力、经验、面临的最大挑战，以及最佳实践的建议。
削减项目，提高IT专注度
IT服务公司Randall-Reilly的首席信息官Chiranjoy Das称，他通过取消非必要性项目以提高企业的关注度，让IT人员更容易在更高的水平展现价值，最终确保企业变得更加敏捷。
Das确定的最大优先事项包括将Randall-Reilly IT与客户系统集成，使用微服务等现代方法重新架构旧系统，实施人工智能和机器学习以自动化手动流程，并提供干净、标准化的数据用于分析和监控。
Das表示，“事实上，为了保持敏捷并满足客户的需求，我们不得不推出尚不太完美的功能。例如，我们曾将sprints(即根据特定的时间框架划定的基本进度单元)从两周缩减到一周，这无疑提升了团队的专注度，但反过来也为Scrum团队带来了很大的压力，因为我们不能危及安全性。”
现有资源只能支持这么多东西，这也是Das重新评估其团队项目的原因。导致交付管道过载的原因包括部门负责人推动可能对整个企业没有战略利益的“偏爱项目”(pet project)，将太多投资回报率不高的大项目归类为“紧急项目”以及一些“假大空”的想法，例如未经适当审核的加密项目。
由于交付以及精疲力尽的团队成员在期望的重压下遭受重创，Das开始着手解决一些关键问题，包括某些项目缺乏商业案例，其他项目没有执行发起人或项目所有者，以及缺乏可用于解决技术债务的时间。他缩减了IT正在进行的项目总数，并一直倡导转向“以产品为中心”的软件开发，这意味着除非产品所有者根据利益相关者的需求确定优先级，否则IT团队不会完成任何工作。除了每周的sprint，IT还实施了持续集成(CI)/持续部署(CD)并进行了自动化回归测试，从而提高了IT敏捷性和质量。
自从Das开始做出这些改变后，IT团队的状态好转了很多。人才保留率增加了，会议减少了，IT人员也有更多精力来开展更多与业务目标一致的战略项目。
Das补充道，公司领导者非常赞赏IT能够坚定立场，但他们正在考察我们，看我们能否兑现做出的承诺。但毫无疑问，更高的责任感和更少的项目负担有助于我们更好地集中注意力。
领导者建议：Das认为，让企业了解IT为何要减少项目数量——以更一致地交付——是至关重要的。大多数项目并不会为业务赋值，在将项目分配给IT之前，责任需要转移到业务领导者身上以证明投资回报率。
此外，敏捷的思维和文化远比敏捷开发方法重要得多。IT领导者必须在一头扎进CI/CD之类的事情之前创造一种紧迫感。敏捷性的其他关键要素包括建立数据仓库、API、适当的安全性和可扩展架构。没有这些基础板块，IT就无法实现敏捷。
通过集成框架和微自动化为业务赋能
为了与“以客户为中心”和专注创新的业务战略保持一致，技术团队必须做出快速决策并适应不断变化的业务环境。
为此，Ricoh USA数字服务中心负责人Bob Lamendola确定了三个关键战略优先事项：微自动化，采用集成框架，并支持全民开发者。事实上，技术功能现在正围绕自动化、集成和分析进行组织。
Lamendola介绍称，“通过专注于使用微自动化逐步改进业务流程，IT已经能够快速实现效率目标。我们还有很多长期的大型项目，并专注于更广泛地转型变革。但是目前，通过专注于较小的胜利，我们正在实现敏捷性并向企业展示我们正在倾听他们的迫切需求，同时也在朝着长期目标不懈努力。”
认识到在可预见的未来需要支持复杂的混合云基础设施，Lamendola的团队开发了一个灵活的集成框架，可以在保持安全控制的同时实现更轻松的互连。API层允许Ricoh的第三方合作伙伴连接公司的企业资源计划(ERP)系统和其他合作伙伴服务，从而以最少的运营支持创造更好的用户体验。
Lamendola解释称，“我们认识到，需要灵活地根据需要更改我们混合模型的合作伙伴或组件。通过将集成框架置于我们架构的核心，这样一来，每次我们想要将新的解决方案整合到我们的企业中时，任务就变得不那么繁重了。”
此外，IT还在数据聚合、工程和分析方面进行了投资，以释放全民开发者的力量，他们可以使用集中开发的规则和业务流程框架将数据转换为驱动行动的信息。
Lamendola表示，“他们有权构建自己的仪表板和模型来实现团队的目标。此外，数据分析社区与数据聚合和可访问性的结构化方法相结合，又在职能和企业层面提供了平衡的控制水平。”
Lamendola补充道，这是一个重大的文化转变，它要求IT适应变化。传统工作正在转变，需要新的思维方式。从长远来看，我们将专注于生产力，但我们必须从一开始就掌握文化，以释放潜力。
领导者建议：Lamendola称，我们一直专注于基础，而非最终产品。最终产品很重要，但它并不能推动我们前进。我们正在转型过程中，且仍处于转型中期，我们正在努力利用过去的投资来加速未来的基础战略。此外，了解何时放松控制也很重要。的确，政策和控制必须存在，但必须拥有灵活性，才能实现敏捷性。
打破壁垒：围绕产品和流程进行重组
内容服务提供商Hyland的首席信息官Steve Watt介绍称，Hyland公司正在进行重大系统改造，以推动企业发展并创建下一代基于平台的产品。此举也给IT带来了巨大的压力，要求其提供持续的价值。他解释称，“企业不能再等待所有项目都集中交付，他们期待在整个项目生命周期中持续交付价值的能力。”
对于Watt来说，精简意味着消除员工绩效的障碍。在此，自动化至关重要，它使团队能够在IT内部和外部自助服务，并专注于结果。通过让正确的资源直接参与并专注于这些成果，团队能够实现紧密运作并取得成功。
这就是Watt将IT重组为产品或流程一致的团队的原因。每个部门都有自己的报告结构，纳入来自不同领域的员工，包括解决方案和平台工程师、产品所有者、敏捷流程管理者以及精通基础架构、应用程序开发和集成的IT员工。例如，一个团队完全专注于Hyland的“按订单报价”流程，使用敏捷框架持续完成工作，以执行持续积压的功能、改进和修复任务。
Watt称，“自重组以来，我们拥有更多的精力对任务进行优先级排序，浪费的时间也更少了。此外，我们能够更好地与业务保持一致，并且看到更快的实施和更少的返工。”
此外，围绕这种新的工作方式与企业进行持续沟通同样至关重要。Watt解释称，“我们已经寻求并获得了支持，即需要削减一些事情以专注于更重要的事情，并确保我们专注于利用所拥有的有限资源进行正确的工作。”
领导者建议：如果企业没有准备好在正确的时间和有规律的节奏下参与实践，IT仍然会浪费时间和精力。请务必确保你的业务利益相关者了解敏捷的真正含义，以及你在该框架中的执行将如何发挥作用。
恰到好处的技术：拥抱工作流程自动化
非营利性医疗认证组织Inteleos的首席信息官Juan Sanchez认为，对于Inteleos的IT团队来说，提高速度和敏捷性的压力是自己施加的。
集成平台即服务(IPaaS)的实施是IT议程的首要任务，同样重要的还有通过核心平台更新减少技术债务，为内部和外部客户构建数据科学能力，以及创建零接触(zero-touch)员工入职和配置。
Sanchez解释称，“如果我们利用这些工具和机会，就可以产生巨大的影响。精简IT的最终方式是利用工作流程自动化。”
通过利用具有完整API的成熟SaaS平台，Inteleos的开发团队可以专注于工作流程的关键操作，而非代码的底层细节和永无止境的重构工作。基础架构团队还可以专注于构建为业务带来直接价值的工作流程。例如，通过简化及自动化帐户和应用程序配置工作流程而非保持域控制器运行，IT可以为新员工提供更好的入职体验。
目前，Inteleos的许多业务流程都需要人工干预。变更请求也通常侧重于使流程更有利于员工，而非客户。Sanchez希望当业务流程所有者了解他们可以自动执行重复性任务时，能够释放他们以更全面的方式思考流程的能力，并更加关注流程的受益对象和方式。
Sanchez表示，“我们将自身的操作视为一个弹性系统。我们试图确定交付价值的瓶颈在哪里，并考虑我们应该从哪里以及如何扩展该系统的不同部分。”
此外，Inteleos还采用了“Goldilocks IT”原则，即构建适量的技术，不多也不少。根据Sanchez的说法，建立新技术几乎应该是最后的选择。虽然这种说法有悖常理，但每种新技术解决方案都会产生直接和长期成本。因此，建立新技术时必须慎之又慎，切忌步伐过快。
到目前为止，Inteleos的KPI已经得到了改进，传统的IT服务指标(如周期时间和SLA违规)也有所减少。通过在API设计中使用更好的架构方法，开发团队已经超出其并发请求性能目标250%。
将IT的形象从“黑箱”事务功能转变为业务合作伙伴并非易事。IT与其利益相关者之间不断增加的对话正在推动Inteleos的发展。Sanchez介绍称，“与以前相比，我们正在产生更大的战略影响，并在更宏观的层面帮助指导组织运行。有效沟通是协作的关键，也是大多数技术团队需要培养的重要技能。”
领导者建议：愿意在人才方面发挥创造力。没有这种觉悟，即便世界上最好的架构也会失败。此外，Sanchez也认同，敏捷是一种思维，它必须首先存在于技术团队的头脑中，然后再让这种思维方式渗透到与业务部门互动的方式中。通过这些互动，我们将在业务中看到敏捷性的体现。如果作为一个技术团队，我们无法构思超出我们所见的想法，那么我们注定只能成为事务解决者，而非业务合作伙伴。
