做事方法-读书笔记

做事方法

工作中成为做事靠谱的同事

  1. 相较于做事的态度，重点在于做事的能力；
  2. 做事能力的评价标准
    1. 思维闭环，从端到端的角度思考和落地
      1. 事前规划，例如需求的背景和价值（体现主动原则）；
      2. 事中执行，所有人关注的阶段；
      3. 事后总结，例如需求上线后的业务数据和回收效果，做这件事情的收获（体现成长原则）；
    2. 做事有方法论
      1. 基于标准执行流程/行为模板，保证交付结果的下限；
      2. 基于数据模型，提供逻辑支撑；
    3. 成果导向（体现价值原则）
      1. 实践是检验真理的唯一标准；

做事方法论


团队规划法

团队中每个人都需要参与团队规划

  • 团队领导：制定团队规划，整体方向、目标、节奏；
  • 团队成员：拆分团队规划，具体事项、成效、节点；

KPI

KPI（Key Performance Indicator，关键绩效指标）

  1. 自上而下分解公司的目标；
  2. 相关指标衡量执行的效果；

KPI的问题

  1. 只适合目标稳定的标准化工作
    • 流水线生产的KPI：产量/停机时间/良品率；
    • 产品销售的KPI：销售量/市场占有率；
    • 技术创新既不能稳定产出，又难以标准化；
  2. 给团队带来不好的风气
    1. 故意定低指标，以便容易实现；
    2. 追求短期利益（业务指标），忽视长期效益（稳定性）；
    3. 只看指标，忽视人的情感；
    4. 重视绩效考核及量化数据，忽略本职工作；

互联网应用的困惑 KPI 弊端
后端研发的工作如何量化？ 代码行数？版本数？
bug等级及数量？		 坏味道代码，频繁发布影响线上
研发与测试争执不下
技术团队怎么体现工作贡献？ 技术团队背30%的业务指标 业务吃肉，技术喝汤
业务挨打，技术罚站
有风险的工作谁愿意做？ 新技术引入 犯错风险，不确定收益

常见技术团队的规划角度 详情 陷阱
解决问题 解决版本延迟、线上 Bug 和团队成员士气不高等问题 解决问题肯定有价值
优化性能 团队优化，比如提升开发效率和质量，提升团队成员战斗力；
技术优化，比如将 App 的崩溃率从 0.5% 优化到 0.3%，将后台接口响应时间从 50ms 优化到 30ms。		 没有完美的系统和产品，肯定能找到可量化的优化
引入新技术 比如引入 Flutter 来实现双端统一开发，引入机器学习来实现系统的某个功能。 新技术有可能让生产效率或者生产质量大幅提升，
既可以提升团队技术水平，又可以提升产品竞争力。

从这些角度来做 KPI 规划，往往拿不到很好的绩效结果。

  1. 这些都是团队和技术的角度，没有结合业务目标，就算实现了既定目标，也无法体现业务价值；
  2. 团队的资源是有限的，团队规划需要考虑如何创造出最大的价值（投入产出比最大化）。例如出海项目App降低崩溃率 < 当地用户UI改版

OKR

OKR（Objectives and Key Results，目标与关键成果）

  1. 设定业务目标，例如提升市场占有率。
  2. 为每个目标设定关键结果以及具体的标准，例如为实现上述目标，准备“请 XX 明星做代言人”、“投入 100 亿做用户补贴”等。

OKR和KPI的区别

规划法 关键词 区别 足球运动员 曹操专车的业务负责人 索尼
KPI 数据指标 履行职责，局限于当前手上事情 进球数、助攻数、跑动距离和比赛场次 司机数量、订单数和乘客数 彩色显像管电视机销量
OKR 业务目标 业务价值，考虑更多的选项，根据实际情况判断和选择 夺冠、四强和保级 让曹操专车成为网约车行业第二 液晶和等离子电视转型

不同的指标在在不同的时期重要程度是不一样的，有的指标甚至是互相冲突的。

  • 例如在某手游交易网站的 KPI 讨论场景中，产品经理列出了 5 个指标，用户量、成交额、用户安全、发货速度和收入，然后给每个指标设定了一个增长量；

  • 如果业务目标是做到市场份额行业第一，那么用户量作为核心指标必须增长，你需要到百度买流量、补贴新用户和免交易手续费等，但这样做肯定会增加支出、减少收入；

  • 如果集团要求创新业务必须实现盈亏平衡，那么收入作为核心目标必须增长，你就不能免除交易手续费，而是要实现交易阶梯收费，但这样又会影响用户量和成交额，因为会有一部分用户会因为手续费的原因而转移到其他交易平台。


