产品经理需要写MRD吗

|流光碎影

产品经理需要写MRD吗
Market Requirements Document,简称市场需求文档。市场需求文档的主要功能是描述什么样的功能和特点的产品(包含产品版本)可以在市场上取得成功。产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现 商业目的,功能/非功能需求分哪几块,功能的优先级等等。

一般来说,我们最常见的PRD是在MRD的基础上产出的,当然,产出PRD还需要原型、思维导图还有Feature List之类一堆东西的辅助。

作为产品经理,我参与过好几个项目,从大公司到小公司,产品经理的角色,一直都在实际上处于很尴尬的位置。上周末的UCD广州年会,帽子男发问“能够参加自己公司核心战略会议的请举手”----会场上举手者寥寥无几。关键,白鸦问的是“参加”而不是“参与到”,如果问的是后者,估计人就更少了。

产品经理这一概念,在05~07年产品的理念刚刚插入中国互联网时,是很火热很强势的。产品经理的角色定位通常都是公司总裁或者副总裁的直属员工,管理的产品部门属于公司的直属部门,会参与到公司整个市场分析、战略、决策、运营、推广等各方面中去;那个时候,MRD是属于产品经理的重点工作之一,尤其那个时候的大部分产品经理都是由市场转型过去的。

最近几年,产品的概念在中国互联网开始深化。一方面,产品经理慢慢退出公司战略与决策部门,取而代之的是通过数据研究去知道决策的UED部门(初期这个也是产品经理的工作之一);另外一方面,产品经理的更多精力也开始投放在产品细节上,并且与UED 部门进行协作式产出PRD文档;当然,还有一个不好的方面,当产品的概念泛滥以后,部分PD、前端甚至美工也开始自称产品经理,这些“产品经理”自然无权写MRD了。

有些朋友告诉我,他们公司是把MRD合并在PRD里面一个文档完成的。我想,这是不是有点多此一举的味道在,一般来说,PRD 文档是交付给开发部门的文档,MRD写在里面,第一方面是没人看,第二方面是你写那么多东西给到下面开发部门,他们根本就看不懂(或者根本不愿意去看懂)。产品和开发从来就是一个不可调和的矛盾体,有些是运营做调解有些是根本就是产品部门去直接对接。妄想以MRD去告诉开发部门哪些功能非常重要切勿删掉还不如直接在PRD上以红色粗体说明更有意义(just kidding,我很多时候是真的想这么做的)。

软件开发需求分析时,做不到的需求怎么处理

对商业用户来说,他们后面是成百上千个供应商,前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客,如何做好精细到一个
小小调料包的进、销、调、存的商品流通工作,这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目,
正是软件开发成功的关键所在。
--- 经理:“我们要建立一套完整的商业管理软件系统,
包括商品的进、销、调、存管理,是总部-门店的连锁经营模式。通过通信手段门店自动订货,供应商自动结算,卖场通过扫条码实现销售,管理人员能够随时查询
门店商品销售和库存情况。另外,我们也得为政府部门提供关于商品营运的报告。”

-- -分析员:“我已经明白这个项目的大体结构框架,这非常重要,但在制定计划之前,我们必须收集一些需求。”

-- -经理觉得奇怪:“我不是刚告诉你我的需求了吗?”

--
-分析员:“实际上,您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨
论,然后才能真正明白达到业务目标所需功能和用户要求,了解清楚后,才可以发现哪些是现有组件即可实现的,哪些是需要开发的,这样可节省很多时间。”

-- -经理:“业务人员都在招商。他们非常忙,没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统?”

---
分析员尽量解释从用户处收集需求的合理性:“如果我们只是凭空猜想用户的要求,结果不会令人满意。我们只是软件开发人员,而不是采购专家、营运专家或
是财务专家,我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过,未真正明白这些问题就开始编码,结果没有人对产品满意。”

--- 经理坚持道:“行了,行了,我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发,并随时将你们的进展情况告诉我。”

--- 风险躲在需求的迷雾之后

-
--以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中,所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指
的风险承担者包括客户方面的项目负责人和用户,开发方面的需求分析人员和项目管理者。这部分工作做得到位,能开发出很优秀的软件产品,同时也会令客户满
意。若处理不好,则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。

-- -拨开需求分析的迷雾

--- 像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲,像“雾里看花”般模糊并令开发者感到困惑。那么,我们就拨开雾影,分析一下需求的具体内容:

-- -·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求,通常在项目定义与范围文档中予以说明。

--- ·用户需求——描述了用户使用产品必须要完成的任务,这在使用实例或方案脚本中予以说明。

--- ·功能需求——定义了开发人员必须实现的软件功能,使用户利用系统能够完成他们的任务,从而满足了业务需求。

-- -·非功能性的需求——描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制。

--- ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

--- 前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容,为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定,然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

--- 下一层次需求——用户需求,必须从使用产品的用户处收集。因此,这些用户构成了另一种软件客户,他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如:程序的易用性、健壮性和可靠性,而这些特性将会使用户很好地接受具有该特点的软件产品。

--- 经理层有时试图代替实际用户说话,但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者,必须让实际用户参与到收集需求的过程中。如果不这样做,产品很可能会因缺乏足够的信息而遗留不少隐患。

