01 / DEFAULT
系统化应当是业务的默认思考方式
在一个成熟的业务组织里，人员可以流动，关键角色可以更换，上下游合作方也可以更迭，但这些变化都不应该破坏业务的稳定性。高频、高风险或多人交接的业务，应建立更明确的规则、证据链和异常处理机制。
理想的业务更像一个定义清晰的接口或 API：对于符合约定的输入，它按照明确规则处理，并稳定输出高质量、可验证的结果；对于不符合约定的输入，它也能识别异常、给出反馈，而不是依赖某个关键人物临场救火。
这个类比强调的是输入边界、处理规则和异常反馈，而不是把复杂业务误认为完全确定的程序。
02 / QUALITY
高质量输出的三个标准
- 01
符合现实世界的运行逻辑
它不能只在纸面上自洽，还必须能在真实的资源、成本、责任和时间约束下执行。
- 02
解决实际问题
输出的价值不在于展示方法有多复杂、工具有多先进，而在于能否让业务状态发生真实改变。
- 03
能够用简单语言解释
一个不掌握专业术语的人，也应该能够理解流程运行的基本原理，以及系统为什么这样运转。
我不会把时代红利、组织资源或职位头衔单独当作方法有效性的证据。它们可能帮助结果发生，却不能替代对方法本身的验证。方法是否有价值，仍要回到具体环境、适用条件和可复核结果。
03 / FRAMEWORK
一套五层工作框架
- 01
回溯上下文，重新定义问题
面对一个复杂业务问题，我不会立刻给出方案，而是先回溯它的形成过程：业务背景是什么，问题从哪里产生，背后的原因是什么。接着复盘历史上已经尝试过的各种解法、产生的效果，以及为什么经过这些尝试后，它仍然是一个没有被解决的问题。
完成回溯后，我才会与业务方确认当前真正的卡点、希望我解决的具体问题，以及双方可以达成的合理预期。否则很容易用一个看似完整的方案，解决了错误的问题。
- 02
拆解实现路径，设置分层目标
合理预期不能只停留在一个最终目标上。我会先分析目标的实现路径，再从路径中定义若干里程碑，让每个阶段都有可以检查的完成标准。
如果“2”是承诺目标，那么“1”是最低可接受结果和兜底方案，“3”是超预期目标。执行时以“3”为牵引，取法乎上，争取稳定实现“2”；但最终验收仍以“2”为准，不能因为完成了“1”就把未达标重新解释为成功。
如果执行过程中关键前提发生实质变化，应当显式重订承诺目标和验收标准，而不是在结果出现后单方面降低口径。
- 03
保留最小决策证据
执行过程中不必事无巨细地记录所有动作，但至少要保留三类信息：项目背景、决策依据和预期达成的结果。它们分别回答“为什么会有这件事”“为什么当时这样决定”和“这次行动原本希望改变什么”。
后来的人只有同时看到这三部分，才能倒推出当时的判断过程，而不是只看到一个脱离上下文的结果。
- 04
以里程碑为控制点，定位偏差并调整路径
当实际结果偏离预期时，我会先回到最近一次有证据确认完成的里程碑，检查从那个节点之后的执行情况。这样可以把问题限制在一个明确区间内，而不是每次出现偏差都推翻整个项目。
复盘时先核对路径和里程碑事实，再识别新增不确定因素及其促进或阻碍作用，重新评估达成难度，最后检查执行是否到位。这个顺序可以避免一出现偏差，就把所有问题简单归因于执行人员。
- 05
把业务手感转化为可传递的判断记录
我目前仍有一部分判断依赖业务手感。它通常表现为一套基于业务手感的主观评价标准：在每个节点，结合已经观察到的事实、上下游反馈和资源状态，判断完成度以及继续达成目标的可能性。它能够适应复杂环境，但目前还没有形成足够明确、可传递的沉淀，因此仍然存在关键人员依赖。
这一层的目标不是消灭业务手感，而是把它外显化。每个里程碑至少记录：原本应达到的状态、当前观察到的事实、判断可完成或不可完成的原因、正在促进或阻碍结果的不确定因素，以及下一步保持或调整的动作。
04 / EXAMPLE
虚构示意：一次跨团队上线为什么延后
完全虚构 · 仅用于说明框架 · 不对应任何真实客户、公司、项目或业绩
某项跨团队新服务在第四周偏离了原定里程碑
某项由产品、运营和审核团队共同推进的新服务，计划在六周后开放。第四周的里程碑是“核心流程联调完成”，第五周是“小范围试运行”。
- 回溯问题：复盘历史尝试后发现，此前的延迟主要来自需求范围反复变化；当前真正的卡点则是审核规则尚未确认，而不只是技术开发速度。
- 拆解路径：最低目标是核心流程可用并保留人工兜底；承诺目标是核心流程和异常反馈机制同时上线；超预期目标是在此基础上增加自动化报告。
- 保留证据：记录为什么选择这条路径、每层目标依赖什么前提，以及这次上线原本希望改变什么业务状态。
- 按节点纠偏：第四周复核发现，技术联调已经完成，但审核规则仍未确认。新增审核要求形成阻碍，临时增加的审核支持形成促进；综合判断后，承诺目标的实现难度变高。继续检查执行，发现规则确认事项虽然被多次提醒，却始终没有明确责任人和截止时间。
- 外显业务手感：团队记录当前事实、难度判断、促进与阻碍因素，并决定冻结非核心需求，为规则确认指定责任人和截止时间，同时保留最低目标中的人工兜底方案。
05 / BOUNDARY
适用边界与局限
这套框架更适用于多人协作、周期较长、结果可以分阶段检查且不确定性较高的业务。对于低风险的一次性事项，完整使用五层框架的记录成本可能高于收益，此时只保留目标、事实和下一步即可。
它不能替代专业判断，也不能保证目标一定达成。它的作用，是让判断依据、偏差定位和路径调整更容易被验证、更容易被后来的人接手。
06 / CHECKLIST
在称它为“系统”之前
- 问题的背景、来源和成因是否已经被重新梳理？
- 历史解法、实际效果和未解决原因是否已经复盘？
- 当前卡点、预期结果和验收标准是否已经对齐？
- 实现路径是否被拆成可以检查的里程碑？
- 最低目标、承诺目标和超预期目标是否清楚分开？
- 项目背景、决策依据和预期结果是否能够追溯？
- 结果偏差是否能定位到最近一个里程碑之后？
- 新增不确定因素及其促进或阻碍作用是否被识别？
- 路径调整和执行复盘是否被分开判断？
- 关键业务手感是否已经转化为别人能够理解的记录？
系统化不是把人从业务中移除，而是让业务不再只能依赖某一个人。真正成熟的系统，应该允许人员、角色和合作关系发生变化，同时保留稳定、可验证、可复用的解决问题能力。
本文是 Ma Xinyang 对个人工作方法的阶段性整理。文中的案例为虚构示意；真实案例将在完成授权、脱敏和事实核验后另行发布。