如何避免软件《需求文档》一被评审就被改的面目全非？

小编见过的程序员和产品经理之间产生的矛盾大多是因为一个叫“需求文档”的东西，有这么一种让人头疼的需求文档，产品经理将这样的文档转交给程序员的时候，程序员的内心一定是崩溃的，他一定会问若干个“如果”：如果发生A情况，该怎么处理；如果发生意外，产生了B情况，又该怎么处理。

产品经理收到反馈再来更新需求文档，你问，我改，再问，再改，等大家都疲惫了，需求文档也成熟了。最后谁都看不懂，一份文档束之高阁，没有任何价值。

需求文档中的“优先级”选项也是令程序员很头疼的，优先级分为高、中、低三个选项，大多数产品经理会说，高优先级必须上线，中低优先级也是需要做的。那还分什么优先级呢？或者说中低选做，这种模棱两可的感觉还不如抽象成做或者不做。当然，这需要产品经理提升能力，能够清晰地评估出一个版本能否涵盖这么多的内容。

程序员需要的是一份大家都认可的清晰的交互图，其关键位置需要有一些边界条件的说明。这份交互图不一定非要用专业的原型工具输出，一张草纸加铅笔描述清晰即可。

小编认为由产品经理和程序员一起讨论功能的关键路径，并一起确定每一个流程，然后简单地画出草稿，才是效率最高的方式，并且可以少开很多会议。若仅一个人想好了就发起评审，结果往往是需求被改得面目全非，不如大家在初期就一起讨论得出结论。

当然，程序员是很高傲的，产品经理没叫他参与讨论时，他会抱怨：“什么都不叫我，乱决策，现在一团糟，根本实现不了。”

产品经理叫他的时候，他又会说：“整天跟产品经理在一起讨论问题，技术上都没有长进，没有积累。”或者抱怨说：“白天跟产品经理讨论，只有晚上加班才能写点代码，筋疲力尽，还总被批评效率不高。”