OKR 和 KPI 的联系

  1. OKR：先根据环境变化和业务发展进行判断和取舍，明确业务目标，再基于目标分解出合理的 KPI；
  2. OKR的KR有两种表现形式，
    1. 一种是 KPI，可以量化的KR，例如用户量增加xx百分比；
    2. 一种是里程碑，可以衡量的关键节点，例如创新业务全链路打通运行；

OKR的表现形式

总结

  1. OKR是基于业务目标拆解后的KPI和里程碑；
  2. KPI让我们正确地做事，OKR让我们做正确的事。

3C方案设计法

背景：领导审批/跨部门协作时，他人对你的方案提出挑战

  1. 有些情形没有考虑到；
  2. 无法证明你的方案优于其他方案；

3C方案设计法：每次做事都至少设计 3 个方案，选择最优的几个方案执行，其中C代表Choice，选择。

事情 方案1 方案2 方案3
设计缓存方案 Memcache + MySQL Redis Redis + MySQL
处理表现不好的新员工 立即辞退 观察期为6个月 多指导与沟通
分享《大厂晋升指南》 笔记总结网上发布 群聊主题分享 跟晋升提名的同事/应届新人分享

三个阶段完成方案设计

  1. 预研阶段，设计出 3～5 个备选方案；
    1. 迫使自己想出3个备选方案，思考多种可能性，避免错过更好方案；
    2. 研究不同方案的优缺点，有助于系统理解领域内知识和技能；
  2. 讨论阶段，评审每个方案；
    1. 汇总备选方案，与上级和同事方案评审；
    2. 聚集他人信息、观点和疑问，完善每个方案中优缺点、依赖条件和所需资源的理解；
  3. 决策阶段，挑选最终方案
    1. 互斥方案，选出最优方案落地；
    2. 并行方案，3选2或者5选3落地；

自己审视——》团队审视——》团队决策——》自己执行


工作效率的影响

  1. 事情整体效率提高：多个方案准备，一次评审决策>一个方案预设，多次执行调整
  2. 团队效率提高：方案完备，执行到位>谈论热烈，执行反问

晋升/面试的帮助

  1. 平时总结，应对“为什么”提问，例如为什么采取这个方案；
  2. 掌握方案设计评价标准；
  3. 系统理解领域知识，掌握领域技能；

1个方案是陷阱，2个方案是困境，3个方案是选择。


PDCA执行法

工作规划——》落地执行

PDCA执行法

PDCA 执行法：将事情的执行过程分成四个环节：计划（Plan）、执行（Do）、检查（Check）和行动（Act）。

  1. 适用于“负责人”，例如Team Leader、虚拟团队负责人和领域负责人等，涉及制定计划、拆解任务、协调资源、安排责任人和检查结果等工作；

  2. 其他人遵循项目计划，执行具体事项。


联系及区别

OKR、3C方案设计、PDCA都与规划相关

  1. OKR做正确的事情;
  2. 3C方案设计挑选最优的方案；
  3. PDCA执行做好事情；
方法 关键理念 核心目的 时间跨度 总结
OKR规划法 去做正确的事情 对齐业务和团队规划 至少3个月
一般6个月或者1年
不超过3年		 OKR 制定整体规划，例如业务规划KR“新用户增长 100 万”，运营团队 TL 分解出KR“买量 60万”
3C方案设计法 充分设计方案 选择最优方案 与规划同步 3C 选择实现方案，例如对比抖音、快手、微信购买渠道——》从抖音买量 60 万
PDCA执行法 做好事情 保证事项落地执行 至少1周
一般2周或者1个月
不超过3个月		 PDCA 落实具体任务。例如分为4个阶段
第1月：买量10万观察验证，运营、产品、技术观察留存率；
第2月：买量20万验证调优，运营、产品观察留存率；
第3月：买量40万加大验证，运营观察留存率；

