我：对了，那个，有个地方可能要改一下...
工程师：你看着我的眼睛！
我：...
我：我有一个好消息和一个坏消息，你想先听哪个？
工程师：我不听我不听我不听
我：...
我：诶，跟你商量一下，有个地方换个方式话，以后你维护起来会不会更简单...
工程师：噢？站起来说。
上面是与我司工程师の日常，当然稍有夸张，不要在意这些细节。我们来说正题。
真实情况下，要是新入行的研发盆友，遇上刚毕业的小白PM，不会那么琴瑟和鸣，更多是一场场撕X大战。改需求，已经成为一个老梗，（PM）常常被大家吐槽，资深（被虐太多的）工程师对改需求早已见怪不怪。但哪怕是做了几年下来，脸皮已经厚可敌国的我，遇到需求要改，也常常是如履薄冰。
今天先不说怎么避免改需求，既然已经要改了，怎么才能优雅地改，尤其对产品经理同学来说，这个「姿势」很重要。
1.改设计
设计是最容易发生频繁改动的地方，尤其对于产品架构形态还不稳定的产品，不停的尝试最佳效果方案，或因各方「反馈」吐槽，顶不住压力，或因老板喜好、大手一挥，就改改改了，因为设计是「看起来」修改成本最低的地方。
千万不要学支付宝家一个版本一个大改，整个交互框架重构，每次都要重新找半天，都不能让我们愉快的花钱了！对成熟产品来说，框架重构，简直是莫大的挑战，往往还是一个「灾难」，君不见豆瓣一个改版，激起民愤千丈，最后还得妥协改回去。要优雅的改设计，建议尽量不要动框架，动作太大，姿势会难看。
在不影响核心需求满足路径的情况下，其他分支页面可以改，要与设计师、工程师充分沟通修改目的，让大家清晰知道，当前是处于试验期，所有方案都可算作「临时方案」，心理上做好随时可能调整的准备。这样，即使反复修改，至少小伙伴是已经有底的，在准备方案时自然会提前考虑一些扩展灵活性。最好在改版前，多出一两套设计方案，多论证几轮，筛选出明显不靠谱或改动成本巨大的方案，即使要改，心里也要有数，是冲着验证哪一个方面去的。
2.改逻辑
这其实是产品中的「大忌」，核心功能逻辑确定以后，除非业务方向调整，一般情况下是不作变动的。如果是在基础逻辑上，去补充、完善或调整，这种层面的修改，尽量多思考全面，不遗漏场景，不造成冲突影响。
常见的一种bad case，因为修改一处逻辑，引发两个点冲突，进而引入新的一条逻辑来解决冲突，这种补丁套补丁的方式，越往后，积弊难返，过一段时间则要重构大修。伤筋动骨，还背着包袱，改出来的东西可能龇牙咧嘴，说好的优雅呢？
变化是常态，尤其创业产品。但盲目的修改，没有客观确凿的验证充分情况下，就贸然推翻过去的需求话，可能错掉正确的方向不说，反复折腾消磨了团队人员激情，最后对「各种修改」一个麻木状态去应对，不再主动思考去帮助完善修改方案，这才是产品最大的损失。
题图来自艺术云图
