使用得当, 敏捷 是一个很棒的工具. 将大型软件项目分解成较小的项目, 可操作部分为IT团队提供了一个很好的方法 降低交付风险. 但当一家公司面临变革的紧迫性时, 或者是迫切需要让一切回到正轨, 它的决策者很容易受到采用敏捷的神话的影响 可以解决所有问题.

当敏捷的“尾巴”开始动摇公司时，敏捷就不再是有用的工具了, leading decision-makers to veto projects that don’t fit neatly within the organization’s transformed parameters. 在最好的情况下, blind adherence to a framework’s rules will create a stilted bureaucracy that demoralizes team members, 一个没有更大目的的集会和仪式. 在最坏的情况下, 敏捷近视 能否掩盖更大的问题，比如缺乏领导力和创造性冒险精神.

在没有a的情况下 结构化的风险管理方法, 敏捷实践可能会让更大的人感到困惑, 科技债务等潜在问题, 遮挡总体产品愿景, 并带领产品团队只关注快速的胜利. 简而言之，模糊的风险管理模糊了大局、创造性的解决方案. 在一个 敏捷的生态系统, the biggest risk faced by product leaders hinges on an old truism: Sometimes it’s easy to lose sight of the forest when you focus too much on the trees.

产品经理 should foster a tolerance for risk-taking by championing larger initiatives that don’t dovetail with an 敏捷框架: Advocate for creativity and a clear and bold product vision to preempt the potentially inert bureaucracy that can accrete in a risk-averse environment.

It’s easy and tempting to put 敏捷 on autopilot, only doing what a particular framework says. 为了更好的目标，你需要发挥自己的主动性，投入更多的工作, 投入更多的时间, 并鼓励各级领导做出更多努力.

根除科技债务:从大的角度考虑

敏捷否决的第一个受害者发生在像 技术债务 被忽略. Technical debt is an immense and ongoing project that can’t be solved in a single sprint or handled in one user story. To make matters more difficult, tech debt is a problem nobody really likes to address: It can be 难以解释 the rationale for addressing tech debt to business stakeholders who want to see immediate returns. 开发人员 are often uncomfortable estimating it; after all, 识别技术债务 可能会给人一种他们工作做得很差的印象. 更重要的是，产品团队通常没有 这在他们的路线图上很合适.

On several projects I’ve worked on—many in e-commerce—core business activities such as payments, 订单执行, or shipping were saddled with 技术债务 that prevented the implementation of better solutions. 基础设施破旧不堪, 至少有两个客户选择忽略这个问题，直到系统出现故障, 造成停机和收入损失. 一旦一个系统出现故障，无论是软件还是汽车的刹车片， 维修的总费用呈指数增长.

为什么会这样呢? 部分原因是希望有一个可预测的路线图和平滑 敏捷过程 creates a bias toward 敏捷-suited activities and precludes serious discussions of bigger issues. 让对敏捷的投入决定业务目标，而不是使用 作为工具的敏捷 为了使商业目标顺利运行，对公司有有害的影响.

砍伐树木:创造性破坏

根据我的经验，企业将创造力视为风险的同义词. 当然，他们想要的好处 来 从创造力，但做一些新的东西可能会以失败告终. 一种积极规避风险的敏捷形式, 当被允许影响商业决策时, 加剧了这个问题.

例如，我遇到过几次不合格的产品 电子商务渠道. 经常, these funnels are weighed down with either design debt or 技术债务 and created for an audience or persona that has changed significantly since the product was first released. 在这些情况下, 正确的前进方式是根据数据承认这种情况, 并启动一个主要的用户体验项目来研究新的角色, 制定新方法, 简而言之，重建隧道, 创造一个全新的渠道. 而不是, 通常发生的是这里和那里的小调整, 将重点放在对现有(已消失)漏斗的迭代改进上. This 来s from the misguided search for efficiency where none can be had, for tasks that 巧妙地融入到冲刺中，以及能够快速取得成功的小项目.

有时候，小的迭代并不是解决问题的正确方法. 在软件行业，增量工作得很好直到一个颠覆者出现. If you find yourself still making incremental changes to a pager when Apple has already opened an iPhone factory next door, 你把注意力都集中在树木上，而忽略了整个森林.