使用技巧

  1. 计划：确定具体任务、阶段目标、时间节点和具体责任人。
    1. 处理重要且紧急的事情：临时止血，长期规划；例如Redis出现未授权访问漏洞，先通过防火墙访问控制，后续再升级Redis版本修复漏洞。
    2. 处理重要但不紧急的事情：按事件类别/时间迭代拆分多个小项目；例如优化存储系统设计，按事件类别拆分为分库分表、大表归档和缓存优化，涉及表较多，再将每个表按照时间迭代规划；
    3. 学会找上级协调资源；
      1. 原因：详细分析后发现人力投入比预估多，或者涉及跨团队资源协调；
      2. 协调人力资源，调整事项优先级；
      3. 成立虚拟的工作组；
      4. 向上级汇报计划，广播相关成员；
  2. 执行：按照计划落地各项具体的活动，例如技术人员完成方案设计、编码和测试等工作。
    1. 根据情况采取相应的管理风格，详见管理五模式_；
    2. 做好信息同步
      1. 问题发生、定位和解决第一时间汇报
      2. 进展定期通晒，例如周报/周会；
      3. 关键节点汇报；
  3. 检查：对照计划检查实际执行结果，明确哪些符合预期、哪些不达预期、哪些超出预期以及存在什么问题。
    1. 归结深层内部原因，尤其是自己的原因，详见5W根因分析法
    2. 下游通知修改业务类型的值（0为单车、1为助力车——》1为单车、2为助力车），有一处遗漏，导致线上问题，复盘
      1. 研发，测试，产品，业务全流程问题；
      2. 作为研发，新业务含义需定义新业务类型使用，就算值相同，方便后续统一修改；
  4. 行动：基于检查的结果，总结经验和教训，明确下一步需要采取的措施。
    1. 汇报整体结果；
    2. 总结经验和教训，不超过3个改进点优化流程；

5W根因分析法

找准问题源头，既治标又治本。

5W根因分析法：重复问五次“为什么”，起源于日本丰田公司生产过程中的问题分析。

问题 回答 相应措施
为什么机器停了？ 机器超载，保险丝烧断了 更换保险丝
为什么机器会超载？ 轴承的润滑不足 给轴承上润滑油
为什么轴承会润滑不足？ 润滑泵失灵了 更换润滑泵
为什么润滑泵会失灵？ 它的轮轴耗损了 更换轮轴
为什么润滑泵的轮轴会耗损？ 杂质跑到里面去了 铺上防杂质的滤网

业务分析场景

在某交易平台的业务规划目标讨论会上，了解业务目标背后的深层考虑。

问题 回答
为什么今年的业务目标是成交金额翻番？ 只有成交金额翻番我们才能达到盈亏平衡点
为什么今年要求达到盈亏平衡点？ 集团要求我们的业务能够自负盈亏
我们本质上还属于创新业务，为什么集团要求我们的业务能够自负盈亏？ 因为疫情的影响，集团需要开源节流，减少非盈利业务的持续投入

涉及集团的决策背景和讨论信息，继续追问业务团队，难以得到确切答案，且对业务规划目标理解没有更多帮助。

问题数量不是关键，找到根本原因才是关键。

  1. 下一个问题是对上一个回答的进一步深入；

  2. 建议不小于3个，超过7个还未找到根因，需要审视提问是否焦点偏移；


技术学习场景

验证是否深入理解Netty网络高性能的核心原理。

问题 回答
为什么Netty网络处理性能高？ Netty 采用了Reactor模式
为什么用了Reactor模式性能就高？ Reactor模式是基于IO多路复用的事件驱动模式
为什么IO多路复用性能高？ IO多路复用既不会像阻塞IO那样没有数据的时候挂起工作线程，
也不需要像非阻塞 IO 那样轮询判断是否有数据。
为什么IO多路复用既不需要挂起工作线程，也不需要轮询？ IO多路复用在一个监控线程里面监控很多的连接
没有IO操作时，挂起监控线程；
有连接进行IO操作时，操作系统唤起监控线程处理。
那还是会挂起监控线程啊，为什么这样做就性能高呢？ 单个监控线程切换的性能影响忽略不计；
工作线程没有IO操作时，不会阻塞，可以执行计算任务；
因此大幅度提升了系统的整体性能。

技术深度学习，详见链式学习法：提升技术深度

方案选择，详见3C方案设计法

面试连环炮/晋升连环问训练，多问自己一些为什么


管理改进场景

在某次项目延迟问题的讨论会上，找出项目延迟的核心原因。

