业务变更和技术变更的区别是：业务变更会改变项目相关方的利益，而技术变更不会。如果开发团队收到业务变更后，直接安排开发，软件将不断收到缺陷反馈。因为相关方的利益在他们不知情的情况下发生了变化。
最近就看到了一个伪技术变更。为了推广App，公司做了扫码下载功能。老用户生成一个二维码推荐给新用户。新用户扫码并下载软件后，老用户可以获得一些积分。需求变更是这样的：新用户扫码之后，增加一个手动输入老用户ID的步骤。如果ID有效，积分将根据ID分配给用户，而不是分配给生成二维码的用户。产品人员把需求标记为技术变更，开发团队接受了这个需求，直接安排开发。开发团队草率接受业务变更，是有大隐患的。
很明显这个变更修改了老用户的利益。假设老用户X生成了二维码并推广给新用户A。按照原有规则，积分将分配给老用户X。可如果新用户A扫码之后，输入了老用户Y的ID。按照新规则，积分会分配给老用户Y。如果老用户X不了解、不认可新规则，必然会投诉开发团队：我做了推广，为什么没有得到积分？
这就是伪技术变更的危害。在任何变化中，利益受损的一方必然出现反弹，业务变更也是这样。为了发展的需要，业务变更不可避免。但业务变更产生的反弹，应当由受益方，即业务部门来承担（或者至少是分摊）。可是如果业务变更伪装成技术变更，反弹的成本就被转移到技术部门来承担。业务部门会说：“你看，技术部又写bug了。”但其实这不是bug，是业务规则变了。
因此，无论是为了更好的开展开发工作，还是提高软件质量，开发团队都要对伪技术变更保持警惕。在收到变更时先想一想，哪些相关方的利益会受到影响，这些影响得到了各相关方的确认了吗？