产品经理对产品细节需要给到什么程度？才不会被开发骂？

产品经理对产品细节需要给到什么程度，才不会被开发骂？ 

背景：公司规模较小，分工不是很明确。由于无市场部，以前产品立项没有流程，为失败的产品付了很大的代价，故成立产品部，目前有两个人，亟待解决产品与市场脱节的问题。

起因：由于没有专门的交互设计和视觉设计，以前由开发自行发挥，后来因为用户体验实在太差，老板决定由产品部来完成这部分工作。

提问者：我理解的产品管理的工作重心在规划和立项。我的工作基本围绕项目任务书（目标市场、产品定位、可行性分析、目标成本和销售目标等）和产品需求包（需求描述、用户场景、优先级）这两个交付物。

遇到的问题：

用户注册

需求：支持手机号码注册

界面：给出了手机号码注册的界面

这个功能在立项评审时，以上信息已经足够。但进入开发阶段，就会遇到，验证码怎样获取、有效时间多长、失效后怎样、号码已注册怎么提示、密码长短组合有无限制、密码丢失后如何找回等等一系列问题。

对我们的产品来说，注册这个功能实在是微不足道。产品核心功能所遇到的类似的问题就更多了。

各项需求对应用户的操作错误、设备异常情况、极端情况以及逻辑细节，都是在立项和原型阶段没有考虑的。

研发在开发过程中会不断提出疑问，给出方案后要求改原型，提需求变更，甚至当开发进度失控时会以需求不明确为借口要求我们提交项目延期申请。

往往产品开发进入这个阶段时，我们已经投入到下一个产品的立项调研工作里了，面对这些问题实在不胜其烦，但又无法说服老板，老板认可这些不应该由开发人员去考虑，产品部应该在前期就将产品定义清楚。

这个问题从行业角度来说，如果是面对互联网行业，用一些User Case之类的重方法是起不到好作用的，行业变化这么快，这么多文字产品经理书写完毕，就已经耗费好几天了，更不要说思考的时间了。

这个问题从目的来说，满足不被开发骂。比起写需求有一个非常简单地做法，就是产品经理和开发交朋友，如果你们是很好地朋友，那么开发就算骂你，你也不会觉得很刺耳，反而这是高效的处理问题的机会。

这个问题从题目来说，其实提问的产品经理在某种程度上有一个完成任务的心态。这个是比较消极的，认为需求说清楚了，效果不好就是开发的问题了。

看提问人的背景应该属于从类似华为这样的成熟企业来到一个2B的企业服务行业，公司规模比较小，团队认为用敏捷，所以文档不重要，于是产生一些困惑。其实这里的关键是如何认识到这个角度：团队对需求的共识高于一切——这个角度才是真敏捷。

如果从这个角度来看，并不需要仔细考虑咱们的文档应该写到哪一步，写到哪些细节，而是应该把关注点放在开发团队是如何认识到这个需求要做到哪些点。

如果开发团队有经验，你文档不写，也能做到。如果开发团队欠缺经验，你文档写了，也写不全，做不到。如何有效达成共识是关键，文档其实传递信息的效率是很低的。

那这里有没有立杆见影的方法呢，答案是——有。

需求评审会由产品经理讲需求改为开发人员讲需求。

通常我们都是靠产品经理讲解需求，然后用投影仪逐一解释，但是这个过程中团队整体是PK心态，互相对抗的，尽量多说少做，而且很难达成共识。通常开发人员都没有时间提前看需求文档，更不要说理解了。

改成开发人员讲解需求后，你就会发现，面对白板。如果不能充分理解需求根本就是大脑一片空白，所以开发人员必须提前研究需求，不懂还需要找产品经理沟通，共识自然就通过会议达成了。