问题 回答
为什么项目延迟了？ 要等测试环境进行测试
为什么要等测试环境？ 只有2套测试环境，2套都已经用于另外两个项目
为什么只有2套测试环境，不能搭建多套吗？ 现在没有机器用来搭测试环境了，而且我们有将近 20 个子系统，搭建一套可用的测试环境耗时可能要一周
为什么会没有机器，直接申请机器不就可以了？ 测试环境对机器性能要求不高，基本能跑就行
那为什么不找运维申请过保机器（使用超过3年的机器，即使没坏也要换掉）用来搭建测试环境？ 之前没想过这个方案

没有新机器搭建测试环境——》申请过保机器搭建

搭建一套可用环境太耗时了——》测试开发部启动一个基于Docker的快速搭建环境的项目，5min生成可用环境


实际应用，应需注意

  1. 首先要明确问题本身，很多情况问题定义不明确，例如“成交量大幅下降”，下降多少幅度？同比/环比？子业务/所有业务？
  2. 其次友好声明，对事不对人，避免引发情绪对立；
  3. 如上文所述，问题数量不是关键，找到根本原因才是关键。

5S问题处理法

找到根因——》处理问题

处理问题是一个复杂的系统工程

  • 既反映专业能力，又反映综合能力；
  • 问题既可能拖垮绩效，又可能成为晋升机遇；
  • 关键在于如何有效地去处理。

5S问题处理法：明确问题（Specify）——》拆解问题（Split）——》定位问题（Seek）——》解决问题（Solve）——》落地行动（Sort）

  1. 明确问题

    1. 问题本身尚未明确定义，直接采取行动——》做了很多事情，但无法衡量
    2. 量化的问题，关键在于确认数据是否准确
      1. 最方便的方法是让数据部门去核对，但是可能耗时比较长；
      2. 最快速的方法是通过多个关联数据互相验证。
    3. 没有量化的问题，进行量化
      1. 可以量化但是还没量化的，例如“业务增长放缓”，业务增长的定义，放缓的程度，跟老板和业务对齐；
      2. 无法简单量化的，例如“团队士气不高”，调查问卷综合多数人的主管感受

  2. 拆解问题

    1. 拆解维度

      • 业务类问题按照业务类型拆解，或者按照客户群体拆解；；例如电商业务的“订单数下降 30%”，——》“男装下降了 20%”、“鞋类下降了 30%”、“食品下降了 20%”，其它品类的数据增长。

      • 管理类问题按照流程拆解，或者按照事项分类拆解；例如“团队研发效率不高”——》“会议太多”、“测试环境不足”、“发布太麻烦了”和“需求变更太频繁”。

    2. 根据子问题的数量和规模，看是否申请团队资源；

    3. 拆解技巧

      1. 子问题数量 2～5 个，尽量独立；
      2. 明确子问题负责人，组成工作组，定期向上汇报进展。

  3. 定位问题，尝试找到根因，给出终极解决方案，详见5W根因分析法

  4. 解决问题，提供多个方案，包含建议和依据，交由上级拍板，详见3C方案设计法

  5. 落地行动，按照阶段/团队/短期紧急/长期重要的优先级排序，详见PDCA执行法


4D总结法

事中执行阶段的方法论，提升获取好结果的概率，但无法保证。

  1. 使用3C方案设计法，决策过程仍然有可能有失误。
    1. 受限于团队整体的技能限制，分析和讨论备选方案时遗漏了一个重要的方案；
    2. 决策时判断标准有问题，对性能要求估计过高，实际上线后业务量远低于预期；
  2. 使用PDCA执行法，执行过程仍然有可能出现偏差。
    1. 具体执行时，受到使用者的水平和投入资源等因素的限制；
  3. 外部因素干扰
    1. 例如某海外钱包团队用3C方案设计法设计出了最优的业务方案，但是当地政局不稳定，导致跨境消费剧烈减少，然后又发生疫情，导致本地消费大幅减少，最终结果不好。

做事的方法很重要，回答考察规划和执行相关的“为什么”

做事的结果也重要，回答考察做事结果相关的“为什么”

  1. 你认为这个结果怎么样？你怎么评价这个结果？
  2. 为什么你认为这个结果不好？
  3. 为什么你的方法挺好但是结果不好？
  4. 你从这个结果得到什么经验和教训？

