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 个回答,查看全部。

相关 [faq 产品经理 产品] 推荐:

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

- - 知乎每日精选
产品经理对产品细节需要给出到什么程度. 产品需求往往写到 Use Case(用例)的程度,才刚刚好. 用例最早至少是在 1998 年随着 Rational Rose、RequisitePro 和 RUP 5.0 传入中国的,那时 Rational 公司(2003 年被 IBM 全资收购)还未正式进入中国,而国内一些领先的企业、大学和研究所(先驱者)已经在开始学习使用 UML 与 Use Case 了.

产品经理

- - 人月神话的BLOG
再谈下怎样能够算得上一个合格的产品经理,一个人不是说你能够有产品构思,能够画点原型,能够做团队和项目管理就是产品经理. 苏杰原来有本书叫《人人都是产品经理》,看了后大家可能会觉得做一个产品经理是挺容易的一件事情,但是自互联网提供和设置了大量的产品经理岗位后,产品经理这个词基本就烂大街了. 我们如何来界定一个产品经理,如果简单点来讲可以理解为 根据自己长期的项目和运营实践,通过自己的敏捷洞悉能力和分析能力,能够将当前的市场需求或潜在的市场需求转化为具体的产品需求,并能够核心的定义产品功能模型和价值输出,同时能够通过项目和团队管理的能力,凝聚一个小组形成一个真正的团队,将自己的产品构思付诸于最终产品实现的人.

产品经理好与坏

- lnsoso - 随心所记 - 生活中的dodo
例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.

产品经理是炮灰

- 张金龙 - 所有文章 - UCD大社区
前些日子有篇网文,鼓吹产品经理的重要性,几乎夸上了天. 有人评论道:“是为了争取加薪吗. 一个人能取得多大的成功,取决于两点:1、他有多少才华与热情,2、这些才华和热情是否能战胜环境中的困难. 很遗憾,摆在产品经理面前的障碍大部分是不可战胜的. 在这篇文章里,我们只讲靠谱的产品经理,不讲不靠谱的. 不论PM靠不靠谱,都分为两种,或者在大中型公司工作,或者在小型公司(创业团队)工作.

产品经理好与坏

- abcd - 所有文章 - UCD大社区
例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.

产品经理是炮灰

- Neglect - 坏脾气的小肥
前些日子有篇网文,鼓吹产品经理的重要性,几乎夸上了天. 有人评论道:“是为了争取加薪吗. 一个人能取得多大的成功,取决于两点:1、他有多少才华与热情,2、这些才华和热情是否能战胜环境中的困难. 很遗憾,摆在产品经理面前的障碍大部分是不可战胜的. 在这篇文章里,我们只讲靠谱的产品经理,不讲不靠谱的. 不论PM靠不靠谱,都分为两种,或者在大中型公司工作,或者在小型公司(创业团队)工作.

产品经理“玩”数据

- - 一个产品经理的博客...
  产品经理生来就是要解决问题的. 那如何才能更好、更高效地解决问题?首先要求我们能发现问题,数据分析就是一种常用的发现问题的手段. 通过数据定位问题,然后用设计方案来尝试解决问题,之后再用量化的数据指标来评估问题是否解决了,解决了多少. 通过迭代优化,问题就能够得到较好解决.   本文结合自己在在登录产品的体验优化中积累的一些实战经验,重现过程中的设计点滴,有效果明显的方案,也有效果不明显的优化尝试,最后将总结一些通用的设计思路.

好的产品经理,差的产品经理

- - Xiaoxiao's Weblog
本文转载至 译言网 作者: Ben Horowitz. Ben Horowitz这篇不朽的杰作诞生于1996年,但时间的久远丝毫不影响其对当前的警示作用. 彼时,作为Netscape产品管理部门经理的Ben,没有假大空地介绍产品经理的角色和责任,而是很直观地对比了一个好的产品经理和差的产品经理.

一个谷歌产品经理眼中的产品经理

- - 互联网分析
我在创业公司已经呆了好一阵子了,我发现招聘这个事儿在大公司和创业公司还真是截然不同. 在雅虎搜索的时候,我们一直是持续的进行招聘的. 我一周会进行大概5-8次的面试. 简历、面试、offer,总是一个接一个,不间断. 现在我已经不做招聘经理的事儿了,我在创业公司只负责招很少一部分的产品经理. 但是总有人在招产品经理,而我也总是面试团队的一员.

优秀的产品经理/糟糕的产品经理

- - 标点符
每个产品经理都希望自己时优秀的,而不是糟糕的. 但如何定义是否优秀却没有一个统一的标准. 最近看到了一片文章,中间的一些观点给了我非常大的启发,让自己意识到原来自己做的很多事情,其实是属于糟糕产品经理做的. 优秀的产品经理:关注团队的快乐指数. 当一个团队对产品开发过程感到不满的时候,就无法为客户创造出好的产品,他们也不会喜欢自己的工作,一个好的产品经理除了会收集正式的反馈,同时也会收集一些关于项目、迭代余流程的非正式反馈.