小米集团，有这样一个部门——信息技术部，即 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产品解决方案，帮助更多企业通过流程驱动新增长。欢迎扫码预约

于产品经理需不需要懂技术这个问题，经常来源于产品经理和研发团队之间的battle。其实这个问题的答案，就藏在问题的背景信息里。

试想一下，如果一个产品经理，不论是刚入门的，或是已经有过多年从业经验的，如果稍微懂一些常见技术的实现方式或技术实现的原理、逻辑，这一场场的battle还能挑得起来么？！

如果是刚入门的产品经理，可以暂时不知道某些功能的技术实现逻辑，在高级产品经理的指导下或是参照竞品开展产品设计工作就行。即便在某些业务场景下的功能实现方式与研发成员认为的有冲突，也可以让高级产品经理出面做出解释，或者直接和研发团队硬刚，这便是工作中产品经理和研发团队最常见的冲突。

然而，不论是高级产品经理的解释或是跟研发团队的硬刚，恰好说明了产品经理在有了一定的从业经验后，还是要懂技术或是要具备技术思维，即了解技术实现方式、领域内常用的技术架构、技术发展趋势及应用价值。

如果一直不愿意去了解技术，也不主动学习，甚至排斥，那在以后的工作中和研发团队的沟通只会越来越困难。

再加上现在产品经理这一职业正在走向细分，有些职位甚至明确要求产品经理必须精通招聘方指定的某一项技术，可以说懂技术已经成为当下产品经理的一项重要技能了。

那么，究竟要懂到什么程度呢？

1、了解常用技术的基本概念

首先，要知道当前主流技术的概念吧。

学知识，其实学的就是概念。

就像面向对象这个概念，是研发人员解释现实世界的一种方法。

在设计有多级分类的产品功能时，产品经理就需要理解「对象」和「类」的概念。如果产品经理脑海中没有面向对象的技术实现原理的话，在设计这个多级分类功能时，就会要求技术实现自由手动调整层级和并认为这是很容易实现的。但在研发人员看来，哪有产品经理描述得那么简单，一旦向产品经理询问相关细节，产品经理就开始急了。毕竟在研发团队眼中对类和对象的思考是为了完成从功能视角向技术视角的转变，在产品经理眼中就是动动鼠标的事儿。

产品经理如果不理解这些最基本的技术概念和技术原理，只是轻描淡写的认为很容易实现的话，冲突就在所难免。

除此之外，还有像「写死」、「架构」、「进程」、「同步/异步」、「接口」等。

比如「写死」，对研发人员来说，就是一些参数或配置是否要写死，除非有新版本更新，否则这些参数或配置项对用户来说基本上不能手动更改。

针对这个概念，产品经理就要考虑在设计与下拉菜单的交互时，定义清楚是哪配置项或参数因行业需要、或法律法规要求、企业管理上的需求，必须写死，并给出经相关人员确认的配置项或参数值。

如果产品经理本人对此也不确定，也不经查证，没有明确定义就要求研发人员写成灵活可配的，这在研发人员眼中就没有了业务参考标准和交互标准，意见不一，最终还是会把分歧导向产品经理身上。

这种情况尤其在B端产品领域更加明显，有些行业的B端产品需要遵循国际规范、国家规范、甚至还有一些地方标准需要遵循，一些第三方认证机构、企业自身也有不一的参照标准。这时的产品功能需求对「写死」这一技术要求就更加严格，不懂这一技术实现方式的产品经理别说跟研发团队了，也有可能与销售、客户产生冲突。

除了上述这些，还有几个会引发理解歧义的技术概念，比如联调、缓存、数据传输格式、高并发、日志、定时任务、脚本、爬虫、性能测试、灰度发布、SDK、APi、框架、脏数据、第三方登陆、埋点等。可以结合所在行业、常用产品功能、业务特征对其进行释义并附以案例说明，作为产品经理的技术知识库，提高和研发团队的沟通效率。

2、理解技术发展路线

其次需要掌握的是技术路线图。

技术路线图是对产品路线图的补充，它把技术规划与单个产品或产品线的总体规划统一了起来。

业界最常见、最具参考价值的就是Gartner公布的技术路线图，它公布了大多数常用技术的生命周期曲线，也指明了引进新技术的时机与条件，对产品的差异化创新具有很强的指导价值。

Gartner安全运营成熟度曲线

上图是Gartner在今年发布的有关安全运营技术的成熟度曲线。这种利用技术进化时间和市场期望值制成的模型，已成为资本市场投资热点、社会舆论造势、企业开展技术创新的研发依据和选型标准。

每一个技术都会经历图中的五个阶段：

第一阶段：技术萌芽期——这个时候一些新产品已经出现在市场上，早期公众的关注会把它演绎出极个别成功的案例故事，大众开始在网络上高谈阔论。于是进入第二个阶段。

