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

当敏捷的“尾巴”开始动摇公司时，敏捷就不再是有用的工具了, 领导决策者否决那些不符合组织转型参数的项目. 在最好的情况下, 对框架规则的盲目遵守会造成僵硬的官僚作风，使团队成员士气低落, 一个没有更大目的的集会和仪式. 在最坏的情况下, 敏捷近视 能否掩盖更大的问题，比如缺乏领导力和创造性冒险精神.

在没有a的情况下 结构化的风险管理方法, 敏捷实践可能会让更大的人感到困惑, 科技债务等潜在问题, 遮挡总体产品愿景, 并带领产品团队只关注快速的胜利. 简而言之，模糊的风险管理模糊了大局、创造性的解决方案. 在一个 敏捷的生态系统, 产品领导者面临的最大风险取决于一个老生常谈:有时候，当你过于关注树木时，很容易忽视整个森林.

产品经理 是否应该通过支持那些不符合企业利益的更大的举措来培养对冒险的容忍 敏捷框架倡导创新和清晰大胆的产品愿景，以防止在规避风险的环境中积聚的潜在惰性官僚主义.

把敏捷置于自动驾驶状态很容易，也很诱人，只按照特定框架的要求去做. 为了更好的目标，你需要发挥自己的主动性，投入更多的工作, 投入更多的时间, 并鼓励各级领导做出更多努力.

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

敏捷否决的第一个受害者发生在像 技术债务 被忽略. 技术债务是一个巨大而持续的项目，不可能在一个sprint中解决，也不可能在一个用户故事中处理. 让事情变得更困难的是，技术债务是一个没有人真正愿意解决的问题:它可能是 难以解释 解决技术债务的理由是希望立即看到回报的商业利益相关者. Developers are often uncomfortable estimating it; after all, 识别技术债务 可能会给人一种他们工作做得很差的印象. 更重要的是，产品团队通常没有 这在他们的路线图上很合适.

在我参与的几个项目中，很多都是电子商务的核心业务活动，比如支付, 订单执行, 或者航运公司背负着技术债务，阻碍了更好的解决方案的实施. 基础设施破旧不堪, 至少有两个客户选择忽略这个问题，直到系统出现故障, 造成停机和收入损失. 一旦一个系统出现故障，无论是软件还是汽车的刹车片， 维修的总费用呈指数增长.

为什么会这样呢? 部分原因是希望有一个可预测的路线图和平滑 敏捷过程 会对适合敏捷的活动产生偏见，并妨碍对更大问题的严肃讨论. 让对敏捷的投入决定业务目标，而不是使用 作为工具的敏捷 为了使商业目标顺利运行，对公司有有害的影响.

砍伐树木:创造性破坏

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

例如，我遇到过几次不合格的产品 电子商务渠道. 经常, 这些渠道要么背负着设计债，要么背负着技术债，而且是为自产品首次发布以来发生了重大变化的受众或角色创建的. 在这些情况下, 正确的前进方式是根据数据承认这种情况, 并启动一个主要的用户体验项目来研究新的角色, 制定新方法, 简而言之，重建隧道, 创造一个全新的渠道. 而不是, 通常发生的是这里和那里的小调整, 将重点放在对现有(已消失)漏斗的迭代改进上. 这来自于对效率的错误追求，而效率是不可能的 巧妙地融入到冲刺中，以及能够快速取得成功的小项目.

有时候，小的迭代并不是解决问题的正确方法. 在软件行业，增量工作得很好直到一个颠覆者出现. 如果你发现自己还在对呼机进行渐进式修改，而苹果已经在隔壁开了一家iPhone工厂, 你把注意力都集中在树木上，而忽略了整个森林.

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

对抗风险偏见的唯一解药是培养合适的领导力，为创造性创造空间 风险管理使用敏捷作为一种工具来最小化不必要的风险，而不是消除它.

对于产品经理来说，我们的工作是在市场上展示领导力 团队层面, 并支持组织层面的领导:与利益相关者合作, 产品团队, 和技术团队确保他们理解并与下面讨论的策略保持一致, 怎样才能避免你的产品团队转向“全盘”文化 风险厌恶情绪.

保持清晰的产品愿景

知道并接受在敏捷时代可能出现的风险厌恶，已经是防止它扎根的重要的第一步. 下一步是解决由于缺乏领导和所有权而导致的问题:产品愿景必须由培育它的人来指导, 捍卫它, 并在公司内部销售, 抵制僵化和削弱大胆战略的冲动.

在理想的情况下, 拥有产品愿景的人应该是公司高管, 也许是创始人, 谁来负责把注意力集中在你正在制作的东西上，以及为什么——而不仅仅是如何制作. 但在高管层面的产品存在仍然是 一个相对较新的发展. 其次最好的情况是有一个副总裁或产品主管，他们有足够的自主权和权力来对抗当前的趋势. 如果你的公司没有现成的产品愿景拥护者, 你可能需要付出一些努力来培养这样的盟友.

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

管理数据以促进大型计划

一个优秀的工程团队已经了解不解决技术债务的危险. 但当他们只掌握技术信息时, 他们的声音可能会被过于狭隘地关注底线的业务团队压制或最小化.

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

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

团队中的创造力不会凭空产生，破坏也不会凭空出现. 创造力需要高级决策者的培养和监督. 一种可能发生的方式是在个人层面, 通过深思熟虑的选择，留出更多的时间与更多样化的人进行更多的讨论. 我个人就遇到过这样的情况 客户服务团队 或者一个实习医生提出了一些真实的建议 创新的解决方案 这让产品和技术都感到惊讶. 但是，如果您不花时间进行一对一的对话，您将永远不会听到这些想法——尽管您的框架有时有严格的时间限制.

创造力也可以是 在计划层面上培养. 花额外的时间和精力构建具有更高层次目标的史诗，以确保人们不受约束, 即使这会在以后带来更多的测试和交付挑战.

拥抱有意识的改变

永远没有改变的最佳时机. 在不确定的时期, 失败的风险带来的危险变得更加严重, 公司想要坚持他们所知道的. 在丰衣足食的时候, 制度性动力阻碍了创造力的发展, 因为风险被认为是不必要的, 公司想要坚持那些有效的——即使它实际上并不是那么好.

有时需要一场危机才能打破这种平衡, 因为现状无法实现，改变的风险被机遇作为前进道路的承诺所掩盖. 但你不应该等到绝望的时候才做出重要的决定. 而不是, 将风险作为开发过程的一部分，无论好坏, 为了抓住机会，集中精力, 资源, 和审议. A 产品经理 谁是风险的捍卫者, 胸怀大志, 能否抓住在敏捷生态系统之外冒险所带来的机会——在创造性努力方面走在前列，并提供对整个森林的看法.