写好MRD的10种技巧[转]

转自:http://bbs.bianews.com/thread-69395-1-1.html

        MRD-“市场需求文档”,是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品,是被工 程师团队开发产品时使用。         在硅谷的一些软件公司,MRD仅仅覆盖high-level的功能。在这种情况下,产品经理通过创建了另一个文档-通常指的是PRD(产品需求文档)来 定义更加详细的产品需求。
        在本文中,我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的,为工程师团队传达产品需求为目的的文档。
       写好MRD的10种技巧
1、从用户角度的编写
        从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色(User Personas)”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA(sales force automation)软件的“Login”的功能性。
       方法A:
       用户通过一个要求用户提供证书的登陆界面,然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书,在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。
       方法B:
        Mike是一个销售经理,Cathy是一个销售代表。当他们打开软件,他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确 的,他们能登进系统。一旦登陆进系统,Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。
        哪个方法更加容易阅读和理解?就我的看法,毫无疑问,”方法B”。还有,它同时减少了令人烦恼的阅读!
2、使用Screen Shots

        使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候,一个screen shot好比一千个文字!
        举个例子,看看下面这个screen shot,你需要多少字来描述?我想可能不只一千个字。
3、用简单的语言编写
        在我超过11年的行业中,我通常注意到的(更多是令我懊恼)一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。
        相反,想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么,以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦(有时他们会把MRD撕碎然后再碎片喂给碎纸机)的用做作的语言的陷阱。
        还有:
        a)保持简短的语句,把长的语句分解成多个小的语句。
        b)避免大篇幅的连续文本,把他们分解成多个小的章节。
        c)把大块文本内容分解成,screen shots,表格、重点列表等等。
4、小心的使用模板

        我发现MRD模板非常有用。他们的几个好处包括:
        a) 模板提供了一个标准的格式,使那些不得不阅读大量MRD的读者更加容易阅读。
        b) 模板让新的产品经理快速的写MRD变得容易,因为公司与公司之间的MRD内容是不同的。
        c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分;
        然而,一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近60页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用:
        a) 产品经理害怕但又不得不写MRD – 几乎和不得不和Dick Cheney去南德克萨斯打猎一样(译者按:美国副总统Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴)。
        b) 工程师团队害怕但又不得不阅读MRD。
        c) 写MRD和读MRD都需要花大量的时间。
        我推荐你使用MRD模板,但确保他们不要过分的长。还有如果需要,确信产品经理可以灵活的跳过模板某些部分和创建新的内容。
5、区分需求的优先级
        在这些年里,我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素!
        这就是说作为MRD作者的产品经理,当出现需要决定取舍的时候,应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。
        区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1,P2,P3…这样工作的刚刚好。在这个分类中-P1是最高优先级,P2是第二高优先级等等。
        最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中,最好是和其他多种因素一起综合决定。
        我推荐你只要包括P1,P2,P3的需求在你的MRD中,在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。
6、说明”是什么”和”为什么”,但不要”如何”
       产品经理为理解客户的需求负责,然后基于这些理解定义什么和为什么需要开发.
有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的MRD。
       考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。
       推荐-描述“是什么”
       Mike是一个销售经理,当他打开我们的CRM软件,他会看到一个登陆界面…登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框,我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。
       不推荐-描述“怎么样”
       Mike是一个销售经理,当他打开我们的CRM软件,他会看到一个登陆界面…登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择 了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。当cookie写到硬盘后,用户名和密码将被发送到服务器。下一次Mike来到登陆界面 时,Javascript 将读取他的cookie,成功读取后,Javascript 将是适当的DOM命令填充登陆页面上的用户名。好的产品经理擅长理解用户的需求和描述什么需要实现,好的工程师擅长决定怎么样实现它。好的工程师希望能自 由的决定怎么样最好的实现用户希望得到的东西。