需求变化对于程序员来说是一个可怕的噩梦。

不知道大家是否听闻过程序员自嘲的话语：“扫码改需求！” 看似很平常的一句话，却透露出程序员内心对需求改变的抗拒。在软件工程里，一个项目的前期阶段，需求调研是一个非常重要的步骤，产品经理调研好需求之后，确定大致的软件功能目标，后续程序员会对着这个目标，去尽力实现，这是一个理想的情况。但实际情况是，前期确定好需求之后，程序员心里知道了这个软件大概要怎么做，在项目进展途中，突然发现此需求走不通，或不符合用户习惯，或不符合公司的规模，需要重新设计某个模块，甚至全部推翻重来，这样一来，前期辛辛苦苦耗费时间写下的代码，突然成了一堆废功能。程序员心里瞬间有种努力白费了的感觉，所以，一旦产品经理变更需求，大多数情况下，整体情况会遭到程序员们的怨言，特别是变化了一两次后，修改功能代码之后，可能又会反反复复地变化其它方面的需求，从而陷入了一个需求变-改代码-需求变-改代码的循环当中。

那么，需求反复变化，究竟是谁的责任呢？大多数程序员，会把矛头指向需求调研的主要负责人——产品经理。他们认为，是因为产品经理前期需求调研的不完整，或欠考虑，造成了后续反复变更的情况。我个人认为，问题其实并不是由一个角色而引起的，原因可能在多个角色身上。首先，产品经理对于需求调研得不全面，确实是需求反复变化的因素之一。某些毫无技术常识的产品经理，在调研需求时，总觉得各个功能模块都能实现，同时考虑用户体验感不周到，这样调研出来的成果，在后期修改的可能性大大增加！但其实，还有一个重要的原因在于技术人员身上。在产品经理调研完需求后，会和技术人员研讨方案可行性，之后，确定了这个可行性之后，技术人员们才会去分工开始编码实现。技术人员队伍中队员水平参差不齐，在研讨需求方案可行性时，不能够很准确地指出产品经理初版需求的一些问题，所以，前期开会研讨需求时，技术人员觉得每个需求都可以毫无问题轻松实现，到实际编码的时候，却感觉困难重重，最后，又返回责怪产品经理的需求调研不完善，这样的情况也屡见不鲜。

所以，要保障项目的正常进展，需求产品经理要认真做好需求的调研，与各个业务部门搜集需求后，整理自己的需求构想，同时积极地与技术人员沟通需求的实现难度，可行性，安全性等问题，技术人员针对需求，给出自己从技术角度出发的建议，只有各个部门相互联系起来，认真对待，才能最高效地开展工作，达成项目目标！