本文中主要阐述的问题包括：
1、是不是只要没有技术上的实现问题，开发者就不应该对产品经理提出质疑？
2、需求文档、功能文档、最新而最全的原型设计文档，这些要求过时了吗？
3、产品经理进阶建议。
软件工程领域，本着分工合作高效进行的管理方式，每个人只要做好自己的分内事就行。当产品经理召集开发人员进行各种评审会的时候，其实是想让开发人员好好分析下，会不会出现逻辑问题。至于在产品设计上，开发还是比较人微言轻的。产品负责将这次的版本迭代做出来，让功能能够覆盖相关的需求，让开发人员确认过没有逻辑问题的情况下就可以进行到开发阶段了。如果开发人员产品设计上有过多的啰嗦，产品就会问你“是否有实现逻辑的问题？如果没有的话，就按这样设计的做就行了。”
关于这种情况，在软件实施管理的知识来说，是正确的。乔布斯也说过：
大致的意思就是，“你必须从用户体验开始，然后用技术实现它们。而不是反过来先去考虑技术。”
但是，如果一位产品经理代表的并不是用户体验（只是自己的主张），而拿这句话来搪塞勤劳的开发人员，那真的很让人烦恼。
首先，在现在的软件工程行业，开发人员为了能够更好的面向对象思考问题，也会面向对象的组件化开发。举一个简单的例子，如果一个app项目中有好几处可以提供给用户选取时间的功能，因为考虑到现有的3处地方都是一样的，为了以后的组件化开发，一个负责的开发人员会把这个“选取时间”的控件封装好，以便下一次直接使用。可是糟糕的是，下一次的版本迭代中也有一个地方需要提供时间选择功能，但是产品将这个时间选择界面的样式改变了，以前其他地方用到的时间选择样式依然按以前的来。对于这种情况，开发人员真的是好难过。但是，开发者要拥抱改变。这无可厚非，但是请说出这次为什么就要改变样式？以前的样式不符合吗？。。。“不好意思，这个不是你们开发考虑的问题，你只需要告诉我能不能做出来就好了。设计上的问题，不用你们操心。”产品会这样告诉你。
类似的情况还有：当开发人员指出产品的设计漏洞时，产品会以一种“战略性的鄙视”告诉你，“你所说的我们早都考虑过了，但是这一次的版本迭代我们先这样做～”唉，真是厉害。
上面说了这么多，我只是想替勤劳的开发人员说句公道话。首先请理解软件工程行业的组件化思维，组件化思维不仅是开发要做的事情，产品、UI、测试等人员都是需要进修的一门课。然后，在开发人员把常用控件组件化好以后（按道理来说，应该由产品提出哪些控件需要组件化，尽早的统一好样式和功能让开发封装好），产品却还要进行改动。其实，开发人员不是不愿意改动，而是，他们只是想确定下你是不是认真的？是否真的有这方面的需求？是否真的需要改进？那之前的样式是否需要统一起来，还是区别处理？这些问题，开发只是想确定好产品经理是认真思考过的，而不是“看产品经理当时的心情”。
其实，如果开发与产品经理之间的关系到了这种不信任的地步，这样下去就会出现两者情况：第一种是，开发和产品经理不和气，经常会为了产品的设计发生争执。其实这种情况，至少说明开发还是比较负责的态度，如果真是第二种情况，那就没希望了。第二种情况就是，以后产品怎么设计，开发就怎么做，产品本身的事不再关心。产品想怎么改都行，反正只要有时间，没有什么是开发不出来的（软件行业，又不是研究行业），最终受到损失的是公司。
上面说了这么多，包括有时发生的产品经理和开发人员发生暴力事件。都说明了一点，现在大部分的软件工程行业，或者直接说是互联网公司吧，产品经理的话语权没有放置在合适的层次。当然什么事情都有两面性，当这位产品经理的能力得到大家的一致认可，并且通过了各方面的考验，那么赋予这位产品经理更好的执行权是可以的。否则，还是乖乖的按照正常流程执行会比较好。所谓的正常流程就是说，学习西方的管理方式，制度为上，而不是人治。
敏捷开发提倡口头交流这种高效方式，但是并不是说就从此以后就不需要文档了。所以，需求文档、功能文档、完整的原型设计文档是不可少的。
