线上故障复盘会开到一半有人问起某个接口当初为什么这样设计。在场的人给出三种说法有人说当时评估过另一个方案有人说那个方案早就被否了至于否决的理由没有人记得。只能去翻半年前的聊天记录翻了很久只找到一句结论。这个场景在很多研发团队里反复出现。讨论的时候人都在信息也齐全讨论结束之后决策就散在消息流、会议上的口头结论和几个人的记忆里。过一段时间再问谁都不敢确定当初是怎么定的。这篇不推荐工具只讨论一个具体问题研发团队的技术决策怎么留存。要回答它得先看清丢的是哪一层再按讨论、评审、需求变更三类场景分别处理。一、研发团队的技术决策为什么留不住1、三个反复出现的现场有一种现场是同一个问题被重复讨论。半年前定过一次项目负责人换了又重新讨论一遍结论还可能和上次不一样。另一种现场是需求改过之后团队对改动范围的认知不一致。产品记得改过开发记得只是加了个字段测试的用例还是按旧口径写的问题要到联调阶段才暴露。还有一种现场是老成员离开或者转岗某个模块的判断依据跟着消失。接手的人只能从代码里反推反推不出当初的取舍。2、讨论没少丢的是结论讨论不稀缺稀缺的是讨论结束时那句可以被引用的话。一段讨论的结束标志常常是没人再说话了而不是形成了一句写清楚的结论。消息流还在检索也能搜到但完整的上下文要重新读一遍才能拼出来。真正需要留存的是三样东西当时的背景、评估过的选项、最终的选择和理由。聊天记录保存的是过程不是决策。3、哪些决策值得留存不是所有讨论都要记录。值得留下来的通常是影响跨模块或跨团队的、回滚代价高的、几个月后还需要向人解释的决策。反过来写法约定、命名习惯、一次性的排查过程放在原来的位置就够了。留存范围放得太大记录这件事本身就会先失败。先划清这个范围再谈记录方式动作才不容易变形。二、判断问题卡在哪一层上面三种现场看着相似卡住的位置却不一样。改流程之前先花十分钟判断问题出在哪一层。1、载体这一层打开团队的沟通工具搜一个半年前的关键决策。如果能搜到明确的结论这一层没有问题。如果搜到的是一串需要重新阅读的对话说明决策没有独立的位置。2、形式这一层回顾上一次评审会问一句会议结束的时候有没有产生一份能当作结论的东西。只有讨论记录而没有结论下一个接手的人仍然要重新判断一遍。3、关联这一层需求变更之后受影响的开发和测试能不能被及时通知到。如果结论和需求、任务、版本之间没有关联变更就只能靠人挨个打招呼漏掉谁全凭运气。4、一张对照表定位问题层级观察到的现象判断信号优先修复的方向结论只能靠翻聊天记录找到决策没有独立载体给结论固定落点讨论过但没人说得清结论缺少收口动作讨论结束当场收口变更后有人不知道联调才暴露结论与需求任务没有关联建立关联与通知三层的修复顺序不建议颠倒。越过判断直接采购工具多数时候只是把分散的记录换个地方继续分散。任何一层留着没解决记录都会慢慢失效。三、讨论的留存给结论一个独立的位置讨论是决策产生的起点也是结论最容易丢掉的地方。1、讨论可以散结论必须收约定一个收口动作。讨论结束时由主持人或者提议人写一句结论附上理由和仍然待定的部分。谁负责收口要事先指定不能默认落到发起人身上。收口不要求写成长文三五行写清楚就够但这件事要当天做完隔一天回忆就会失真。2、给每类讨论一个固定的落点日常方案讨论、评审会、变更沟通分别应该落在什么位置团队需要事先约定。约定好之后有一个直接好处找结论时不用猜它在哪个软件里。临时交流照旧在群组里进行需要被保留的结论统一放在同一个位置。3、搜不到等于没留留存能不能生效取决于检索。按关键词、按参与者、按时间范围至少要有一种路径能快速定位到当时的结论。多端同步同样关键。如果结论只存在某一位同事的电脑上它就不算留下来了。结论沉淀在机构自建的服务端账号和数据由机构自己掌握成员通过终端接入访问留存和权限控制才能同时成立。四、评审的留存结论和理由都要留下讨论解决了结论能不能被找到评审还要解决另一件事结论能不能被读懂。1、只记结论三个月后就没人懂架构决策记录里有一条被广泛采用的做法记录只追加不修改。决策发生变化时新增一条记录并标明它取代了哪一条。这么做保留了方向变化的时间和原因。后来的人看到的不是一份被反复改写的文档而是一串可以追溯的判断。2、一条合格的评审记录要写清什么字段写清楚的样子等于没写的样子背景与问题具体到场景和约束一句技术升级需要备选方案至少写出被放弃的那个只写最终方案取舍理由说明为什么不选另一个只写选了哪个影响范围涉及模块、接口、排期不写影响复审条件什么情况下需要重新评估不写表格的第三列是最常见的写法写的人当场看得懂三个月后的人看不懂。评审记录的价值不在篇幅而在这五个字段有没有落到实处。3、被否掉的方案更要留没被采纳的方案和否决理由是很少被写下来的部分也是后来被反复重新提出的部分。当时把握不大的决策也值得记录。写清楚这一点将来重新评估时就有依据不必推倒重来。五、需求变更的留存让每次改动都能追溯评审管的是做决定的那一刻需求变更管的是决定之后的变化。1、没有基线就说不清改了什么判断一项内容属于新增还是原有前提是有一份当前有效的范围说明包含要交付的内容、验收标准以及这一版明确不做的部分。版本不统一的时候先统一版本再讨论变化。否则双方各按自己的版本执行争的其实不是方案。2、变更要留住影响分析一条变更记录需要回答五件事改什么、为什么改、影响哪些模块和测试范围、增加多少工作量与风险、谁做的决定。比如一个字段改名看起来只动了一处文案实际可能牵涉数据库、接口和导入模板。只记录改了什么而不记录代价同类变更还会再来一次。3、口头承诺不算记录讨论里的零散意见可以作为线索但不能自动成为执行依据。团队需要明确只有进入记录并经过确认的结论才生效。六、研发团队怎么验证留存机制有没有生效机制立起来之后研发团队还需要有办法判断它是不是真的在起作用。观察三个信号就够了。1、看新人上手要不要重新问一遍新成员能不能通过检索独立还原某个模块的决策背景是判断机制是否有效的一个直接信号。如果每个新人都要挨个问老同事记录就还停在形式上。2、看同类问题会不会被反复决策统计一段时间内重复出现的议题。如果同一类问题在几个月里被讨论了三次说明前两次的结论没有被用起来。3、机制跑偏的三种常见样子一是只写结论不写理由记录变成了通知。二是记录散在太多位置检索成本反而上升。三是把记录动作压在某一个人身上这个人一忙记录就停。对应的矫正动作也简单把理由写成必填把位置收敛到一处把收口动作分摊到每次讨论的主持人。机制不必一次铺开。先在一个小组、一类决策上试行跑顺了再扩大范围。总结回到开头那场复盘会。让人为难的从来不是选择本身而是选择的依据已经找不到。技术决策的留存考验的不是工具采购能力而是一支研发团队把口头共识转成可追溯记录的习惯。它由三个动作组成讨论结束当场收口评审记录写清理由变更留下影响分析。这三个动作不会让研发团队少讨论一次但会让下一次讨论从结论开始而不是从回忆开始。