敏捷开发，让技术实战干货分享飞起来

Posted 2021-04-25 OD积跬步

互联网公司技术类实战干货内容如何开发，一直困扰着培训发展从业者。本文尝试用敏捷开发模式撰写并分享一套验证有效的敏捷开发方法。

场景化问题

2014年开始推行技术分享季，通过积分制度、评选口碑讲师、职级晋级申报挂钩等抓手推动，营造公司内部的技术氛围，刚开始两年参与度、热度都还不错。随着公司面临移动互联网转型的急剧挑战，2016年开始出现了技术分享季热度下降等问题，即使在2017年推出了《课程开发与管理办法》制度，也没起到显著的拉动作用。笔者在今年（2018年）初跟团队的一个小伙伴抛出了一个命题即“找到一种技术类课程的开发方法”，当时的判断有直觉成分。后续各种忙，小伙伴对这个事的投入以及笔者的重视都出现不足，迟迟没有实质性进展。 

最近一个月来，陆续收到来自BP转述、薪酬组调研以及个别工程师等渠道的反馈：对技术学习少的抱怨吐槽。系统思考的理论告知我们，人们今天不得不面对昨天missing的关键问题，因为随着时间的延伸，问题会滚动放大，甚至是指数级的。

洞察杠杆解

恰逢支持公司高管落地打造技术氛围，“内部优秀技术人员分享”是一个重要方面。笔者用思考罗盘这个工具系统分析了“技术分享季热度下降”这个问题：

 

选定四个关键利益相关方，其相关关联影响如下：

1、技术高职：业务忙、加班多的情况下，大多数工程师们很少有意愿并投入足够时间开发一门课程，何况课程开发本身不容易、当众分享本身也有压力，这直接导致技术分享季热度降低，反过来也会影响技术沉淀与积累，技术影响力不足，成就感低并且晋级难，成长慢，进而需投入更多时间开发课程，意愿度更低……这形成了一个恶性循环。

2、内部员工：业务忙、加班多的情况下，可用于集中学习的时间也是有限的，会导致热度下降，时间久之，会感知到技术氛围变差，参与度更低、成长慢，更需要加班就更少时间参与学习……形成另一个恶性循环。同时，员工参与度低会影响技术高职开发意愿，加速另一个恶性循环，成长慢加班多，还会引发抱怨吐槽，由于互联网圈子越发透明，这对外部人才对公司认知也会造成不良影响。

3、外部人才：新进大牛少，缺乏足够大牛参与技术分享，分享热度低，影响外部人才（潜在候选人）对公司品牌、人才培养、技术氛围的感知，受制于牛人聚集效应的影响，公司对外部人才吸引力下降，更少牛人加入，招聘更难，招聘HR及业务同事对培训发展HR会产生吐槽。

4、培训发展HR：对技术不够了解，课程开发辅导困难，加之技术高职成长慢，时间少、意愿低，就更难辅导技术类课程开发；本身工作任务多，也忙不完，不如投放更多精力在开发新的人才发展产品上面去，对这块的推动意愿低，导致技术分享季热度低，这直接或间接地会受到很多吐槽、抱怨，压力下会忙于各种其他事务之中合理化，投入该项目的精力更少……形成又一个恶性循环。

 

基本看见了全局，如何解呢？对这个系统的最有力干预是顶端引入外部技术大牛择优汰换。除此之外，对培训发展HR从业者而言，破局点在哪呢？看似很多问题需要解决，推力、拉力都有了，难道是去强制推广吗？

笔者认为“技术分享内容敏捷开发”是杠杆解。急需一套对技术高职来说简单易懂、易于开发沉淀经验、开发占用时间少、同时所开发的内容还容易分享互动，对培训发展HR来说也容易辅导与反馈、占用时间少的敏捷开发方法。

答案在现场

带着敏捷开发的初步思考，现场参与了两次分享活动：

第一次：旁听Web前端通道技术分享。其中一位同学的分享让我有启发，不仅内容讲起来比较自然，而且也能带着学员思考一个个问题以及分享他的解决方案是怎样的、效果如何。笔者快速形成了基于场景化问题的技术实战干货的“敏捷开发”基本模式。

第二次：观摩某技术部门季度会。其中有一个技术赋能业务的项目实战干货分享，用提炼的“敏捷开发”模式进行比照，算是一次测试验证，基本验证OK，并对模式做了一次小微迭代。

后面用于辅导各技术通道技术高职分享内容开发，进行了若干次迭代，基本框架如下：

敏捷开发内在逻辑如下：

问题本质上是现状与目标的差距，这些问题来自于组织、业务、人才三个方面，如果要抽离最核心的问题，自然是三者的交汇之处——用户的核心需求与核心体验。现实与蓝图之间，是一个个里程碑式的目标，而现状与目标之间都可以具化为若干个场景化问题，针对每一个场景化问题都存在“场景问题-解决方案-结果验证”的闭环模式，闭环复盘形成可复制的经验（好的方面需传承、不好的方面需规避或改进）；与此同时，每个解决方案本身可能也存在一些不足，解决方案的结果都将成为下一个“现状”，这与下一个“目标”之间必然形成“问题”，进行如下一轮的“场景问题-解决方案-结果验证”闭环，这会产生“未来进化方向”。

