你好，我是箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员游舒帆，今天继续跟大家分享“一流团队必备的商业思维能力”这一系列文章。

这是本系列最后一篇文章，今天要来跟大家聊聊敏捷力。敏捷这个词在互联网爆发成长的这些年，早就已经被谈到过火，但这么多年观察下来，我发现敏捷这词被过度的曲解与滥用了，怎么说呢？

  • 有些人以为每天早上开个站立会议、用白板来管理开发
    工作，这就是 Scrum，就是敏捷实践；
  • 有另一群人，把需求变来变去，朝令夕改，让技术团队不断变更优先级，搞得大家疲于奔命，然后丢下一句“你们要更敏捷才行”；
  • 最糟糕的是那些，明明能花点时间就把问题厘清，少走许多冤枉路的事，却要急就章去做，然后碰个满鼻子灰才回过头来修正，说“我们要加快迭代速度，才能应付这些不确定性”，其实，很多不确定性都是自找的。

对敏捷错误的认知，很容易导致错误的结果，在长鞭效应的影响下，流程最末端的研发团队与程序员们，却必须以超时工作来填补因为项目的不断变更而衍生的额外工作。身为技术领导者，千万不能以这种错误的敏节观念做事，否则最终将累死自己，也累死团队。

若你想了解敏捷真正的精神，我建议你看看 agilemanifesto.org 上所述的敏捷 12 原则。

拉回主题，为何我将敏捷力放在商业思维系列文章的最后一篇？

首先让我们回顾一下前面几篇谈到的内容：

  • 数据力，让你掌握公司现况，而且有数据的支撑，我们跨部门沟通与做决策时，会更有依据，更准更高效是一个可以期待的结果；
  • 运营力，所有的任务都围绕着为客户提供价值，任何无法为用户产生价值的事，也无法为公司带来长期利润，这样的思路，有助于提高决策时的一致性；
  • 策略力，让公司的目标从上到下认知一致，所有人都知道为何而战，所有人都能站在战略角度思考，决策不容易失准，而且战略的调整速度也会快上许多。

总结一下，数据力，让信息一致且透通；运营力与策略力则有效的凝聚了共同的方向与目标，三者对于企业的敏捷性都有极大的帮助。

我曾在台湾敏捷峰会上与大家分享一句话，在这也分享给大家：“如果敏捷走不出技术团队，就不可能真正敏捷”。若我只在研发团队内推动敏捷，成效其实非常有限，因为外部的其他人，总是会成为我们走向敏捷的阻碍。

因此，为了强化团队的敏捷性，我做了以下几件事：

首先，我以矩阵式组织重组了研发团队。

我将团队分成两种类型，一种归属于产品团队，另一种则划分到功能部门，每个部门由一到两个产品经理负责，让产品经理们可以深入的参与到公司的各个业务过程。

当研发团队与业务团队能更紧密的参与彼此的工作，绩效也互相挂勾时，默契与信任感就会渐渐产生，信息更透通，行动也更敏捷了。

第二步骤，建立彼此对优先级的认知。

我在技术领导力第 51 讲中曾提到三种决策方式：权力决、共识决与数据决，这三种决策方法我更倾向于数据决，但前提是这个数据是大家能信任，而且认可的。

为此，产品经理必须要跟业务部门一同敲定排优先序的规则。在排序之前，首先要将会影响优先级排序的要素陈列出来，例如提升业绩、提高用户体验、提高系统稳定性与性能等，给每个要素一定的权重值，并试算出每个项目的价值，价值愈高的优先级愈靠前。

权重值与排序规则通常会经过几次的修正，最终才能为大家所认可，做这件事的目的除了更高效的去排序工作外，更重要的是提升了彼此对事情的认知，我们都清楚对方在意些什么，也容易凝聚共识与目标。

此外，在面临难以抉择的选项时，业务部门也要给与产品经理足够的信任，尊重产品经理的专业决策。

第三步骤，加快迭代脚步，将项目切小，并优先执行最有价值的部分。

这个步骤看似简单，但若没有前面两个步骤来提升信任感与建立共识，落实的难度其实挺高的。过去项目较大，时程估期可能都在 3-6 个月，做价值排序时也是就整个大项目来计算。现在为了加快迭代速度，往往将项目切成 2-4 周交付一次，项目的顺序将有很大的变化。

