技术领导力实战笔记_105_第85讲_|_游舒帆：敏捷力，拥抱不确定性，与VUCA共舞
你好，我是珍亚管理顾问公司负责人TGO鲲鹏会台北分会学习委员。
尤淑帆今天继续跟大家分享一流团队必备的商业思维能力。
这一系列文章，这是本系列最后一篇文章。
今天要来跟大家聊聊敏捷力，敏捷这个词儿在互联网爆发成长的这些年早就已经被谈到过火。
但这么多年观察下来，我发现敏捷这词儿被过度的曲解与滥用了。
怎么说呢？有些人以为每天早上开个战地会议，用白板来管理开发工作，这就是scrum,就是敏捷实践。
有另一群人把需求变来变去，朝令夕改，让技术团队不断变更优先级，搞得大家疲于奔命，然后丢下一句，你们要更敏捷才行。
最糟糕的是，那些明明能花点时间就把问题理清，少走许多冤枉路的事儿，却要急救章去做，然后碰个满鼻子灰才回过头来修正说，我们要加快迭代速度，才能应付这些不确定性。
其实很多不确定性都是自找的对敏捷错误的认知很容易导致错误的结果。
在长篇效应的影响下，流程最末端的研发团队与程序员们却必须以超时工作来填补。
因为项目的不断变更而衍生的额外工作，身为技术领导者，千万不能以这种错误的敏捷观念做事儿，否则最终将累死自己，也累死团队。
若你想了解敏捷真正的精神，我建议你看看egel many first toe,点ORG上所述的敏捷十二原则拉回主题，为何我将敏捷力放在商业思维系列文章的最后一篇呢？首先让我们回顾一下前面几篇谈到的内容数据力，让你掌握公司现况，而且有数据的支撑。
我们跨部门沟通与做决策时会更有依据、更准、更高效，是一个可期待的结果。
运营力，所有的任务都围绕着为客户提供价值，任何无法为客户产生价值的事儿，也无法为公司带来长期利润。
这样的思路有助于提高决策时的一致性。
策略力，让公司的目标从上到下认知一致。
所有人都知道为何二战所有人都能站在战略角度思考，决策不容易失准，而且战略的调整速度也会快上许多。
总结一下数据力，让信息一致且通透，运营力与策略力则有效的凝聚了共同的方向与目标，三者对于企业的敏捷性都有极大的帮助。
我曾在台湾敏捷峰会上与大家分享一句话，在这儿也分享给大家。
如果敏捷走不出技术团队，就不可能真正敏捷。
如果只在研发团队内推动敏捷成效其实非常有限。
因为外部的其他人总是成为我们走向敏捷的阻碍。
因此，为了强化团队的敏捷性，我做了以下几件事儿。
首先我以矩阵式组织重组了研发团队。
我将团队分成两种类型，一种归属于产品团队，另一种划分到功能部门，每个部门由一到两个产品经理负责，让产品经理们可以深入的参与到公司的各个业务过程。
当研发团队与业务团队能更紧密的参与，彼此的工作绩效也互相挂钩时，默契与信任感就会渐渐产生，信息更通透，行动也更敏捷了。
第二步骤，建立彼此对优先级的认知。
我在技术领导力，第五十一讲中曾提到三种决策方式，权力决、共识决与数据决这三种决策方法，我更倾向于数据决，但前提是这个数据是大家能信任，而且认可的。
为此，产品经理必须要跟业务部门一同敲定排优先序的规则。
在排序之前，首先要将会影响优先级排序的要素陈列出来，例如提升业绩、提高用户体验、提高系统稳定性与性能等，给每个要素一定的权充值，并试算出每个项目的价值价值愈高的优先级越靠前。
权重值与排序规则通常会经过几次的修正，最终才能为大家所认可。
做这件事儿的目的，除了更高效的去排序工作外，更重要的是提升了彼此对事情的认知。
我们都清楚对方在意些什么，也容易凝聚共识与目标。
此外，在面临难以抉择的选项时，业务部门也要给予产品经理足够的信任，尊重产品经理的专业决策。
第三步骤，加快迭代脚步，将项目切小并优先执行最有价值的部分。
这个步骤看似简单，但如果没有前面两个步骤来提升信任感，与建立共识落实的难度其实挺高的。
过去项目较大，实程估期可能都在三到六个月。
做加值排序时，也是就整个大项目来计算。
现在为了加快迭代速度，往往将项目切成两到四周，交付一次，项目的顺序将有很大的变化。
举例来说，原先有个项目，a要依序完成一二三到十共十项工作，为期四个月。
项目的价值是带来四千万业绩。
现在我们若要将项目切为a一、a二、a三、a四四个迭代项目，我们必须针对原先的十项工作做重新的排序。
可能a一先做一三两个需求完成后可以带来两千万业绩。
A二则完成二四五三个需求完成后可以带来一千万业绩。
也就是说我们仅完成了百分之五十的需求，却已获得百分之七十五的价值。
剩余的a三、a四的价值只剩一千万，拿来跟b一c一等比较。
重新排序后，或许我们该优先进行b一，而非a三。
而这就是将项目切小后的好处之一，让我们总是能优先进行价值最高的工作。
然而，项目切晓对研发团团队来说也一个挑战。
过去去watwaterfor的开发流程时，大家都很习惯将需求访谈期拉长，测试到部署的时间也往往估得较长。
当项目最前与最后的工作都需要花费一周时，一个只有四周的项目开发时间便剩余两周了。
这样的产出效率很难让人接受。
因此，研发团队必须持续改善工作方法与流程，缩短项目的前后置时间，进一步提升生产效率。
第四步骤，凝聚共识，持续追求更快更好更有价值。
如我在前一篇策略历史所说，若你发现不利用人工智能技术就能创造出关键结果，那你可以选择不用解决问题，不必总是仰赖技术。
这个观念我们也持续推广到研发部门外，让大家了解不是凡事儿都得靠系统。
如果时间真的急迫，但研发部门暂时排不出资源，我们还是会从专业角度提出其他建议方案。
我在技术领导力，第五十一讲中曾举了个例子，是请客服部门先以人工服务的方式来提供产品预计要开发的功能。
这个项目之所以能顺利推行，很大一部分仰赖于我们始终追求更快交付价值这个原则。
否则程序员不会提出这样的建议，我也不会采纳这种非技术解决的方案。
而客服主管更不会同意这种高度依赖人力的服务方式。
看到这儿，或许你会有个疑问，我们这样做难道不会只顾了短期需求而忽略长期吗？不会的，因为我们通过更短的交付周期，倒逼团队将每个项目的价值讲得更清楚。
也因为更深入的参与了彼此的日常工作，沟通的落差减少了许多。
并且因为具有足够的信任感，部门之间往往都能互相帮忙。
第五步骤，针对面临较高不确定性的部门，持续协助导入敏捷流程。
比如营销部门过往，他们最难回答的问题就是一个活动举办后大概能创造多大的成效，导致大多数的营销项目最后都是超值预算，才能达成原先的业绩目标。
在营销项目上，我们以多个小项目同时推进的小步快跑的迭代方式，通过市场反馈与数据分析，提高对现况的把握程度，更精准的达成了项目原始的目标。
若要拿实质成效来说，过去需求多数都来自于业务部门与高层。
在我们持续推动商业思维与导入敏捷约末一年后，研发团队的工作中仅有百分之五十来自业务部门与高层，而剩余的百分之五十则来自研发团队自提的需求。
我们清楚如何呈现技术性项目的价值，也知道我们应该优先做哪些事儿，才能帮助公司达标总结。
当所有部门都正确理解了敏捷，而非把敏捷视为研发团队的责任，企业才可能真正敏捷。
面对多变且不确定的环境时，才能同舟共济，以达成目标。
为首要商业思维，围绕着商业目标、用户与价值导向交付，将商业最核心的几个要素都涵括在内。
过去两年，我不断在团队内传递这些重要的观念与知识，团队的凝聚力更强，组织运作也更高效了，创造的价值也提高了许多。
本系列文章到此告一段落。
大家可以回顾一下，这几天我们谈到的内容，再次思考数据运营策略与敏捷在工作中扮演的角色，并适度的将这些知识与观念普及于团队内。
若你在看完这几篇内容后，有任何问题，欢迎提出讨论。
作者简介，尤书帆，昵称GP技术起家后走入管理产品运营相关领域，历任顶级软件技术总监twitor ABC研发总监。
熟悉b to b软件与在线教育，常年耕耘技术管理与商业领域，现从事顾问培训与教练工作，期许自己，为社会输送更多的卓越领导者。