第一次变更第八周周三会员体系升级项目进入第三周九条用户故事按计划推进六个人各忙各的小张偶尔还要抽时间看看智能推荐的技术预研。下午两点业务产品经理王磊给陈钊发了一条消息“陈钊有个小调整。运营那边反馈现在的等级升级条件里需要加一个’连续活跃天数’的维度就是用户不仅要满足消费金额还要满足连续登录天数才能升级。改动不大你们加一下”陈钊让负责这个模块的开发评估了一下反馈说加一个计算因子到等级规则配置里改动量大概半天就好。陈钊答复王磊“可以半天能搞定不影响整体排期。”他甚至没也花多余的时间去思考增加一个计算因子半天工作量确实不大。第二次变更第八周周五王磊又来了。“陈钊运营又提了一个诉求——能不能在会员详情页加一个’成长值进度条’就是让用户看到自己距离下一个等级还差多少他们说这个对用户感知很重要能提升升级动力。”陈钊皱了皱眉这个不在原始需求里。他让负责前端的同学进行评估反馈说加一个进度条后端要提供一个成长值计算接口改动量大概两天到三天。“不影响整体计划推进吗”“压缩一下其他故事的时间可以消化。”陈钊想了想答复王磊“可以加但这是第一次变更之外的新增需求。我记录一下后续如果再有类似的新增需要重新评估对整体排期的影响。”王磊说“应该没有了就这一个小功能。”第三次变更第九周周二王磊第三次找上门来。“陈钊上周老方和老板开会老板看了会员体系的演示版之后提了一个想法——能不能把积分体系和会员体系打通比如积分达到一定数量可以自动升级会员等级老板觉得这个联动效果会很好。”陈钊听完这个消息深吸了一口气。三次两个星期之内连续提了三次变更。第一次加一个计算因子——半天。第二次加一个成长值进度条——两到三天。第三次积分和会员体系打通——这是系统级联动涉及两个核心系统的接口改造至少需要一两周。他把三次变更的内容拉在一起看了一会儿。如果每次变更都是小改动那三次加在一起就是一次大改动。但每一次被提出来的时候需求方的口径都是就一个小调整、“应该没有了”、“老板觉得效果会很好”。没有人有恶意王磊只是每次收到运营或上面的反馈就习惯性地转给技术。张薇要618数据看板的时候也是这样能多提就多提但每个人都只看到了自己提出的那一块没有人从全局视角评估加在一起会怎样。变更不是问题没有管理的变更才是*陈钊没有直接拒绝第三次变更。他做了一件之前没做过的事——把三次变更拉在一起做了一次系统性评估。他打开笔记本列了一张表三次变更累计改动量已经超过13个工作日而整个项目的排期缓冲张栋梁帮他从Planning Poker数据里算出来的只剩不到7天。这意味着如果接受第三次变更项目一定延期。陈钊把这个数据整理好约了王磊和张栋梁一起开了一个短会。他没有直接反馈你们变更太多了我接受不了。他说的是“王磊我把最近三次变更的改动量做了一次汇总累计需要13个工作日左右项目周期只剩不到7天。如果接受积分和会员体系打通整体提测里程碑需要向后推至少一周。”然后他做了一件更重要的事——把变更放回了需求五问的框架里做校准。“王磊我们回到需求五问来看一下原始需求的目标用户是谁是全部付费会员核心目标是提升留存和付费转化。”“连续活跃天数——服务于这个目标加了一个计算因子改动量可控在原始需求范围内。通过。”“成长值进度条——服务于用户感知和升级动力属于提升体验的增强型功能。原始需求里没有但价值明确。有条件通过需要确认排期消化方式。”“积分会员体系打通——这个变更的本质是把两个独立的系统变成一个联动系统原始需求的目标是会员体系升级不是积分体系重构这个变更的服务对象和价值目标已经超出了原始需求范围。”他停顿了一下“我的建议是前两个变更先正常受理第三个变更放到下一期积分和会员体系的联动是一个独立的需求应该走完整的需求前置分析和评审流程——按我们建立的需求五问要求评估。这样第二期上线的时候积分联动就是一个有明确目标和量化价值的需求而不是一个’老板觉得效果会很好’的想法。”王磊听完沉默了一会儿。张栋梁在旁边补了一句“如果老板确实想要这个联动我可以和运营一起做一个独立的需求分析这样第二期做的时候我们也能用MoSCoW拆一下范围避免现在这种变更累积的情况再出现。”王磊点了点头“行前两个加进去先做第三个独立出来我先和老板那边沟通下看看是否可以放到下期做。”变更管理的三个原则从这件事之后陈钊和张栋梁一起定义了一套变更管理的基本原则。原则一每一次变更都要评估不能凭感觉放行。第一次变更连续活跃天数半天确实小陈钊没多想就答应了。这不算错——小变更快速响应是合理的但问题在于答应了之后没有记录也没有整体评估。小变更不怕多怕的是不知道累积了多大。从那以后陈钊要求张栋梁在需规文档里维护一个变更记录表——每次变更记录来源、内容、评估改动量、累计改动量当累计改动量超过排期缓冲的30%时触发一次整体排期重新评估。原则二变更决策回扣需求五问。这是需求五问框架在变更场景下的直接延伸每一次变更到来的时候不是直接评估技术改动多大而是先问为谁做 这个变更服务于原始需求的目标用户还是引入了新的用户群体为什么做 这个变更服务于原始需求的价值目标还是偏离到了新的目标做什么 这个变更在原始需求的边界内还是超出了范围不做什么 接受这个变更意味着要砍掉或推迟什么怎么做 技术改动量和风险如何如果一次变更在为谁做和为什么做上仍然服务于原始需求的目标大概率可以接受如果偏离了就应该独立提一个新的需求。积分和会员体系打通就是在为谁做和为什么做上偏离了原来的需求——原始需求的目标是会员体系升级而系统级联动本质上是一个新命题。原则三变更决策要透明不能只存在于技术负责人的脑子里。陈钊反思了第一次和第二次变更的沟通方式——他只和王磊私聊团队其他人只知道多了一个小点不知道多了多少、“为什么多”、“整体排期受不受影响”。从那以后他要求变更决策在团队内同步每周的站会上张栋梁通报本周所有变更记录和累计影响团队每个人都能看到缓冲还剩多少、“哪些变更已经接受了”。透明不是为了追责是为了让团队对项目的真实状态有共同的认知。如果只有管理者一个人知道项目在悄悄延期等延期真正来临的时候团队会措手不及。拥抱变化但不纵容随意周五陈钊在笔记本上写下了这一周的总结。拥抱变化这句话在行业里被说了太多遍以至于很多人把它当成了来什么做什么的借口。但真正的拥抱变化不是无条件接受所有变更而是给变更一个清晰的决策框架评估、校准、管理它然后决定接受还是拒绝。需求会变这是事实。产品经理发现遗漏运营有了新想法老板有了新灵感这些都会发生。但你作为技术负责人有责任让每一次变更都经过校准它到底服务于谁、服务于什么目标、付出什么代价、需要砍掉什么来腾出空间。变更不可怕。可怕的是变更在不知不觉中累积等你发现的时候项目已经面目全非。下期预告《向上汇报的时机与分寸》——需求评审、优先级、排期、方案、变更这些陈钊都有了一定的经验他还有一个弱项向上汇报。不是他不知道要汇报而是他不确定什么时候该说、说什么、说到什么程度。S2E5 完 | 约3100字//技术心路//