TO B业务
|
互联网的上半场是移动端的流量红利，下半场是To B 业务的黄金时代 |
|
To B产品本质上是一种面向生产的工具，企业需要借助产品提升生产效率 |
|
To B产品功能逻辑负责，设计成本高，开发成本高 |
| To B 业务获客成本、交易成本都很高，获客不易留存难 |
SaaS业务的特点
| 维度 |
To C |
To B |
|
产品心智 |
感性至上，注重用户体验，
产品交互 |
价值至上，注重业务梳理，功能明确 |
|
用户心智 |
需求不确定性更强，产品需要快速试错 | 需求相对明确，解决实际问题 |
|
团队心智 |
自己经常玩，一说就懂 | 日常用不到，对产品的深入理解不易 |
|
交易链路 |
往没有复杂的交易链路，直接买单 |
有较长的销售过程，团队协作要求高 客户成功体系对客户服务要求高 |
|
迭代机制 |
规划 设计 迭代 |
产品设计和用户定制的平衡 |
组织能力杨三角
-
组织能力，指的是一个团队可以发挥的整体战斗力，是使团队能够明显击败竞争对手、为客户创造必要价值的关键力量。
-
组织能力的重要性：成功= 战略 * 组织能力
员工思维之打造更好的文化价值观（1）
员工思维之打造更好的文化价值观（2）
治理方式一架构与流程
破局，打造高效能研发团队
–敏捷交付体系
-KPI与OKR结合的目标管理体系
-虚实结合的战斗阵形、特种作战分队
-研发团队能力提升之道
敏捷交付体系(1)
•高效能：快速、可持续地交付稳定 的产品和服务
•对于B端SaaS产品，功能稳定和 性能指标是生命线
•目标：80%的需求？？天内交付
敏捷交付体系(2)
敏捷交付体系(3)
通过工具来承载研发流程
-
组织管理
-
目标管理
-
产品管理
-
项目管理
研发效能指标体系
目标：
数据可信、驱动改进
量化指标：
产品交付质量：线上缺陷数/线上需求缺陷密度
QA测试质量：漏测率(线上Bug数/线下Bug数)
自动化质量：问题召回率/报警准确率
DEV提测质量：线上缺陷数/线下需求缺陷密度
方法论:
标准化：
规范公示->公示->执行->优化
平台建设-> 指标数可视->质量管理赋能
数字驱动：基线设定-> 量化考核-> 月度复盘-> 持续改进
执行策略:
技术推进：依次覆盖逐个推进 黑盒->灰测->接口自动化->静态代码-> 专项->单测->ui自动化
管理推进：多轮迭代持续改进 规范宣贯、执行监督、回溯复盘、措施改进
敏捷交付体系
-
技术架构的合理性一定是先导
-
通过工具沉淀方法论，规范作业流程，通过技术手段提升效率
-
指标体系的建设不是目标，是管理改进的抓手
KPI与OKR结合的目标管理体系
KPI考核的缺陷
-
研发工作的特点注定了 KPI往往难以量化
-
随着团队扩大，只有KPI很难做好目标的分解与传递
-
通过KPI结果建立对目标的牵引，但是过程难以管控
OKR的应用
-
通过OKR传递组织目标，统一团队认知，上下同欲
-
OKR作为思考框架和纪律要求，通过里程碑的方式管理重要的工作事项，比如效能平台、服务治理平台、微前端框架等基础设施建设
-
OKR不落地到具体个人，只到部门(Team Leader)
能力成长
-
团队能力成长是管理者最重要的工作之一
-
组织有责任和义务打造学习的文化氛围和创造学习的条件
-
保持技术的开放性，支持引入新框架、新技术，不断探索
-
加强和外部团队的交流与协作
-
鼓励甚至是强制技术分享
总结
-
To B业务对研发团队有不一样的挑战：业务复杂、理解难度高、 交付期望高
-
效能提升，不仅要依赖研发流程和效能工具的完善，更需要整个 组织能力的提升
-
我们通过组织架构优化、效能平台建设、组织目标牵引合理化、 团队能力提升等各种维度的不断完善，以提高研发效能
原文始发于微信公众号（二进制跳动）：To B高效能研发体系构建实践框架
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167293.html
