title: FAQ-产品经理对产品细节需要给出到什么程度，才不会被开发骂？
desc: 我理解的产品管理的工作重心在规划和立项。工作基本围绕：项目任务书（目标市场产品定位可行性分析目标成本和销售目标等）产品需求包（需求描述用户场景优先级）这两个交付物。<br><br>因为是小公司，没有专门的交互设计和视觉设计，以前由开发自行发挥，后来因为用户体验实在太差，老板决定由产品部来完成这部分工作。<br><br>举个最简单的例子说明我遇到的问题：用户注册<br>需求：支持手机号码注册<br>界面：给出了手机号码注册的界面<br><br>这个功能在立项评审时，以上信息已经足够。但进入开发会遇到，验证码怎样获取有效时间多长失效后怎样号码已注册怎么提示密码长短组合有无限制密码丢失后如何找回，等等一系列问题。<br><br>对我们的产品来说，注册这个功能实在是微不足道。产品核心功能所遇到的类似的问题就更多了。<br>各项需求对应用户的操作错误设备异常情况极端情况以及逻辑细节，都是在立项和原型阶段没有考虑的。<br>研发在开发过程中会不断提出疑问，给出方案后要求改原型，提需求变更，甚至当开发进度失控时会以需求不明确为借口要求我们提交项目延期申请。<br><br>往往产品开发进入这个阶段时，我们已经投入到下一个产品的立项调研工作里了，面对这些问题实在不胜其烦，但又无法说服老板，老板认可这些不应该由开发人员去考虑，产品部应该在前期就将产品定义清楚。<br>请问各位产品的大神，这样的问题是如何解决的，功能细节的细化边界在哪里，有没有好的制度改善这种情况。<br><br>感谢回复！<br>1说下背景，公司规模较小，分工不是很明确，由于无市场部，以前产品立项没有流程，为失败的产品付了很大的代价，故成立产品部，目前有两个人。亟待解决产品与市场脱节的问题。<br>2说明下注册这个事，公司产品是工业品，客户不是终端用户，高层提出用注册来接触到终端用户，并非为权限管控，和产品本身功能无关。故用了微不足道。<br>3不清楚其他公司产品管理的模式，所以发问。上个东家规模较大，产品工作核心在回答“为什做这个产品”和“为什么这个产品能达到销售预期”。立项评审后交付任务书给项目经理，走IPD流程，系统分析师主导详细设计。<br>可能产品基线完善，未做过需求细化，仅参与节点评审，确保定义的功能都实现。产品发布评审通过后，从项目经理处接手进入生命周期管理。<br><br>我认为这个过程应该是有流程来规范和引导立项后从任务书到开发语言的转化过程，且有明确交付物和节点。<br>我的理解是将任务书与原型评审作为与开发的交接点。现在开发采用所谓的敏捷模式，没有详细设计这个阶段。原型毕竟不是最终产品，随着开发深入，细节的问题会越来越多，甚至有些功能无法实现到这个阶段才能识别。这个过程处于一个失控状态，这是我困惑的地方。
topic: 产品经理
content: 多谢大家点赞！目前在近 2400 人的关注者中，本答赞数已超 500，收藏数竟然已超 680！而且还被编辑推荐收录。这真是入乎以来头一遭啊 - 高兴之余，我也颇感意外，因为事先我确实没有料到会有这么多人理解认可用例技术的价值，纯属试着写写看的心态。你看 Use Case 话题的关注人数： Use Case - 问答社区 才区区不到 70 人，这点热度可以忽略不计吧。我一直主张用例应该是 SRSPRD 的核心内容，然而江湖上能读写 Use Case，把用
answerer_tags: 大叔级 OO 程序猿、软件架构狮，特级资深 Agile 2 敏捷开发教练