小张的方案和他的方案第七周周一排期估算初步完成、Must have从十二条精简到九条之后陈钊在午休前收到了小张提交的技术方案文档。小张负责的是最核心的用户故事——“会员等级计算规则重构”。陈钊打开方案看了一遍。小张的思路是新建一套等级计算引擎用规则配置化的方式替代现有的硬编码逻辑支持后台动态配置等级阈值。陈钊看完之后第一反应是——“这个方向我不太同意。”他心里的想法是等级计算规则确实需要重构但现有系统的硬编码逻辑虽然不优雅实际上运行稳定而且改动频率很低——大概半年才调整一次阈值。为了一个低频操作建一套规则引擎过度设计了。他更倾向的方案是保留现有计算逻辑的框架把阈值参数提取到配置文件加上一个简单的管理后台页面做阈值编辑。改动量小风险低而且完全够用。但他没有马上说我不认可这个方案。因为上周Planning Poker的场景还历历在目小张给这个故事打了5分他打了8分。当时的分歧经过讨论后统一到了5分说明小张对这块的理解确实比他更深入。现在小张拿出了一套方案而陈钊的第一反应是不对他需要先问自己一个问题——我是不同意这个方案还是不同意小张这个人这是两种完全不同的判断。评审方案不是评审人很多技术方案评审表面上看是在讨论技术路径实际上掺杂了大量的人际因素。最典型的情况有三种第一种资历压制。资历深的人说我当年就是这么做的没问题资历浅的人就算看到了风险也不敢提。老赵之前不太配合新流程某种程度上就是因为这个——做了十几年技术突然要按一个新来的管理者定的流程走心理上需要一个适应过程。第二种权威压制。管理者说我觉得应该这样做团队就顺着说对就这样。不是团队认同是团队服从。陈钊自己也差点犯这个错误——他看到小张的方案之后第一反应是不对如果不是及时踩了一脚刹车他可能直接就说你改成我说的这种了。第三种沉默压制。新人看到问题不敢说因为怕暴露自己不懂。上次Planning Poker小周打了一个13其实就是一个新人鼓起勇气暴露了自己的不确定——如果那个场景不是匿名打分小周大概率会沉默地跟着大多数人写一个5。**这三种情况有一个共同点评审的焦点从方案好不好跑到了谁提的方案上面。 方案是新人提的就被轻视。**方案是管理者提的就不被质疑。方案是老员工提的就默认是对的。陈钊意识到如果他想让方案评审真正有效他需要先把评审的焦点拉回方案本身。怎么做他和张栋梁商量之后梳理了一套方案评审的标准框架。方案评审的四个维度维度一方案是否服务于需求目标这个维度回答的是——方案要解决的那个问题和需求定义的那个问题是不是同一件事前面讲到的需求评审五问里前两个问题就是为谁做和为什么做。方案评审的第一步就是回扣这两个问题——你的方案到底在服务谁、服务什么目标张栋梁在评审前加了一步“每次方案评审我先对照需规文档里的’为谁做’和’为什么做’确认方案的目标没有偏移。”拿小张的方案来说需求目标是会员等级计算规则重构支持新的等级阈值配置。小张的方案——规则配置化引擎确实服务于这个目标。陈钊倾向的方案——阈值提取到配置文件也服务于这个目标。两个方案在维度一上都是合格的。维度二方案的技术可行性这个维度比较常规——方案在技术上能不能跑通有没有已知的技术风险性能、稳定性、兼容性有没有考虑小张的方案在技术可行性上没有问题。规则引擎的思路成熟市面上有大量参考案例实现。当然陈钊倾向的方案也没有技术风险。两个方案在维度二上也都合格。维度三方案的复杂度是否匹配需求价值这个维度回答的是——为了实现这个需求付出的技术复杂度值得吗小张的方案规则配置化引擎开发周期约两周后续维护需要理解规则引擎的配置逻辑。陈钊倾向的方案阈值提取到配置文件开发周期约三到五天后续维护门槛低。需求价值是什么会员等级阈值调整频率约半年一次。用两周做一个半年才用一次的功能还是用三到五天做一个够用的方案答案很清楚。维度四方案是否考虑到后续扩展这个维度要格外小心——不能过度设计也不能完全不考虑未来。规则引擎方案的优势在于扩展性好如果未来等级规则越来越复杂配置化引擎可以快速响应。但问题是如果这两个字背后没有数据支撑——谁说等级规则会越来越复杂产品那边没有任何这方面的规划。陈钊倾向的方案扩展性弱一些但后续如果真的需要升级到规则引擎从配置文件迁移过去的成本不高。两个方案在维度四上各有优劣但考虑到未来需求不明确过度预留扩展性反而是风险。不是你听我的是我们讨论清楚陈钊把四个维度的分析整理了一下约了小张单独聊。他没有说你的方案过度设计了。他说的是“你的方案在技术可行性和扩展性上都没问题但我想和你讨论一下复杂度是否匹配需求价值。”他把自己考虑的点娓娓道来“等级阈值调整频率是半年一次你设计的规则引擎开发周期约两周我倾向的方案约三到五天。两者都能满足当前需求。如果产品没有明确的规则复杂化趋势规则引擎的投入产出比可能不太划算。”小张听完想了想“你说得有道理我当时设计规则引擎主要是考虑到以后规则可能会变多。但如果产品那边没有这个规划确实没必要提前投入。”陈钊问“那你觉得如果先用配置文件方案后面需要升级的时候迁移成本多大”小张说“不大。配置文件的结构设计和规则引擎的配置结构其实可以保持一致后面迁移就是换一个解析层改动量可控。”陈钊说“那就先按配置文件方案走如果后续产品有规则复杂化的需求我们再评估是否升级到规则引擎。你把方案调整一下评审会上由你来讲。”小张点了点头。陈钊在这次方案评审中学到了三件事第一先对齐四个维度再讨论技术路径。没有维度框架的方案评审容易变成我觉得A好和我觉得B好的主观之争。四个维度把讨论锚定在了客观标准上。第二让方案的提出者做最终汇报。小张的方案被调整了但最终在评审会上讲解和回答问题的人还是小张。陈钊没有把我说了算变成方案也是我定的。第三把结论变成共识。如果陈钊直接否掉小张的方案小张会觉得我辛辛苦苦写的方案被一票否决。但通过四个维度的讨论小张自己得出了先不做规则引擎的结论——这不是被否定是被说服。说服和否定是两种完全不同的沟通结果。评审会上的人周三下午方案评审会。小张在白板上画了调整后的方案架构图讲得条理清晰。老赵提了两个关于兼容性的问题小张一一回答了。小李问了配置管理的细节小张也给出了明确的方案。陈钊全程没有打断。他只在最后问了一个问题“如果半年后产品说等级规则要加一个新的计算因子这个方案的扩展性够不够”小张说“配置文件的结构已经预留了扩展字段加一个新的计算因子只需要加一个配置项和一段计算逻辑改动量可控。如果后面规则复杂到配置文件搞不定了我们再评估是否升级到规则引擎。”陈钊点了点头“OK。”他注意到一个细节——老赵全程没有说我觉得应该这样做也没有说以前我们都是怎么做的。他只是在提具体的技术问题。当评审的焦点被锚定在四个维度上的时候资历压制和权威压制自然会弱化。因为讨论的不再是谁的方案而是方案是否经得起四个维度的检验。方案评审之后周五陈钊把这一周的心得写进了笔记本。“方案评审技术标准占一半人际尺度占另一半。”“技术标准四个维度——需求目标、技术可行性、复杂度匹配度、扩展合理性。这四个维度不是教条是一个让讨论回归’方案本身’的抓手。”“人际尺度评审者的角色不是裁判是引导者。你的任务是让团队围绕四个维度讨论清楚不是替团队做决定。如果你替团队做了决定方案的质量就是你的质量不是团队的质量。”“让方案的提出者自己被说服而不是被否定——这是方案评审中最难也最重要的沟通技巧。”张栋梁在旁边补了一句“以后我把这四个维度加到需规模板里。每个技术方案在提交评审之前提交者先自己过一遍四个维度写一段自评说明。这样评审会上就不是从零开始讨论而是基于已有的分析做校准。”陈钊说“好加上。”好的流程不是为了让管理者更轻松是让团队更可靠。下期预告《需求变了又变了——拥抱变化的正确姿势》——方案定了排期定了团队正在全力推进。但产品突然说有一个小改动然后再加一个功能然后这个需求优先级提高了——变更是项目管理中最让人头疼的事。但问题不是会不会变而是变了之后怎么办。。S2E4 完 | 约3500字//技术心路//