举例来说，原先有个项目 A 要依序完成 1.2.3 到 10，共 10 项工作，为期 4 个月，项目的价值是带来 4,000 万业绩。现在我们若要将项目切为 A1、A2、A3、A4 四个迭代项目，我们必须针对原先的 10 项工作做重新的排序，可能 A1 先做 1.3 两个需求，完成后可以带来 2,000 万业绩，A2 则完成 2.4.5 三个需求，完成后可以带来 1,000 万业绩，也就是说我们仅完成了 50% 的需求，却已获得 75% 的价值。

剩余的 A3、A4 的价值只剩 1,000 万，拿来跟 B1、C1 等比较，重新排序后或许我们该优先进行 B1 而非 A3。而这就是将项目切小后的好处之一，让我们总是能优先进行价值最高的工作。

然而项目切小，对研发团队来说也是一个挑战，过去走 waterfall 的开发流程时，大家都很习惯将需求访谈期拉长，测试到布署的时间也往往估的较长，当项目最前与最后的工作都需要花费 1 周时，一个只有 4 周的项目开发时间便剩余 2 周了，这样的产出效率很难让人接受。因此，研发团队必须持续改善工作方法与流程，缩短项目的前后置时间，进一步提升生产效率。

第四步骤，凝聚共识，持续追求更快、更好、更有价值。

如我在前一篇策略力时所说，若你发现不利用人工智能技术就能创造出关键结果，那你可以选择不用。“解决问题，不必总是仰赖技术”这个观念我们也持续推广到研发部门外，让大家了解不是凡事都得靠系统，若时间真的急迫，但研发部门暂时排不出资源，我们还是会从专业角度提出其他建议方案。

我在技术领导力第 51 讲中曾举了个例子，是请客服部门先以人工服务的方式来提供产品预计要开发的功能。这个项目之所以能顺利推行，很大一部分仰赖于我们始终追求“更快交付价值”这个原则，否则程序员不会提出这样的建议，我也不会采纳这种非技术解决的方案，而客服主管更不会同意这种高度依赖人力的服务方式。

看到这，或许你会有个疑问，我们这样做难道不会只顾了短期需求而忽略长期吗？不会的，因为我们通过更短的交付周期，倒逼团队将每个项目的价值讲得更清楚，也因为更深入的参与了彼此的日常工作，沟通的落差减少了许多，并且因为具有足够的信任感，部门之间往往都能互相帮忙。

第五步骤，针对面临较高不确定性的部门，持续协助导入敏捷流程。

比如营销部门，过往他们最难回答的问题就是，一个活动举办后大概能创造多大的成效，导致大多数的营销项目最后都是超支预算才能达成原先的业绩目标。在营销项目上，我们以多个小项目同时推进的小步快跑的迭代方式，通过市场反馈与数据分析提高对现况的把握程度，更精准的达成了项目原始的目标。

若要拿实质成效来说，过去需求多数都来自于业务部门与高层，在我们持续推动商业思维与导入敏捷约莫一年后，研发团队的工作中，仅有 50% 来自业务部门与高层，而剩余的 50% 则来自研发团队自提的需求。我们清楚如何呈现技术型项目的价值，也知道我们应该优先做哪些事才能帮助公司达标。

总结

当所有部门都正确理解了敏捷，而非把敏捷视为研发团队的责任，企业才可能真正敏捷，面对多变且不确定的环境时，才能同舟共济，以达成目标为首要。

商业思维围绕着商业目标、用户与价值导向交付，将商业最核心的几个要素都含括在内，过去两年我不断在团队内传递这些重要的观念与知识，团队的凝聚力更强，组织运作也更高效了，创造的价值也提高了许多。

本系列文章到此告一段落，大家可以回顾一下这几天我们谈到的内容。再次思考数据、运营、策略与敏捷在工作中扮演的角色，并适度的将这些知识与观念普及于团队内。若你在看完这几篇内容后有任何问题，欢迎提出讨论。

作者简介：

游舒帆，昵称 gipi，箴亚管理顾问公司负责人、TGO 鲲鹏会台北分会学习委员。技术起家，后走入管理、产品、营运相关领域，历任鼎捷软件技术总监、TutorABC 研发总监，熟悉 B2B 软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。