我所见过的程序员和产品经理之间产生矛盾大多是因为一个叫「需求文档」的家伙。
有一种恶心的需求文档，我曾经见过，甚至再见到会觉得更恶心，请看下图：
这张图应该会交给交互射鸡湿，交互看着这么长的文字，应该是崩溃的，画出交互图。交给程序员的时候，程序员看着这样的需求描述再来生产的时候，就会问若干个「如果」问题，如果×××情况下，该怎么办呢？产品经理再来更新需求文档，又问，又改，再问，再改，大家都疲惫了，需求文档也成熟了，最后谁都看不懂，一份文档束之高阁，没有任何价值。
请产品经理不要再浪费时间生产这样的文档了，程序员其实根本不需要这份文字式的需求告白书，程序员喜欢「看图」，这种文字式的文档应该是产品同学脑中的思路，而不应该直接把思路描述成文字交出来。
程序员需要的是一份清晰的交互图，这份交互图上在关键位置有一些边界条件的说明，这份交互图不一定非要用什么visio或者乱七八糟的工具输出，一张草纸加铅笔描述清晰即可，但是要还原出需求所描述的所有元素，虽然没有UI设计，但是程序员就可以开始开发demo了。
由产品、交互和程序员一起讨论出feature的关键路径，并大家一起脑补好每一个流程，然后简单的画出草稿，我认为是效率最高的方式，并且可以减少很多会议，凡是一个人说想好了，发起评审，基本最后都被改的面目全非，还不如初期就大家一起得出结论。
当然程序员是很「贱」的，你没叫他一起参与讨论的时候，他会抱怨说：“TMD，什么都不叫我，乱决策，现在乱的一坨屎，根本跑不通”，你叫他的时候，他又会说：“整天跟产品在一起讨论问题，技术上都没有长进，没有积累，或者又抱怨说，唉，每天白天跟产品讨论，只有晚上加班才能写点代码，累的像条狗，还总被人家说效率不高”。
程序员大多认为自己有些“武功”，跟不同的程序员交流要用不同的办法，例如多请他吃饭或按摩。
所谓能力越大，责任越大，明白的程序员早就想明白了，他每天的工作不是给他的老大干活，也不是给他的老板干活，每天其实都是在给自己干，无论在哪里干，都当是创业。
再说下需求文档中的「优先级」这个选项，也是令程序员很头疼的，优先级分为高、中、低三个选项，大多数产品经理会说，高的必须上线，中低优先级也是需要做的，那还分什么优先级呢？或者说中低选作，这种模棱两可的感觉不如抽象成，做或者不做，当然需要产品经理能力的提升，清晰评估出一个版本能否涵盖这么多的事情。