---
在实际需求分析过程中,以上两种客户可能都觉得没有时间与需求分析人员讨论,有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇
到的需求极为简单;否则不能这样做。如果您的组织希望软件成功,那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

--- 优秀的软件产品建立在优秀的需求基础之上,而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时,才能建立起一种良好的合作关系。

--- 由于项目的压力与日俱增,所有项目风险承担者有着一个共同目标,那就是大家都想开发出一个既能实现商业价值又能满足用户要求,还能使开发者感到满足的优秀软件产品。

-- -客户的需求观

-- -客户与开发人员交流需要好的方法。下面建议20条法则,客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧,将通过协商达成对各自义务的相互理解,以便减少以后的磨擦(如一方要求而另一方不愿意或不能够满足要求)。

--- 1、 分析人员要使用符合客户语言习惯的表达

--- 需求讨论集中于业务需求和任务,因此要使用术语。客户应将有关术语(例如:采价、印花商品等采购术语)教给分析人员,而客户不一定要懂得计算机行业的术语。

--- 2、分析人员要了解客户的业务及目标

---
只有分析人员更好地了解客户的业务,才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人
员,客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统,那么开发和分析人员应使用一下目前的旧系统,有利于他们明白目前系统是怎样工作的,其流
程情况以及可供改进之处。s

--- 3、 分析人员必须编写软件需求报告

---
分析人员应将从客户那里获得的所有信息进行整理,以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析,客户就能得到一份“需
求分析报告”,此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告,以确
保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

--- 4、 要求得到需求工作结果的解释说明

---
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明,因为工作图表能很清晰地描述出系统行为的某些方面,所以报告中各种图表有着极高的价
值;虽然它们不太难于理解,但是客户可能对此并不熟悉,因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果,以及怎样检查
图表有无错误及不一致等。

--- 5、 开发人员要尊重客户的意见

--- 如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间,同样,客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

--- 6、 开发人员要对需求及产品实施提出建议和解决方案

---
通常客户所说的“需求”已经是一种实际可行的实施方案,分析人员应尽力从这些解决方法中了解真正的业务需求,同时还应找出已有系统与当前业务不符之处,
以确保产品不会无效或低效;在彻底弄清业务领域内的事情后,分析人员就能提出相当好的改进方法,有经验且有创造力的分析人员还能提出增加一些用户没有发现
的很有价值的系统特性。

--- 7、 描述产品使用特性

---
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性,因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如:客户有时要求产品要
“界面友好”或“健壮”或“高效率”,但对于开发人员来讲,太主观了并无实用价值。正确的做法是,分析人员通过询问和调查了解客户所要的“友好、健壮、高
效所包含的具体特性,具体分析哪些特性对哪些特性有负面影响,在性能代价和所提出解决方案的预期利益之间做出权衡,以确保做出合理的取舍。

--- 8、 允许重用已有的软件组件

---
需求通常有一定灵活性,分析人员可能发现已有的某个软件组件与客户描述的需求很相符,在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够
降低新系统的开发成本和节省时间,而不必严格按原有的需求说明开发。所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合您所需的特
性,这时一定程度上的需求灵活性就显得极为重要了。

--- 9、 要求对变更的代价提供真实可靠的评估

---
有时,人们面临更好、也更昂贵的方案时,会做出不同的选择。而这时,对需求变更的影响进行评估从而对业务决策提供帮助,是十分必要的。所以,客户有权利
要求开发人员通过分析给出一个真实可信的评估,包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

--- 10、 获得满足客户功能和质量要求的系统

--- 每个人都希望项目成功,但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制,一定要明确说明您的假设和潜在的期望,否则,开发人员开发出的产品很可能无法让您满意。

--- 11、 给分析人员讲解您的业务

--- 分析人员要依靠客户讲解业务概念及术语,但客户不能指望分析人员会成为该领域的专家,而只能让他们明白您的问题和目标;不要期望分析人员能把握客户业务的细微潜在之处,他们可能不知道那些对于客户来说理所当然的“常识”。

--- 12、 抽出时间清楚地说明并完善需求

热门推荐
  • 电子商务专业应该掌握哪

    电子商务专业应该掌握的基本技能: 1. 一定要会使用photoshop 对学生朋友并不要求真正的能用的有多么多好,但基本的...

  • 产品经理需要写MRD吗

    产品经理需要写MRD吗 Market Requirements Document,简称市场需求文档。市场需求文档的主要功能是描述什么样的功能和特点...

  • 做一个app一般需要多少时

    需要40天,甚至更久 1、需求规划——制定完整的需求文档,理清楚所有的功能规则和功能交互,大概3-5天。 2、UI交互...

  • 市场的需求文档含义?

    根据某一个产品,在市场中哪些人群,哪类场合需要购买来写 软件工程中需要多少文档 最基本的:立项文档,需求分...

  • 如何用java进行移动端后台

    java进行移动后台开发与java进行web后台开发完全一样。java原生的后台框架servlet,如果使用java后台开源框架可以选用s...

  • 一份有效的软件测试计划

    先说说啥是软件测试计划; 所谓测试计划是指描述了要进行的测试活动的范围、方法、资源和进度的文档。它主要包...