作为程序员，最想打死的应该就是产品了，他们可能会提出类似于根据手机壳更换手机主题的需求，也会一个需求改10遍然后用第一版。
作为程序员难道就任其宰割了么？
当然不是！裤裆着火----裆燃。
下面介绍几种尽量减少和产品打架的方法。
看策划案
万恶之源：需求。而需求，应该是有策划案的，如果没有，请让公司优化流程，或者换一家。
策划案就好比是施工队的蓝图，语言表达永远是有歧义的，而策划案就是为了减少歧义，并且留作证据，让运营和后来的同事有迹可循。
而当你拿到策划案的时候，首先需要了解：
1. 产品有多在乎这个功能
如果只是产品试错的，可以简陋点，如果是以后可能无限扩展的，就多想一些可能性，减少重构。
比如房间PK功能，可能就是运营看到同类产品，然后想试试效果，我们设计的时候只需要保证稳，而不用保证扩展性，毕竟房间PK需要的主播量是很多的，大概率效果不会很好。手动滑稽。
比如房间红包功能，是促进用户消费的，应该是会长期使用，而且不能保证有多少人抢，又是和钱相关，所以要多考虑并发设计，并且提高可承载的人数。但是发红包不会有什么扩展了，最多就是换换红包皮肤，所以扩展的可能性也不大。
再比如贵族功能，首先是跟钱相关，而且各种权限花里胡哨的，肯定会随着业务扩展而扩展，所以最好设计成独立系统，减少耦合，以后扩展功能直接接入这个系统就好了。
2. 功能背后的故事。
每个功能都有一个提出点，考虑产品提出的原由，也叫“原始需求”，再去分析策划案，可能会有一些更优的方案。
比如产品希望有个推荐系统，然后设计了一堆算法，比如根据最近多少分钟的某个时间计算权重，然后加入衰减周期等等。你就可以优化这种复杂的算法，以一种你好写算法去完成他们的需求。
有人可能会觉得这不是我该考虑的事情啊，怎么设计不是产品说了算么？错！产品只是考虑我想要什么，他们不会技术，所以他们并不知道怎么是简单，怎么是复杂，他们只能想到他们所能想到的。
你永远无法想到你不知道的事情。
这个时候就需要《沟通的艺术》，你既不能只是一味图方便，也不能完全写很坑的算法，甚至有些算法根本就是没有什么效果的。这就需要你充分了解功能背后的故事，去做工作了。
需求改动
程序最烦的往往不是这个功能有多复杂，而是这个功能一直改来改去。
首先需要完善的制度就是估时，案子经过商讨、修改、定稿确定后，程序应该对其进行评估，包括测试，也应该评估，然后给出预计上线时间。开发过程再有改动，则需要添加时间。
但是这个对自己运营产品的公司有效，对外包是无效的，甲方就说我需要改，最后还是只有加班改，怎么办？
留好备份。
永远不要相信产品和甲方的话，永远，永远。
不管他们怎么说，这个功能不会改了，以后就这样了，和上一次的功能差不多等等，都不要信！！
改动的时候自己提交好git，打好标签，如果有必要，甚至可以多个分支或目录，总之，让自己回滚的成本变低。
心态
也许你尝试过了上面所有的方法，由于制度问题、或者有的人就是坑，而你又暂时无法脱身（提桶）。
试着想想：
- 他能不能怼，比如是老板的好盆友，是运营的好帮手。
- 怼了我能不能不改，如果改动已成事实，不如接收。（生活就想qj，如果实在无法避免，就躺平吧）
- 我打不打得过他，怼人一时爽，被打的结果就不可知了。
如果以上的你都想好了，连提桶、医院都已经想好了，最后想想：打架斗殴是什么罪名，建议看看罗翔老师的视频。
其实
大家都是打工者，何必呢。
别怂，别刚
在人与人的交往中，要巧妙地利用别人的弱点。
如果你是软柿子，那么谁都可能把麻烦事退给你。如果你是不点就炸，那么谁也不敢把团队交给你。
所以，该出手时就出手，但是尽量做到以理服人，而不是通过吵架打架。
好了，对于和产品打交道的经验就介绍到这里，后面我会持续出几篇关于项目实战的文章，分享如何设计好一个个功能，如何规避产品中的坑。