结果不好的事情，需要分析原因，总结经验教训；

结果好的事情，需要讲清楚个人对结果的贡献。

4D总结法：从结果、数据、技术和成长4个维度整理自己的做事收获。

  1. 结果，关注事情的价值（虚）

    1. 业务开发团队，从业务角度总结
      1. 业务开发项目，例如业务用户日活
      2. 技术优化方案，例如性能提升
      3. 管理措施，交付效率和质量的提升
    2. 中间件开发团队
      1. 从系统的性能、可用性和成本等方面
      2. 已产品化，从销售量或者流量等方面
    3. 技术支撑团队，例如运维/测试部门，从质量、效率和成本方面

  2. 数据（实）

    1. 列出相关的数据；
    2. 理解数据背后的含义，尤其是对数据的评价以及评价的标准；
    3. 不好量化/临时需要补数据，找多人评估取平均值；

  3. 技术

    1. 学到了什么新的技术；
    2. 对哪些技术有更深或者更全面的理解；

  4. 成长

    1. 关注个人综合能力成长

      1. 对业务的理解能力
      2. 项目组织能力
      3. 带领团队的能力
      4. 沟通能力
      5. 做事方法

    2. 业务总结示例

      问题 示例
      业务的适用场景是什么？ 用户的主场景：礼包、下载、找游戏。
      目标用户是谁？ 消磨零碎时间不是用户玩手游的最主要场景，反而是 63% 的用户在成块的闲暇时间体验手游。
      目标用户有什么特点？ 用户的几个典型弱点：贪婪（礼包、活动、抽奖）、懒惰（信息流）、虚荣（等级、成就）、窥探（笑话、八卦）。
      解决了目标用户的什么问题？ “没时间玩”成为最主要的原因，是否说明用户对 app 的定位就是工具型，需要的时候用一下，不需要的时候根本不会去看。
      实际的效果如何？ 游戏衍生内容好坏对用户根本性影响非常弱，
      这个结论直到最后才发现，之前基于这个判断决策。
      快速验证，最多观察一年
      用户为什么喜欢/不喜欢这个功能？ “没有”和“偶尔”用竞品的竟然占了 90%，这说明几个竞品没有差异化（定位都一样），用户只需要其中一个。

  5. 总结

    1. 一个持续1个月的项目，熟练后约花费1个小时；
    2. 笔记列出关键点；
    3. 系统整理，发表文章/团队内分享；

金字塔汇报法

总结主要是面向自己做梳理，更强调自己个人的贡献，以及事情的价值和细节；

而汇报主要是面向领导做组织提炼，更看重团队整体的结果，以及事情的逻辑和关键。

金字塔原理是美国人巴巴拉·明托提出的一种关于思考逻辑的方法论。

  1. 核心思想是任何事情都可以归纳出1个中心思想；
  2. 中心思想可由3~7个论点支持；
  3. 论点可由3~7个论据支撑。

基本原则

  1. 结论先行，二八原则分配时间

    问题 技巧
    不要讲这么多细节，挑重点讲 先重要(结论)后次要(结论)
    先全局后细节
    能不能用一两句话概括一下这一年的工作 先总体(结论)后细分(结论)
    先论点后论据
    听下来感觉去年团队很辛苦、很努力、拼劲十足，
    但我怎么没看到最后拿到的结果    		 先结论后原因
    先结果后过程

  2. 自顶向下，用下层的信息支撑上层的结论

  3. 归类分组，下层的数量控制在3~7个

  4. 逻辑递进，同级别的内容具备逻辑关联一致性/顺序性