第二阶段：期望膨胀期——在此阶段，随着各路媒体的大肆宣传和报道过度，非理性的渲染，采用了这些技术的产品知名度无处不在，新技术在各个行业都开始受到热烈追捧，这种追捧情绪达到顶峰，它的价值被夸大很多倍。

第三阶段：幻想破灭期——随着这项技术的缺点、问题、风险、技术限制出现，失败的案例逐渐大于成功的案例，大部分项目开始被市场验证是行不通的，新技术被鼓吹的泡沫破灭等。

第四阶段：复苏期——媒体不再传播该技术。很多技术案例都是该阶段销声匿迹的，但仍然会有不少公司会继续创新，在历经前面阶段所存活的技术经过多方实验和有侧重点的实践，对它的适用范围及条件限制以更加客观的方式在一些项目上开始逐渐稳定，并且知道该技术哪些方面有用，哪些无用，逐渐开始获得收益，这时该技术会再次受到主流媒体与业界高度的注意，这个时候技术的好处已经被一些行业典型客户广为接受。

第五阶段：生产成熟期——技术的好处已经广为展示和接受，新科技产生的利益与潜力被市场实际接受，进入了非常成熟的阶段，大家都在默默使用它，此处通常正式升级，进入新一轮的萌芽期。

我们广为熟知的5G技术、大数据技术、现在的AIGC都经历过这样的发展路线。

对产品经理来说，了解常用技术的发展路线图，能更好地指导产品路线图的规划与设计，让产品规划方案与技术成熟度相吻合，这也是有序地规划产品功能的一项核心能力。

在B端领域，有些走在技术创新前沿的客户，会要求企业提供针对新技术理念的培训，这个时候就需要产品经理和研发团队针对客户对产品的技术创新需求，专门研究和整理技术概念、实现原理、应用场景、应用价值预测等资料，这个过程也是产品经理进一步掌握技术实现方式的最好契机，为下一步在产品设计中应用储备知识。

其实，懂技术对产品经理来说一个加分项。在考虑需求实现方式时，能优先考虑技术实现效果最佳的方式，能在设计用户体验时兼顾技术实现需求，还能和开发人员进入深入地探讨，输出高质量的产品设计方案。

3、掌握数据分析技术

在有些分享中，也把它称为数据库技术。在大数据领域，也叫数据仓库技术。这对产品经理来说需要掌握的知识范围太大，我更倾向于理解和应用数据仓库技术中的OLAP（分析型数据库）技术，即帮助产品经理快速实现多维分析查询的一种方式。

因为对数据的多维查询与分析，是证明产品功能在上线后是否真正具有业务价值的最佳证据。

对产品经理来说，掌握数据分析技术有两种应用场景:

一是在产品没有上线之前，产品经理使用数据分析技术对用户调研问卷的分析。即便这些数据量不大，掌握基础的数据分析技术能让产品经理对问卷分析结果的来证明自己对用户需求的洞察与判断更有说服力一些。这个时候有Excel工具即可，结合常用的数据分析模型，比如对比分析法、分类分析法、相关性分析法等模型对调研数据进行多维分析，指导需求分析和进一步的用户关注点挖掘。

二是在产品上线之后，产品经理更要掌握和使用数据分析技术来评估产品的运营情况。

毕竟很少有企业专门给产品经理开发一个产品运营数据的监控系统，这个时候，如果产品经理懂一些数据分析技术，就可以从研发人员处获取阶段性数据库，使用主流的数据分析工具比如tableau进行个性化分析，比如相关性分析法、周期群分析法、RFM、AARRR等，为自己的质疑提供数据支持、为下一步的功能迭代提供数据依据。

也有人会说，公司有专门的商业分析部门，不需要产品经理掌握这些吧。确实是，只不过产品经理掌握数据分析的目的和商业分析部门掌握数据分析技术的目的不同。

产品经理掌握数据分析技术，是为了支持自己的产品规划，为了验证需求开发优先级是否合理，为了让自己的产品创新方案具有数据支撑。洞察力再强的产品经理所得出的结论也大多是定性的，在高层和其它部门人眼中这属于“猜想”，没有依据。而数据，就是强有力的依据。尤其是从数据发现的机会点和产品经理的预判吻合度越高，越能进一步提高产品经理的洞察力。

从这三个层面来看，产品经理懂技术，不是要求会写代码，而是具备技术思维，把这种思维方式用在功能设计中，用于对技术发展趋势的理解中，用在对产品的数据分析中，更好地提升产品经理的分析与决策能力，也不会出现和其它部门之间的battle。

家好，我是灸哥，今天我们一起来聊聊关于技术领导力的那点事儿～

在科技迅速发展的今天，技术领导力已经成为团队甚至企业竞争力的关键要素。

在灸哥看来，作为一位技术领导者，他不仅需要具备深厚的技术背景，还需要在管理、沟通、战略规划等方面展现出色的能力。

那么，我们应该如何培养技术领导者，塑造未来的技术领导力呢？

一起聊聊吧，刚好这两年灸哥的经历还是有很多成功经验的～

图片来自网络