敏捷风险管理框架:前进的道路

The only antidote to anti-risk bias is to cultivate proper leadership that carves out space for creative 风险管理使用敏捷作为一种工具来最小化不必要的风险，而不是消除它.

对于产品经理来说，我们的工作是在市场上展示领导力 团队层面, 并支持组织层面的领导:与利益相关者合作, 产品团队, and tech teams to make sure they understand and are aligned with the strategies discussed below, 怎样才能避免你的产品团队转向“全盘”文化 风险厌恶情绪.

保持清晰的产品愿景

Knowing and accepting that 风险厌恶情绪 can emerge in an 敏捷 age is already a huge first step toward preventing it from taking root. The next step is to solve problems caused by a lack of leadership and ownership: A product vision must be guided by someone who nurtures it, 捍卫它, 并在公司内部销售, 抵制僵化和削弱大胆战略的冲动.

在理想的情况下, 拥有产品愿景的人应该是公司高管, 也许是创始人, who takes responsibility for keeping the focus on what you’re making and why—not just how. 但在高管层面的产品存在仍然是 一个相对较新的发展. The next best case is having a vice president or Head of 产品 who has sufficient autonomy and authority to go against the current. 如果你的公司没有现成的产品愿景拥护者, 你可能需要付出一些努力来培养这样的盟友.

使用性能指标来说明您的优先级:定义良好的 kpi集 能否激励行动而非惯性. 你要争取的人都很忙, 所以这些指标, 很像数据可视化, 应该很少, 简单的, 简洁的, 所有在30秒内看过的人都可以进入. 一旦你有了你的盟友 强大的性能指标 你所提供的也将有助于武装产品负责人的努力.

管理数据以促进大型计划

A good engineering team already understands the dangers of leaving 技术债务 unaddressed. 但当他们只掌握技术信息时, their voices can be silenced or minimized by business teams that focus too narrowly on the bottom line.

这是另一个having的例子 可操作的数据随时可用 是至关重要的. 产品经理, 作为一个既涉足工程又涉足商业的人, 能作为信息的渠道吗, 授权工程团队完成自己的任务. 例如, 如果KPI显示需要在给定的关键系统上改进测试覆盖率, 或者OKR证明可用性问题必须在30天内解决, 这些讨论集中在技术债务上. 需要改进这些指标, 工程团队可以与决策者一起倡导技术债务项目. 同样的, 唱反调的人很难把这样的项目搁置起来, 这是一种常用的策略，用来忽略大型但可推迟的计划.

在规避风险的环境中培养创造力

团队中的创造力不会凭空产生，破坏也不会凭空出现. 创造力需要高级决策者的培养和监督. 一种可能发生的方式是在个人层面, by making a deliberate choice to carve out more time for more discussion with a more diverse set of people. 我个人就遇到过这样的情况 客户服务团队 或者一个实习医生提出了一些真实的建议 创新的解决方案 这让产品和技术都感到惊讶. But you’ll never hear those ideas if you don’t make the time to have one-on-one conversations—despite your framework’s sometimes rigid timeboxes.

创造力也可以是 在计划层面上培养. Spend the extra time and effort to structure epics with higher-level goals to ensure that people aren’t constrained, 即使这会在以后带来更多的测试和交付挑战.

拥抱有意识的改变

永远没有改变的最佳时机. 在不确定的时期, 失败的风险带来的危险变得更加严重, 公司想要坚持他们所知道的. 在丰衣足食的时候, 制度性动力阻碍了创造力的发展, 因为风险被认为是不必要的, and companies want to stick with what works—even if it doesn’t actually work all that well.

有时需要一场危机才能打破这种平衡, as the status quo fails to deliver and the risk of change is overshadowed by the promise of opportunity as a way forward. 但你不应该等到绝望的时候才做出重要的决定. 而不是, 将风险作为开发过程的一部分，无论好坏, 为了抓住机会，集中精力, 资源, 和审议. A 产品经理 谁是风险的捍卫者, 胸怀大志, can seize the opportunities that 来 from venturing outside the 敏捷的生态系统—leading the way on creative efforts and providing a view of the whole forest.