某海外移动钱包技术团队的汇报内容

  1. 总体结论：团队完成从0到1的搭建，但业务发展止步不前

    1. 团队：从0到1搭建完成
      1. 团队初具规模
      2. 全栈团队成型
    2. 业务：止步不前
      1. 用户量增长较慢
      2. 用户活跃度不高
      3. 新业务无亮点

  2. 具体分析

    1. 团队初具规模，总人数20人(HC目标22)，招聘16个，转岗4个
      1. P5：3人
      2. P6：12人
      3. P7：4人
      4. P8：1人
    2. 全栈团队成型
      1. Android：4人
      2. iOS：3人
      3. 前端：6人
      4. 服务端（Java）：7人
    3. 用户量增长较慢，全年新增用户xx万，同比增长xx%
      1. A业务：:AAU用户总数xx万，同比增长xx万
      2. B业务
      3. 未达预期原因分析
        1. 本地用户不习惯这种新的支付方式
        2. 推广力度不够
    4. 用户活跃度不高，日活用户占总用户数比例不高
      1. A业务：DAU用户数xx万，占比xx%
      2. B业务
      3. 未达预期原因分析
        1. 没有高频应用场景
        2. 不符合本地用户习惯
    5. 新业务无亮点
      1. X新业务:新增用户xx万，日活xx万
      2. Y新业务
      3. 未达预期原因分析
        1. 没有熟悉本地环境的产品经理

  3. 关键事项

    1. 全局大图，展示整体情况，例如电商业务。电商业务大图

    2. 演进路径，展示个体的发展路径和当前所处阶段，例如推荐系统演进。推荐系统演进路径

    3. 时间轴，来展示事情发生过程，例如MongoDB 编年史。

      MongoDB 编年史

  4. 总结改进，一般分为业务、技术和管理，每种类型3~5条

    1. 团队

      1. 团队成员80%是新招聘的员工，需要继续加强业务熟悉程度和企业文化建设
      2. P5+P6的成员占了75%，需要优化团队结构，构建合理的团队梯队
      3. 前端团队经常成为项目资源瓶颈，需要继续招聘2人以上

    2. 业务

      1. 加大资源投入力度，增加推广力度
      2. 招聘本地的产品经理
      3. App按照本地用户的审美和操作习惯改版

四线复盘法

事后总结阶段，正常收获总结和成果汇报，

但当发生明显问题时，就需要问题复盘。

  1. 讲清楚事实；

  2. 梳理所有问题，分析定位根因；

  3. 明确责任分配和处罚措施；

  4. 制定可落地的改进措施；

降低问题的发生概率和影响。

四线复盘法：公平公正地组织复盘，告诉你怎么思考和改进。

  1. 时间线：问题发生的经过；

    1. 问题发现、问题处理过程中采取的各种关键措施、问题恢复的时间和问题影响的结果；
    2. 对应问题发现速度、各项措施执行时间和团队响应效率等指标

  2. 问题链：问题的传导路径；

    1. 业务流程：分析各个关联的系统；
    2. 项目流程：分析各个阶段相关的人员，比如开发、测试、产品和运维等；
    3. 先按照业务流程，定位到单个系统，再按照单个系统的项目流程，将问题定位到具体的人或者流程中的某个步骤；

  3. 责任链：问题责任人之间的关系；

    1. 结合时间线中问题影响的结果、公司的故障定级标准和问题链的分析，最终确定哪些团队或个人应该承担责任，分别承担多大的责任，接受什么样的处罚。
    2. 制定明确的定责标准有利于尽量减少争议
      1. 违反公司规章/制度/流程的承担主责。比如公司规定必须要有灰度策略才能升级，某业务版本直接全量升级导致发生问题；
      2. 出现重大纰漏的承担主责。比如测试时漏测了某个常见的业务场景，导致上线后发生问题，测试承担主责，产品承担主责(因为上线前验收阶段没有发现问题)，开发反而不一定承担责任(看具体的公司和团队要求)；
      3. 问题源头承担主责。比如A系统磁盘故障导致接口响应很慢且问题持续很长时间，从而进一步导致B系统对外响应也超时，这种情况下A系统应该承担主责，B系统承担次责；
      4. 问题放大者承担主责。比如A系统磁盘故障导致接口响应很慢但只持续了几分钟，结果诱发了 B系统的设计缺陷，导致B系统瘫痪超过1小时，这种情况下B系统应该承担主责。

  4. 改进线：问题的改进计划；

    1. 流程上的调整（增加或删除流程步骤）；
    2. 技术上的手段（增加功能、优化系统）；
    3. 团队方面的措施（学习、培训、奖惩机制）；
    4. 具体可落地，例如提升团队质量意识——》团队参加公司的质量规范学习和考试、推行Code Review；

线上问题复盘案例

某次线上故障导致用户下单后无法支付

简单线上商城的架构

