这一章讲产品、技术、运营三类中台岗位怎么把日常动作做成可核对的方法。八条建议按性价比分三档排列——前四条是线上应急、需求分析、运营口径和跟前台协作，成本接近零；第五到第七条是还技术债、需求池排序和判断增长阶段；最后一条是专家、管理、转前台之间的路径选择。 ---
说人话： 技术岗一半的活是把已经上线的系统稳住。框架和工具会换，处理线上问题的方法不会：先想办法把问题复现出来，再看日志和监控定位到具体环节，先用最快的方式止血，事后把过程写下来。固定按这四步走，同类问题下次能更快处理。
怎么做： 上线前把监控和日志准备好，错误率、响应时间、核心业务指标能在同一处看到；出问题先确认多少用户、哪些功能、从什么时候开始受影响，能回滚就先回滚，恢复服务后再查根因；处理完当天或次日写复盘，写时间线、影响面、直接原因、根本原因、后续动作和负责人，只写事实、不写谁的责任。
来源： Beyer, B., Jones, C., Petoff, J., & Murphy, N. R.（编）（2016）.《SRE：Google运维解密》. 电子工业出版社. https://book.douban.com/subject/26875239
限制与争议： 应急流程各公司差异很大，有的团队要求先止损，有的要求先保留现场，以所在团队的规范为准；复盘写得过细很占时间，重复出现的小问题可以合并记录。
说人话： 产品岗的活大多绕不开有人要一个功能。收到需求先别急着画原型，先把三件事问清楚：要解决什么业务问题、影响哪些用户、做成什么样算达成。这三件事说清楚，做不做、先做哪个、要多久才有讨论的基础。
怎么做： 每个需求先写一句话背景，说清谁在什么场景遇到什么问题、现状的代价是什么；写清目标，用哪个指标判断做成、现在多少、期望到多少；排期时带上工作量拆解，逐块给时间并说明依赖和风险，需求变更就重新评估，把新增工作量和被挤掉的需求一起摆出来让提需求的人自己选。
来源： 帕顿（2016）.《用户故事地图》. 清华大学出版社. https://book.douban.com/subject/26760348
限制与争议： 需求全都想清楚再动手，在快速试错的场景里会拖慢节奏，判断标准是这个需求做错了要付多大代价；在需求主要由上级决定的环境里，产品岗能做的筛选空间有限，重点放在把信息补全。
说人话： 运营动作多，做完容易说不清效果。办法是先定口径：这件事怎么算做成、看哪个指标、指标怎么算、从哪个系统取数。口径固定下来，再拿趋势而不是单个数字判断好坏。
怎么做： 动作开始前写清目标、核心指标和辅助指标，把数据来源和统计周期一并写明；把口径写进一处共享文档，写清指标名称、计算公式、取数位置、更新频率，避免不同人报数不一样；做一个简单看板只放核心的几个指标，按天或按周更新，数据异动先排除口径和统计范围变化，再判断业务是不是真变了。
来源： 克罗尔、约斯科维茨（2014）.《精益数据分析》. 人民邮电出版社. https://book.douban.com/subject/26278639
限制与争议： 指标不是越多越好，太多会互相打架，抓住一到两个核心指标更实用；品牌、口碑这类结果短期难以量化，要配合用户访谈和定性判断。
说人话： 前台要快、中台要稳，冲突是岗位设定带来的，不一定是人的问题。能减少消耗的做法是：把工作量讲清楚、把选择权交给对方；把每次都要重新谈的规则固定下来。
怎么做： 拒绝需求时给出理由和替代方案，把「做不了」换成「要动三个系统、大概十个工作日，只上临时方案三天能好，你选哪个」；需求提报用统一模板写描述、背景、影响范围、期望时间和负责人，并提前写清优先级谁定、多久排一次、什么算紧急、紧急顶掉谁；主动同步进度，做完、卡住、要延期都提前说，反复出现的争议处理完补一条规则，不靠临时协商。
来源： 无
限制与争议： 如果前后台的考核指标本身对立，流程和沟通方式只能缓解消耗，解决不了根子上的冲突，这类问题要看组织层面怎么设计；团队小、协作人数少时，临时沟通可能比立规则更快，通融和按规则之间要有边界。 本条属经验判断，缺少可核实的统一统计。
说人话： 为了赶时间先上线、以后再改，是常见的欠账。欠着不还，后面加功能越来越慢，改一处容易引出别处的问题。把还债和上线节奏一起排进计划，比攒到只能推倒重做便宜。
怎么做： 建一份技术债清单，标出哪些模块问题多、影响多大、重构大概要多久，按影响排优先级，每次迭代固定拿一小块时间处理，做一点还一点；上线按固定节奏走，小步分批，每次准备好回滚方案和触发条件，上线后盯一段监控再收工；选型看长期维护成本和团队熟悉度，不为追新引入接不住的组件。
来源： Fowler, M.（2014）. TechnicalDebt. https://martinfowler.com/bliki/TechnicalDebt.html
限制与争议： 没有统一的官方口径能给出合适的还债比例，具体拿出多少时间要看项目阶段；即将下线且运行稳定的模块维持现状可能比重构划算，固定节奏上线在需要快速响应的业务里也不一定适用。
说人话： 需求从各个方向来，来者不拒的结果是池子越来越大、什么都做不深。把需求统一收在明处，按价值和成本排先后，再定期清理，是把有限人力用在关键处的做法。
怎么做： 所有需求走同一个入口登记，写清要做什么、为什么做、谁提的、影响多大；排序时逐个问三个问题，带来多大价值、要花多少成本、不做会怎样，价值高成本低的先做，价值高成本高的拆成小步分期做，价值低成本高的不做；定期清理已经不做、背景变了、排很久还没动的需求，说明为什么不做并给出依据。
来源： 无
限制与争议： 打分排序解决不了短期看不到收益、长期必须投入的方向，比如基础设施和合规改造，这类要靠判断而不是打分表；强行给所有需求量化打分容易为凑分而失真，需求来源集中、决策链短的环境里，产品岗能调整的空间也有限。 本条属经验判断，缺少可核实的统一统计。
说人话： 增长分两段。第一段找方向：用户少、模式没定型，重点是低成本地试，找到能留住人的那件事。第二段放量：方向已经验证，重点是把它变成能重复执行的流程，靠分层和多渠道把量做上去。用错阶段的方法，要么慢，要么乱。
怎么做： 冷启动阶段一次只试一个假设，用最小成本验证，不行就换，先盯少数真实用户亲自聊，记下他们的使用场景和不满；放量阶段先把拉新、激活、留存、付费、推荐的链路拆开，找出当前最卡的一环集中资源打；给用户分层、不同阶段用不同策略，把渠道分散开，每个动作都记下假设、做法和结果，形成可重复的流程。
来源： 莱斯（2012）.《精益创业》. 中信出版社. https://book.douban.com/subject/10945606
限制与争议： 阶段划分是连续的，实际工作中常常两段并行，很难划出明确的分界线；面向机构客户的产品，冷启动周期可能长达数年，不能用面向个人用户的节奏去要求。
说人话： 中台岗做久了都要面对往哪走。专家、管理、转前台三条路没有绝对的好坏，差别在时间和精力怎么安排。判断依据放在能核对的地方：做什么事有成就感、受不了什么、手上的能力在市场上值多少。
怎么做： 列一份清单，看过去一年让自己有成就感的几件事分别偏向钻研、带人还是拿业务结果；查一下所在方向和相邻岗位的薪酬区间，用公开招聘信息对照，不要只凭印象；专家路线选一个单位需要、市场也认的方向深耕，把方法和成果写成能对外讲清的东西；管理路线在没升职时就练带人、拆任务、对结果负责；转前台先在内部找接触业务的机会，补齐业务知识，不要裸辞。
来源： Allen, T. J., & Katz, R. (1986). The Dual Ladder: Motivational Solution or Managerial Delusion? R&D Management, 16(2), 185–197. https://doi.org/10.1111/j.1467-9310.1986.tb01171.x
限制与争议： 三条路在实际中常常混合，很多人的路径是先在专业上做出成果再带小团队；不同公司对专家序列的支持差别很大，有的只有管理一条通道，选之前先确认所在单位有没有对应的职级体系。
本章小结： 中台岗的活可以拆成几件事：技术岗把线上问题的处理拆成复现、定位、止血、复盘四步，并在每次迭代里留出还技术债的时间；产品岗把需求写成要解决什么问题、影响谁、怎么算做成，再谈排期；需求统一进池子，按价值和成本排序并定期清理；运营岗先给动作定口径和指标，用趋势而不是单个数字判断；做增长先分清冷启动和放量两个阶段，用对应的做法；跟前台协作时把工作量讲清楚，把反复出现的问题写成规则。往哪走，用能核对的标准来选。