任何一个学习项目的成功，都必须符合3R模式：Right Time, Right People, Right Knowledge。即在正确的时刻为适合的学员群体提供满足需求的培训内容。技术高职开发分享内容时必须清楚目标学员、学习收益，在人数足够的情况下开放报名，由学员自己判断。

验证的结果

不到2个月，敏捷开发模式已经应用到了技术7个通道，很快将实现技术通道的全覆盖。效果上实现了“两升一降”：

提升了分享内容开发（知识沉淀）效率：过往技术分享一般提前一月准备，现在一周左右可以出初稿，出现了“提前产出内容等运营安排”的情况，技术高职积极性也提升；

提升了学员的参与度：场景化问题及学员收益描述精准，首创分享现场最高现场记录，第一次出现超过百人现场参与学习的情况，技术氛围感知增强了。

降低了培训发展HR跟进与辅导难度：砍掉了过往一堆理解与应用都有一定难度的工具表格，敏捷开发模式易懂好讲好用，在课程开发这个事儿上出现了久违的笑容。

某分享反馈片段

分享现场感知：“现场互动非常棒”、“小伙伴们听得也很认真”、“后排表示听得很清楚”、“X、Y、Z（三位培训发展HR）的建议特别好，效果果然不一样，感谢感谢~”

后续落地影响：“周三的分享，达预期啦，开发主动扫描，积极配合”、“产品这两天也都是非常主动YY咨询需求风险了，沟通也顺畅了很多，让改啥就改啥，配合度非常高，相信效果会越来越好，超有成就感的”

该敏捷开发模式自推出以来，正面口碑比较多，持续的培训分享将会带来正向的增强回路。本质上源于敏捷开发模式与以蓝图为导向的脉冲式技术滚动开发模式十分契合，同时在“培训以谁为中心”的问题上实现了多赢：

如上图所示，从非此即彼迈向彼此融合，是多方的真交互，不再是以下几组的对抗：以讲师为中心Vs以学员为中心，以绩效为基础Vs以内容为基础，以知识技能为中心Vs以情境应用为中心，基于工作流程设计学习方案Vs基于工作“情景”设计学习方案。同时还承接了战略，以沉淀为指引。最终，在讲师、学员、公司/HR之间找到了平衡。

可复制的经验

除了敏捷开发模式1.0版本之外，这个过程沉淀了三条经验：

1、 聚焦问题，系统思考寻找杠杠解：跳出树木看到森林，从事务性工作中冷静地抽离，思考全局，不要试图去解决所有问题，智慧地寻找影响系统的关键突破口。

2、深信答案在现场，多踩在泥土里：针对关键突破口思考解决方案，不要闭门造车，或者硬推通用化的课程开发模式及做法，每种方法都有其适用的场景以及背后的假设，每家企业的现实都不相同，深入泥土才能长成适合企业的方法路径。

3、融合互联网思维与OD思维发展人才：综合考量多个相关方的痛点、立场、益处，从对抗（非此即彼）走向融合（兼收并蓄），用过程咨询的方法与内容专家（们）互动，以MVP模式（Minimum Value of the Prototype，最小最有价值原型）快速推出、获得反馈、迭代版本。

进化的方向

笔者后续将从敏捷开发模式（产品版本）、应用场景（产品应用）、经验迁移（方法应用）等三个方面进化。

敏捷开发升级，包括三个转变：

1. 从“实用便捷”到“易用精深”：随着技术氛围与方法导入程度的提升，需要提升敏捷开发每个步骤的深度，开发出易用的工具表格引导，提升分享内容开发的效率与质量。

2.从干货分享到精品课程：除了技术高职本身的专业深度（选取真专家）之外，对培训发展HR而言，要能更好地助推助产，必须提升与技术高职的互动能力甚至牵引能力，这背后的基本功包括业务理解（能否秒懂）、结构化思维（归纳推演）、系统思考（格局视野）、课程开发基础理论（专业深度）、教练引导（对话促动）等等，这些必须有足够的学习与积累。

3. 从专业实用转向学习设计：进一步提升学习体验、设计与优化学习全流程，实现实用+学习体验（互动设计），场域构建（氛围），势能放大（营销、落地）。

 

应用场景扩展：产品运营干货分享推动起来，业务骨干与HR小伙伴双方都有一定的“苦大仇深”感，笔者将探索在产品运营干货分享方面的应用可行性与迭代，力争提高公司知识沉淀效率与学习氛围，提升学员、分享者、培训发展HR小伙伴的幸福指数。

经验迁移应用：发现与洞察在人才发展、团队辅导、组织发展等方面的场景化问题，同时主动走进业务，去理解业务并找到一条快速理解业务的有效路径或模式。

编辑 | 唐裕文