|
|
# 第85讲 | 游舒帆：敏捷力，拥抱不确定性，与VUCA共舞
|
|
|
|
|
|
你好，我是箴亚管理顾问公司负责人、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软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。
|
|
|
|