需求变更本身不是问题，把变更当成麻烦才是问题的开始。很多开发者一听到"能不能再加个功能"就本能地抵触，觉得甲方在占便宜。这种心态直接决定了谈判的姿态——你越是觉得吃亏，越容易在报价时含糊其辞，或者干脆咬牙免费做，最后既亏了工时，又在心里攒下委屈。真正专业的做法是把每一次变更看作一次新的商业要约：甲方有增量需求，你有增量成本，这只是一笔需要重新对齐的账，不涉及人情，更不涉及谁求谁。想清楚这一点，后面的谈法自然就从容了。
谈判的分量几乎全部来自前期。不要等到项目做到一半、改动已经发生时才开始谈加钱，那时候你没有任何筹码，因为沉没成本已经把对方套牢了，你也退无可退。真正的保护机制是签一份有明确范围界定的合同：列出交付清单、验收标准，以及一个关键的条款——"超出范围的需求按XX元/小时或按功能点另行评估报价"。这份文件的作用不是防备甲方，而是给双方一个客观标准，让变更从"你想不想加钱"的模糊争论，变成"这个需求在不在约定范围内"的清晰判断。白纸黑字比口才更有说服力，因为它把情绪挡在了门外。
当变更真正到来时，别急着回答"行"或"不行"，这两个字都容易让你被动。更稳妥的回应是把选择权交还对方，同时把代价摆上台面："这个功能可以做，需要额外X天和Y元，你要不要加?"这样一说，责任就回到了决策者身上。很多人吃亏就在于自作主张先把活干了，再不好意思开口要钱，结果是甲方理所当然地认为这本来就是该做的。商业世界里，不主动亮明代价的付出，往往会被解读为廉价的。你要让对方明白，每一个"可以"背后都有一个真实的成本数字，而是否承担这个成本，由他们决定。
报价环节最忌讳拍脑袋说一个数字。与其说"加这个要多加五千"，不如把拆解过程呈现出来：这个需求涉及几个模块、需要多少工时、会不会影响已有功能的稳定性、测试和后期维护的成本在哪里。甲方真正在意的常常不是那个最终数字，而是数字背后的合理性。当你把成本结构摊开，对方会觉得这笔钱花得清楚，甚至会因为你的专业而更信任你的判断。相反，一个拍脑袋报出的数字，哪怕不高，也容易引发"你是不是在宰我"的警惕。透明本身就是议价能力。
最终能不能谈成，取决于你平时积累的关系账户。如果你此前交付可靠、沟通顺畅，甲方对变更加钱的接受度会高得多，因为他们知道你是一个值得长期合作、不会中途撂担子的人。反之，如果你第一次合作就斤斤计较、毫无信任基础，任何报价都会被当作试探底线。所以加钱谈判从来不是临门一脚的技巧，而是整个合作质量的集中体现。把每次变更当作展示专业度的机会，而非单纯的多要钱，你会发现谈钱反而变得简单了——因为你卖的不是一段代码，而是让对方放心的能力。