时间线

  1. 2020.07.24 10:23 风控服务进行了系统升级，支持新的风控策略；
  2. 2020.07.24 10:28 客服收到第1条用户投诉，投诉内容：无法进行支付，客服引导用户尝试更换支付渠道，投诉内容解决；
  3. 2020.07.24 10:38 客服累计收到30无法支付的投诉，根据客服管理条例，问题升级上报给业务值班长，业务值班长启动应急，召集订单服务、支付服务、会员服务、风控服务的负责人开始分析问题；
  4. 2020.07.24 10:50 支付服务的负责人抽查10个投诉用户的日志进行分析，累计收到30无法支付的投诉，根据客服管理条例，问题升级上报给业务值班长，业务值班长启动应急，召集订单服务、支付服务、会员服务、风控服务的负责人开始分析问题；
  5. 2020.07.24 11:30 风控负责人反馈暂时没有定位出详细原因，但今天系统进行了升级，很大概率和升级有关，建议回滚版本；
  6. 2020.07.24 11:40 风控服务相关的项目经理、产品经理、开发测试等人员决定回滚，开始回滚版本；
  7. 2020.07.24 12:10 风控服务回滚新版本完成，通知客服进行观察；
  8. 2020.07.24 12:30 客服反馈又收到了无法支付的投诉；
  9. 2020.07.24 12:40 支付服务和风控服务排查这次拒绝支付时正确的，建议客服继续观察；
  10. 2020.07.24 13:30 客服反馈没有新的无法支付的投诉；
  11. 2020.07.24 15:00 客服反馈只有1例无法支付的投诉，支付服务和风控服务排查是正常的风控拒绝；
  12. 2020.07.24 16:00 业务值班长、客服、各系统技术负责人讨论，确定本次应急结束；
  13. 2020.07.24 18:00 支付系统分析出受影响的用户数为2000人，实际放弃支付的人数为200人，涉及总金额为10000元，重试不同渠道后成功的有1800人；
  14. 2020.07.25 14:00 风控服务定位出问题根因后修复问题，重新升级版本；
  15. 2020.07.25 18:00 观察4小时，确认没有问题，问题解决。

问题链

业务流程涉及风控服务和支付服务

风控服务的项目流程

  1. 运维人员升级风控服务；
  2. 测试人员修改几十个配置，不小心将其中1个值的0输入成O了；
  3. 产品验证的时候只挑选了几个大的银行渠道，正好没有验证到出问题的银行渠道；

责任链

  1. 业务流程涉及风控服务和支付服务

  2. 风控服务的项目流程

    1. 运维人员升级风控服务；
    2. 测试人员修改几十个配置，不小心将其中1个值的0输入成O了；
    3. 产品验证的时候只挑选了几个大的银行渠道，正好没有验证到出问题的银行渠道；

  3. 定级定责

    1. 损失10000元，根据公司故障定级标准，属于轻微级别，惩罚措施是贡献活动经费；

    2. 最终责任链

      责任 惩罚措施
      风控服务承担主责，支付服务不承担责任 技术负责人贡献团队经费1000元
      风控服务的测试人员承担主责 贡献团队经费500元
      风控服务的产品人员承担次责 贡献团队经费200元

改进线

  1. 时间线

    待改进点 改进措施 责任人 时间点 备注
    风控服务定位问题从10:50到11:30，花费了40分钟
    定位不出来才反馈可能跟升级有关    		 应急流程明确出问题后第一时间明确是否有升级、修改配置、更换机器等变更操作
    而不是先定位问题根因    		 业务值班长 2020.07.31 流程制度上的改进
    风控服务的版本回滚从11:40到12:10，花费了30分钟
    耗时较长    		 优化版本回滚速度
    将回滚耗时从30分钟降至5分钟内    		 风控服务技术负责人 2020.10.31 技术上的改进

  2. 问题链

    待改进点 改进措施 责任人 时间点 备注
    测试人员修改几十个配置
    不小心将其中1个值0输入成O    		 系统增加配置有效值检查
    包括值的类型、范围等，避免人工检查疏忽    		 风控服务技术负责人 2020.09.30 通过技术手段避免人的失误
    产品验证的时候只挑选了几个大的银行渠道
    正好没有验证到出问题的银行渠道；    		 所有渠道都需要验证，不能只抽查
    如果人手不够，可以让测试人员一起验证    		 风控服务项目经理 2020.08.31 流程制度上的改进

引用

  1. 推荐一文：绩效主义毁了索尼
  2. OKR概念
posted @ 2023-12-24 14:51  蒋智  阅读(65)  评论(0)    收藏  举报