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

标签： faq 产品经理 产品 | 发表时间：2016-07-25 21:30 | 作者：张恂老师

出处：http://www.zhihu.com

产品经理对产品细节需要给出到什么程度？

这题其实早有成熟的答案：

产品需求往往写到 Use Case（用例）的程度，才刚刚好。

Wikipedia:Use case

用例最早至少是在 1998 年随着 Rational Rose、RequisitePro 和 RUP 5.0 传入中国的，那时 Rational 公司（2003 年被 IBM 全资收购）还未正式进入中国，而国内一些领先的企业、大学和研究所（先驱者）已经在开始学习使用 UML 与 Use Case 了。

Use Case

举个最简单的例子说明我遇到的问题：用户注册
需求：支持手机号码注册
界面：给出了手机号码注册的界面

这个功能在立项评审时，以上信息已经足够。

这点需求描述，软件工程、需求工程的专业术语叫“特性”（Features），通常是用特性名称加上一两句话或一小段文字来描述。

特性的优点是简明扼要，缺点是需求描述的精度明显不够，常常无法有效地指导复杂产品的实际开发，因为还存在许多模糊的细节和问题需要后续澄清。

所以，题主问到：

但进入开发会遇到，验证码怎样获取、有效时间多长、失效后怎样、号码已注册怎么提示、密码长短组合有无限制、密码丢失后如何找回，等等一系列问题。

这些内容用 Use Case 文本描述，基本可以做到全覆盖。

先举一个简单的注册用例例子（以后补详）：

   用例名称：注册会员

触发事件：用户选择注册

基本流：
1. 系统显示注册界面。
...
5. 用户选择用手机号注册，并输入手机号；系统即时校验该手机号是否有效。
6. 用户选择让系统生成并发送手机验证码。
7. 系统为该用户随机生成一个 6 位的验证码，发送含该码的提示短信到用户手机号，
   同时提示用户在 60 秒内在验证码校验框中输入该码进行校验。
8. 用户输入验证码，系统即时校验该验证码的有效性。
...
12. 用户提交注册信息。
13. 系统检验用户的注册信息。
...

扩展流：

5a. 手机号已注册
...
8a. 手机验证码错误
...
8b. 手机验证码超时
...

其他用例模版：

OpenUP: Artifact: Use Case

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

Use Case 的分析与设计是交互设计的一项核心技术，UX 太差显然与你们没有专业的产品需求分析师有关。

Wikipedia: User-centered design#Use Case

没有专业的需求分析师与成熟的软件（产品）开发过程，出现这些状况是极其正常的：

对我们的产品来说，注册这个功能实在是微不足道。产品核心功能所遇到的类似的问题就更多了。
各项需求对应用户的操作错误、设备异常情况、极端情况以及逻辑细节，都是在立项和原型阶段没有考虑的。
研发在开发过程中会不断提出疑问，给出方案后要求改原型，提需求变更，甚至当开发进度失控时会以需求不明确为借口要求我们提交项目延期申请。

根本的原因，在于你们的产品需求文档（PRD）、需求模型（RM，Requirement Model）质量差（精准度不够）。

像“操作错误、设备异常情况、极端情况以及逻辑细节”之类如何处理的需求内容，这么多年来我所知道的 最佳方式就是用 Use Case 结合非功能需求（如 FURPS+）来分析、组织与描述，包括用例的基本流与扩展流（主要是后者）。

对于一些复杂产品、系统的研发，这类异常、错误、极端、复杂的需求信息往往耗费了实际开发的大量工时和人力（> 50%），而忽视、遗漏、误解这些需求正是导致许多软件工程不成熟团队频繁变更需求，发布、交付经常 delay 的一个主因。

一个过于简单、不含（或未考虑到）这类特殊需求的产品原型其实是没什么价值的，反而容易误导客户、领导与开发者，让大家对交付进度与质量产生不切实际的预期。基于不靠谱的需求、原型做出来的所有开发计划、项目估算、假定与预测自然也是不靠谱的，进度失控自然会成为高概率事件。

为什么进度会失控？因为从一开始大家都只看到了产品需求的“冰山一角”，据此作出了乐观的估计，轻视各种存在的风险，坦然、淡定、一切正常地稳步前进；等到开发的中后期才意外地发现原来 还有这么多要做啊！于是乎拼命地加班加点，手忙脚乱，打疲劳战，然并卵——要按照原来既定的 deadline 交付已经来不及了。

Solution

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

请问各位产品的大神，这样的问题是如何解决的，功能细节的细化边界在哪里，有没有好的制度改善这种情况。

当然有成熟的解决方案。

1）让产品部拥有优秀的需求分析师，熟悉产品的交互设计尤其是 Use Case 分析。在开发阶段为开发团队配备一名专职的需求分析师。

2）功能细化的边界就是 Use Case，标准化公司的 Use Case 模版，让 Use Case 成为产品经理、需求分析师与开发、测试乃至整个团队之间沟通的有效媒介。

怎样科学地从需求用例导出测例？估计您看了 IBM developerWorks 上的这篇精彩文章就全明白了：

Traceability from Use Cases to Test Cases

还有一篇更早（2001 年）的 PDF：

Generating Test Cases From Use Cases

3）你们的产品开发过程也好像是落后的瀑布式（Waterfall），让你们的 CTO 学习掌握敏捷开发，然后把公司的开发过程转换到迭代式（Iterative）。

开发过程

我认为这个过程应该是有流程来规范和引导立项后从任务书到开发语言的转化过程，且有明确交付物和节点。

对，这些就是开发过程（Development Process）应该定义的基本内容。任何成熟的工程、研发团队都应该有成熟的产品、系统或软件开发过程规范。

OpenUP 是 Eclipse 开发推荐的一个敏捷开发过程模型，参考在线文档：

OpenUP

我的理解是将任务书与原型评审作为与开发的交接点。现在开发采用所谓的敏捷模式，没有详细设计这个阶段。原型毕竟不是最终产品，随着开发深入，细节的问题会越来越多，甚至有些功能无法实现到这个阶段才能识别。这个过程处于一个失控状态，这是我困惑的地方。

把任务书与产品原型作为产品与开发之间的交接点，对于你司很可能是不合适的。如果合适的话，你们的开发也不会提出那么多问题了。缺点我前面讲过了，主要是任务书里所反映的产品需求（特性）太粗略，因而产品提交的需求质量差，缺很多东西，事先没考虑到或没考虑清楚，导致开发不满。

总结

我 18 年研究 Use Case 与软件需求分析的体会是：

一个高质量的产品需求模型（PRM，Product Requirement Model）是产品与开发之间的最佳沟通媒介。这个模型应该清晰、完备，既详尽又易读，它的表达主要包含了抽象与具体两部分，抽象的如用例文本与 UML 图形，具体直观的如 Axure 线框图等。PRM 包含了 PRD。

如果你们学会了成熟的迭代式开发（先掌握迭代，再来谈敏捷），那么整个开发过程就不可能失控。

来源：知乎 www.zhihu.com
作者：张恂老师

【知乎日报】千万用户的选择，做朋友圈里的新鲜事分享大牛。点击下载

此问题还有 63 个回答，查看全部。