先稳住，不要慌，先确定问题，是输出的不明确，没有进行前期的业务解读，还是开发没有看文档原型，没有理解业务，如果是自己的问题要检讨，不要甩锅。开发的问题侧重沟通后期预防类似的情况的应急处理，主要还是看沟通和情商了偏差出现在哪里，影响有多大，为什么会出现回滚需求，解决偏差。先聊清楚原因，要么是实现成本太高太费力，开发觉得不值得做，或者这一版来不及要么就是对需求理解有偏差，没有沟通到位，如果必须按照需求来不能有偏差，那其实就没办法测试通过，需要在当前版本上线前改掉。

因为产品化的需求基本上接近于标准化的东西，是需要多个客户场景进行验证的，而且需要在定制化的需求里进行共性的抽象和提炼，才能形成产品化的需求和设计思路。通常情况下，在市场开拓的一年内基本可以说是以定制化优先，当我们交付了多个项目，并且产品和开发人员都能够深入理解客户的场景要求后，我们才能从不同的客户场景中提炼出业务和管理的共性，形成标准化的业务方案和一些技术方案，进而再将定制化的系统进行重构优化，形成产品化的方案。产品化也可以融入到日常的产品设计中。我们在甲方或者乙方做产品的过程当中，产品化和定制化设计思路最大的不同就是：产品化的系统一定是能够进行多系统可共享的。比如说一个客户管理系统，A项目或业务用了，B项目或业务也可以用，大家可以共享，这也是今天谈得比较多的业务中台的概念。那多系统可共享的产品设计最核心的要求就是：系统要做到高内聚、低耦合，以及标准接口，所有的系统功能和外部系统都可以通过接口的方式与我们已经产品化的，比如说客户管理系统，能够进行快速的拆分和对接。客户管理系统不依赖于任何一个业务系统，这时候我们说客户管理系统就已经产品化了。

第一，换位思考。因为从技术的角度来说，我们希望我们的架构界限清晰，能够高效地迭代，同时在稳定性方面去做技术债务的解决。而从产品和运营的角度来说，他们一定是希望用户端的功能能够尽快上线，让用户感知到我们的产品在优化。第二，经常出来分享也是个很好的交流机会，能够学习其他讲师的经验。看到别人有更好的解决方案的时候，对你的业务也有帮助。我一般看到很不错的分享之后都会立刻拍照，或者会跟团队说：“你看别人是这样解决问题的，我们也可以参考一下。”另外，还能够认识很多朋友，有可能哪天遇到相同的困难，询问身边的朋友就能得到一个可以快速借鉴的解决方案，减少了很多踩坑的可能。