在小米集团,有这样一个部门——信息技术部,即 MIT,支撑着小米集团六大业务领域的交付工作。
MIT 坚持以经营结果为导向,用信息化手段帮助团队做正确有效的事情,最小化过程浪费,并持续积累良性资源,从而保障团队能够具备持续高效率、高质量以及高体验的全链路交付能力。
然而,业务急剧扩张带来的人员增长必然会带来不小的管理压力,想要在此基础上将研发效能大幅提升更是难上加难。但是,MIT 自有一套效能建设办法,成功实现千人团队的持续优化和效能提升。
12月9日,MIT 项目经理骆晓然,做客飞行家俱乐部与飞书项目管理社区联合打造的项目管理研讨会,分享了 MIT 如何通过拉齐标准、统一工具、度量分析等一系列动作提高多条业务线研发效能的实践。
01.效能建设的三大过程
大家好,我是骆晓然,来自小米集团的信息技术部(MIT),今天想和大家聊聊在确保多条业务线顺畅运作的前提下,MIT 是如何构建研发效能体系以达到效能提升目标的。
提到研发效能,我们一般会有两类问题。研发效能到底是干什么的?如何衡量改进动作对业务产生的效果?而 MIT 正是为了解决这两个问题而存在的。
研发效能的建设和提升,往往备受挑战。随着业务增长和团队规模扩张,企业协同和沟通压力也在变大;业务复杂度越高,效能鸿沟也会越大;长线的效能改进也可能因为时间差难以得到业务团队认可。
因此,建设研发效能的过程,需要循序渐进、持续闭环。我们的研发效能改进主要分为三大过程:
首先,用标准统一改进方向;
其次,用工具和线上化能力固化行为;
最后,用度量牵引团队持续进步,从而达到团队自驱改进的状态。
同时,通过实践,我们可以检验这些工具和体系是否适用于我们的团队,并抽练出好的经验和方案,将团队能力转化为组织能力,驱动标准、工具和度量体系持续优化,使其更加适配整个团队的需要。
02.用标准达成共识
在 MIT 看来,标准是一个具有指导性的改进目标,标准的发布也意味着团队对改进做出了硬性承诺。但是,在制定标准的过程中往往会遇到很多挑战。
一方面是各个团队的改进期望复杂多样,因此我们收到了很多不同的声音。
我们首先在在这些声音中定位了两个核心问题,一是组织级别的研发过程的线上化能力比较弱,二是对于历史债务治理的关注度或投入度不够。
然后拉上各业务线的技术负责人和一线 Leader,共同组建了 MIT 技术委员会,并达成了共识的改进方向;也通过焦点访谈等方式与一线同学进行多轮讨论,以验证问题和确认方案。
最终,团队明确了两个改进点。首先,需要统一研判过程管理的标准,以构建线上化能力和提升研发过程管理能力;其次,需要统一管理技术体系,构建统一的技术债,以指导技术债的治理。
另一方面是管理模式多样,标准难达成统一。
在这里,我们需要回顾我们制定这个目标的意义是什么,即告诉全员在什么阶段、扮演什么角色、做什么事情。因此 MIT 制定了一份过程活动标准,无论采用敏捷、瀑布或其他管理方法,都可以适应业务发展。
最终,我们通过不懈努力,在千人团队中成功拉齐并发布了标准。
03.工具带来的组织性变革
对于组织来说,标准不能直接限制每个成员的行为,所以我们需要通过线上化工具来帮助团队成员规避认知问题,减少协作中的不必要浪费。
但是当我们向团队推广工具时,大家会质疑这个工具的能力,担心使用成本和不确定性。实际上,迁移工具代表着组织的变革,变革带来的最直接影响就是组织运转模式的变化。
因此,我们团队并没有从一开始就要求大家必须立即使用飞书项目,而是邀请了对飞书项目感兴趣的团队,针对焦点访谈中提到的一些问题,如协作低效、线上化管理资源不透明等,进行了探讨。我们秉持“先试点再推广”的原则,确保变革成功以及工具顺利落地。
我们直接用飞书项目收集用户需求,帮助完善和优化工具能力。这样,我们在协作过程中不仅能够管理自身需求,还能找出最佳实践推广到全员,逐步扩大影响。
04.度量大盘让效能持续进化
当我们实现了线上化能力时,也要学会用度量去帮助我们了解分析团队的现状,沉淀我们的经验,识别过程中的问题。为达成上述目标,我们构建了效能体系大盘。
但是当我们完成了度量大盘,却没有人关注,因为大家会抱怨度量的数据与实际项目运行情况不符。我们应该先思考为什么会出现这种问题:
在制定标准的过程中,我们是否与团队达成了共识?
这个工具是否被团队真正地使用起来了?
基于此,我们制定了相关指标,并做了详细介绍和统计逻辑解释。我们又梳理出了“飞书项目使用成熟度模型”,解释每一步操作会获得什么样的数据,以及这些数据如何应用于当前要度量的内容中,以帮助团队成员理解他们需要采取哪些相应的行动来确保数据的准确性。
如果这个指标体系发布后,还是产生了数据偏差,那么我们需要通过度量找到偏差的原因,并定位问题比较严重的团队,通过沟通来理解偏差背后的痛点是什么。我们收到的反馈主要有两点:一是容易忘记使用该工具;二是在与业务侧协作时仍然基于表格。
因此我们希望大家能将飞书项目作为会议输入工具,直接用它更新进展、校对需求、做分析等,以帮助团队培养使用工具的习惯。
同时,我们借助飞书项目的集成能力和 API 能力,打破了各个工具之间的数据壁垒。比如,研发人员在 Gitlab 上提交代码分支后,飞书项目就能自动接收信号并流转状态,这样,研发人员就能专注于更重要的事。
05.故事启发的方法论
下面我想通过一些小故事来总结一下我们的方法和经验。
第一个故事是,我在推广吉德林法则的过程中,向团队介绍工具时,团队会误以为只要使用了工具,团队管理问题就不存在了。因此我们需要一个能够识别团队问题并提供明确解决方案的工具推广团队或个人,以帮助我们整个团队更好地拥抱工具并推动线上化能力的建设。
第二个故事是,当我们把霍桑效应应用到研发效能改进中,可以帮助团队养成持续改进的文化,建立连续性的价值观。同时,团队领导也需要持续关注一线成员对改进的态度,以坚定我们持续提升效能的信心。
最后一个故事关于眼镜蛇效应,它给我的启示是要避免度量指标或维度与利益挂钩,因为一旦与利益挂钩,就可能导致数据失真。因此,我们建议进行过程性度量和结果性考核。过程性度量包括交付时长、缺陷密度等方面,而结果性考核则关注系统的可用性、故障数量等方面。
#活动推荐
新一代的飞书项目,7月17日亮相!
诞生于抖音团队实践的飞书项目,是一款能用于复杂场景的专业项目管理工具。
这些年,飞书项目已经走出抖音,走向了千行百业。从互联网到汽车制造、消费电子、金融、医疗健康等各行各业,有包含小米、蔚来汽车、联影医疗、MiniMax、影视飓风等超过 1000 家行业头部企业选择飞书项目。
飞书项目也一直在持续探索,如何提供出更加适配行业,更有深度的流程解决方案?
7月17日,新一代的飞书项目,正式亮相。
我们将顺应从制造走向“智造”的时代变化,发布深入制造行业的 IPD产品解决方案,帮助更多企业通过流程驱动新增长。欢迎扫码预约