同学们好，我是老孙。
“这个功能顺手加一下，应该不费什么事吧？”
上班的同学，多半听过类似的话。做系统的人听到的是加功能，做行政的人听到的是活动多加一个环节，做报表的人听到的是再补几组数据。事情要增加，原来的截止时间却没动。
你答应得痛快，后面可能要自己加班；你直接说不行，对方又觉得你不配合。读高项教材时看到“变更请求”“范围基准”“整体变更控制”，如果只是记住名字，很难想到它们就在处理这种局面。
上一篇谈了备考路线。今天先拿一件具体的小事练练：当别人说“加一点”时，你该问什么、查什么，又该让谁来决定。没有软件项目经验也能读，下面涉及的技术工作，我会逐项解释。
一、先把这件事说完整
以下是虚构教学案例，沿用本系列的“智慧邻里2.0”项目，不代表老孙或学员的真实经历。
美好家园集团准备在清华园社区上线一套管理系统。本期原来约定，先把住户资料和物业缴费两个部分做好。李经理负责组织项目，王主任代表社区提出使用要求，小吴负责开发，方姐负责业务核对。
系统已经按约定范围完成大部分工作，正准备测试和上线。这时周总说：“居民报修一直靠打电话，能不能顺手加个手机报修？上线时间不要变。”
手机上填个问题、传张照片，看起来确实简单。但报修提交后谁接单？维修人员怎么知道有新任务？修完由谁确认？住户能不能查进度？如果只做了一个提交页面，后面无人处理，居民可能比以前更着急。
李经理此时要做的第一件事，是把周总的诉求问清楚。他可以说：“这个方向有价值，我先和社区确认本期要做到哪一步，再把对上线时间和现有工作的影响列出来，按项目约定请有权限的人决定。”
这句话没有承诺一定能按原日期完成，也没有把需求挡回去。它给出了下一步，而且下一步确实能做。
这里有个重要前提：本例已经有了批准的范围、进度和费用安排。项目还在早期讨论时，大家提出想法、逐步细化需求，不必把每一句讨论都当成正式变更。等基准确定后，再调整约定，就要按规定处理。
二、先问“要解决什么”，别急着问“几天能做完”
如果李经理只把“加手机报修”转给小吴，小吴很可能先按自己的理解做。等到交付时，王主任说还要派单，方姐说还要统计，周总说最好能看维修满意度。每个人都觉得自己补充的内容本来就应该有。
所以，先把需求从一句话展开成几项可核对的内容。
第一，谁在什么场景下使用。是住户自己提交，还是社区工作人员代录？老人没有智能手机时怎么办？同一个家庭能不能由家属提交？这些问题决定要照顾哪些使用方式。
第二，从哪里开始，到哪里结束。是只接收报修，还是连派单、接单、处理、完工确认都包括？只写“支持手机报修”，不能判断完成了没有。把起点和终点说清楚，大家才知道本期究竟承诺了什么。
第三，怎样判断合格。比如，住户提交以后能得到受理提示，社区工作人员能查到记录，指定人员能收到待办，处理结果能被查询。这里只举业务检查方向，具体标准要和使用方确认，不能由项目组凭空替对方决定。
第四，哪些东西本期不做。自动推荐维修人员、维修费用在线支付、满意度排行，都可能有用，但未必应当一起塞进第一次上线。暂不包含的内容写明白，可以减少“我以为已经包括”的争执。
| 对方原来的话 | 还要追问什么 |
|---|---|
| 手机上能报修就行 | 谁来报、提交什么、提交后交给谁 |
| 最好能看进度 | 谁能看，显示哪些处理状态 |
| 以后统计也方便 | 统计什么，给谁用，本期是否必需 |
| 尽量别影响上线 | 哪个日期必须守住，哪些内容允许分期 |
这一步对应教材里的需求管理。需求不是把别人说的话原样复制下来就完成了，还要分析、澄清，形成可以确认和跟踪的记录。
同学们如果不在技术岗位，也可以换成自己熟悉的事。领导说“年会再加一个抽奖”，你会先问奖品、人数、抽奖方式和时间，不能只把“抽奖”两个字发给主持人。事情越具体，后面越容易商量。
三、一个功能，为什么会牵动好几项工作
需求说清楚后，再谈影响。不要只问小吴“多写一个页面要多久”。开发只是其中一项工作，真正交付给社区使用，还涉及业务确认、测试、操作说明和人员安排。
范围：这次到底多交什么
项目范围可以先理解为，为了交付约定成果，需要完成哪些工作。手机报修不只是一个按钮，还可能增加提交页面、处理记录、派单规则和结果查询。
把新增工作列出来以后，再与原来约定比较。有些要求确实是新增，有些可能原本就在批准范围内，只是之前没做完。后一种情况不能随手包装成“客户又加需求”，把本该完成的工作推给对方。
进度：多出来的工作挤到哪里
如果小吴正在修复缴费功能的问题，临时让他去做报修，就会占用同一份时间。测试人员也不可能一边验证缴费，一边无限增加新的测试任务。
有人说“再加一个人就快了”。但新同事要了解系统，原成员要解释需求，还可能涉及交接和协作。增加人手是否有效，要看任务能不能拆开、资源何时可用，不能把人数和速度简单画等号。
成本：谁投入，谁承担
同事加班、借调人员、采购短信服务，都可能带来成本。有些没有立刻新增付款，但占用了其他工作的时间，也要评估资源影响。不能因为员工工资照发，就认为新增工作毫无代价。
如果合同约定了交付内容和费用，调整还可能涉及合同安排。项目组要识别需要谁参与处理，不能认为领导一句“先做”，就已经完成所有商务手续。
质量和风险：做出来以后能不能放心用
报修记录涉及住户和房屋信息，谁能查看、谁能修改，都要按实际业务和安全要求设计。上线前还需要检查提交失败、重复报修、无人接单等情况，而不是只演示一次“点一下成功了”。
假如为了赶日期，把原来的缴费测试和新增报修测试都压缩，风险会一起增加。需求本身可能有价值，仓促实施的方式却可能给项目添麻烦。
这些就是整体评估的意思。不是把几个管理名词写在表格里凑齐，而是顺着新增工作，查清它实际碰到了哪些人、哪些安排和哪些约定。
四、谁来拍板，不能只看谁说话声音大
教材第八章“实施整体变更控制”强调，变更需要综合评审，并对处理结果进行沟通。具体谁有权限，要看项目管理计划或组织程序中的约定，不能背成“所有变更必须由同一个委员会批准”。
有的项目把一定范围内的调整授权给项目经理，超出权限的再提交指定责任人；必要时，由变更控制委员会开展评审。涉及合同的，还要遵循合同约定及相应手续。职务高低和某次变更的审批权限，不是可以直接替换的两个概念。
李经理要做的是组织大家把依据准备好。需求提出人说明业务价值，开发和测试人员提供工作量与依赖分析，业务方确认轻重缓急，再由有权限的人作出处置。
“评审”也不等于每次都开一场长会。组织可以按变更的重要程度、影响范围和既定流程安排处理方式。小调整不必故意办得很复杂，影响基准的变更也不能只在聊天里点个赞就当手续齐全。
回到本例，至少可以比较三种方案。
方案一，按完整要求增加报修功能，同时调整上线安排及必要资源。它照顾了较完整的业务需求，但原来的日期和投入需要重新协调，不能只写“同意新增”却不说明代价。
方案二，本次守住原定交付，报修放到后续版本。它减少了当前上线的不确定性，但要让提出人知道何时再评估、由谁跟进。不能口头说“下次再做”，转头就把需求丢了。
方案三，经业务方确认后，本次只增加边界清楚的最小功能，其余分期。如果提交后仍依靠人工派单，也应说明人工工作由谁负责、能否承接。少做一些页面，不代表整条服务链就自动有人接住。
哪种方案好，取决于业务价值、约束和实际能力。文章不能替虚构项目编一个“新增也完成、成本也没加、还提前上线”的漂亮结局。更值得练习的是，把选择和代价摆在一起，让决策人看得懂。
五、批准以后，还剩半件事
同学们容易把注意力放在“批不批”，觉得批完就结束了。但批准一项变更，并不意味着负责开发的人已经知道新要求，也不意味着测试人员手里的清单已经更新。
假设最终同意分期上线，李经理还要明确本期交付边界、后续处理安排和责任人，更新受影响的计划或文件。如果基准需要调整，要按规定维护批准后的版本，保留原有记录，不能直接改掉旧文件，弄得大家说不清何时改过什么。
开发人员要拿到一致的需求，测试人员要知道验什么，社区工作人员要知道如何接收和处理报修，提出需求的人也要知道哪些内容暂未纳入。各自拿着不同版本开工，审批再齐全也会出问题。
还有一种情况要分清：系统不能保存已经确认要保存的报修记录，可能是在修复缺陷；原来没有约定在线支付，现在希望增加支付，则可能是在扩展功能。两者都要按项目规定处理，却不能混成一个笼统的“优化”。先查原需求和验收标准，才能判断发生了什么。对照依据比争论谁的记忆更准确，也能避免把缺陷修复当成新增收费项目。
变更日志可以理解为记录变更及其处理状态的台账。提出了、正在评估、已经批准、被否决、推迟处理，这些状态不能混着写。获批后的实施和验证情况，也要按项目安排跟踪。会议上同意了，不等于功能已经做好。
如果决定不在本次实施，也要记录理由并告知相关人员。否决不等于提出人不懂业务，推迟也不等于永久不做。把理由讲明白，往往比一句“流程不允许”更能减少对立。
这一套用到日常工作，可以很轻。组织一次活动，确认新增事项以后，把任务表、预算表和当天流程同步改好；家庭装修确定增加插座以后，核清位置、费用和施工安排，再按约定确认。记录的形式可以不同，约定不能只存在于某一个人的脑子里。
六、把场景换成一道自编题
下面是自编练习，不是历年真题，也不据此推断未来考试的题型或分值。
题目：项目已经建立批准的范围和进度基准。上线前，业务负责人要求增加手机报修功能，并表示上线日期不能改变。项目经理没有澄清具体要求，没有组织影响分析，也未按约定提交审批，就让开发人员实施，要求测试人员自行压缩测试时间。请指出主要问题，并说明较合适的处理思路。
先别急着向下看。你可以用几句话回答：哪一个动作有问题，为什么有问题，应该怎样处理。暂时不要求背完整过程定义。
参考思路：新增要求没有澄清，交付和验收边界不清；未经整体影响分析，无法说明新增工作对进度、成本、资源和风险的影响；未按既定权限与流程处理变更，就直接安排实施；测试时间被随意压缩，可能影响质量，也没有相应评估和安排。
较合适的做法，是先记录并澄清需求，对照现有范围确认变化，组织相关人员评估影响和可选方案，按项目约定由有权限的人决定。获批后更新受影响的计划及文件，向相关人员沟通，组织实施并验证结果；未获批准的，不应擅自按新范围开工。
回答里最有用的，是把动作落到题面上。“加强管理、提高认识、重视沟通”可以放进很多题，却没有说明手机报修到底该怎么处理。写出“明确是否包含派单和完工确认”，别人就知道你看懂了本题的缺口。
也别把流程背成无条件的机械顺序。如果题面给了应急处置规则或特定授权，就要连同这些条件一起分析。本题没有给，不能自行编出紧急授权替未经评估的实施找理由。
七、今天读完，留下什么
很多同学来学高项，首先是为了取得资格、争取职称方面的机会，并不打算转行做软件开发。这个出发点很实际。白天工作，晚上再学一堆陌生词，确实不轻松。
但你不必等到成为技术专家，才开始理解项目管理。你知道一件事由谁做、做到什么程度、什么时候完成，也知道中途加活应当重新商量，就已经有了理解这些知识的入口。技术细节需要逐步补，组织工作的经验也能帮你往下学。
今天留一个小练习：找一件自己经历过的“临时加活”，在手机备忘录里写清原来约定做什么、后来加了什么、影响了谁、最后由谁决定。再补一句：如果重新处理，你最想提前问清哪个问题？不涉及真实单位的保密信息，不需要编成论文项目，更不用急着凑成长篇。
做完后再回看“范围、进度、成本、质量、相关方”这几个词，试着说出它们在这件事里各指什么。能讲出具体对象，比反复看一段定义更能检验自己是否理解。
下一篇继续讲云计算，分清服务类型、关键技术与发展趋势。今天先记住遇到新增要求时的第一步：把事情问清楚，把影响查明白，再按约定作决定。老孙保持日更，明天见。
#高项 #信息系统项目管理师 #软考 #项目管理 #变更管理 #高项备考
