第85讲 | 游舒帆：敏捷力，拥抱不确定性，与VUCA共舞

Sep 11, 2018
第85讲 | 游舒帆：敏捷力，拥抱不确定性，与VUCA共舞-极客时间

下载APP


关闭
讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件
渠道合作
推荐作者
第85讲 | 游舒帆：敏捷力，拥抱不确定性，与VUCA共舞

2018-09-11 箴亚管理顾问公司负责人、TGO会员游舒帆来自北京
《技术领导力实战笔记》
课程介绍

讲述：黄洲君

时长10:00大小4.57M

你好，我是箴亚管理顾问公司负责人、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 软件与在线教育。长年耕耘技术、管理与商业领域，现从事顾问、培训与教练工作，期许自己为社会输送更多的卓越领导者。
分享给需要的人，Ta购买本课程，你将得29元
生成海报并分享
赞 3
提建议
第84讲 | 游舒帆：策略力，让目标与行动具备高度一致性
第86讲 | 刘俊强：管理者必备的高效会议指南（上）
 写留言
精选留言(2)

送普选
2020-10-11
干货满满，感谢作者
2
baye
2021-04-28
三种决策方式：权力决、共识决与数据决
1
