需求奇葩不可怕，可怕的是变幻无常
web前端教程
用大白话，来讲编程
即便后来该公司出来辟谣说事情的起因并非如此。 但码农们早已经不在乎事件背后的真实原因，大家只想借此事来宣泄自己长期以来对产品经理那些不靠谱需求的不满和烦恼。
身为程序员，接需求写代码开发系统是我们的本职工作。相比起奇葩的需求，还有更让我们头疼的是：需求变幻无常。
明明上午说好了这样做的需求，到了下午又要改成那样了。这样写好的代码又要修改或是重写了。 这种情况在项目的开发阶段程序员还勉强可以忍受，但项目到了测试阶段甚至是上线阶段的时候，产品还会提出功能变更的要求，并且要求加班加点改好，如期上线，估计程序员杀人的心都有了。
要知道，程序员愤怒的当然不是加班，加班对程序员来说几乎是加班便饭，小事一桩。令人愤怒的是需求的变幻无常，是提需求者对自己工作的不严谨，不认真。
但作为程序员，抱怨归抱怨，无奈归无奈，与其跟他们撕逼浪费时间，倒不如想办法解决问题。与其指望别人反思，不如自己先反思寻求应对办法。
我发现身边的程序员一般都是“talk is cheap,show me the code”的工作模式，不愿意说太多，喜欢用代码来证明自己的价值，我刚入行的时候也是这样，总是希望用最短的工期来完成开发任务，来证明自己的开发能力。产品一旦提出修改，往往马上会按要求去改代码。现在变成“老油条”了，发现这样的做法并不可取。
如果跟你共事的PM有过反复改需求的“黑历史”的话，那么即使PM要求的时间再赶，你还是不要急于敲代码为好。 因为PM提出的修改意见不一定是想得周全的。
在现实中，程序员刚刚按产品需求写好代码，过一会产品又提出要改需求，这种情况太常见了。
因此，建议当产品提出需求变更以后，要先和其沟通，看看是否真的需要变更，如果真的需要变更，则要和产品交流一下变更后可能出现的各种情况，让产品了解变更需求所需的成本以及有可能出现的种种情况（俗称擦屁股）。
此时可以建议产品再想一想，再看一看，还有什么要改动的地方。等到产品实在提不出新要求了，双方各方面都达成一致了，再考虑动手敲代码。
当然，也不要一味地去反驳产品经理的需求，不是所有困难的需求都是奇葩，我们也可以静下心来，真正去分析和解决这些问题。你不但能提升自己的技术水平，还可以了解到需求背后的动机商业价值。 增长自己关于产品，商业领域的见识。说不定还可以发现自己新的兴趣点，将来还可以顺利地转型，给自己的职业道路更多的选择，何乐而不为！
与其高调撕逼，不如先坐下来谈谈可好？
热门文章
原创教程：
附加习题：
行业困惑：
职业规划：
新手求职：
职场心得：
职场感悟：
新手学习：
职场感悟：
学习困惑：
职场焦虑：
感到迷茫：
薪资待遇：
培训出身：
培训费用：
培训简历：
搞笑黑话：
职业自由：
职场形象：
合作推广分割线