Ⅰ 如何写好产品需求
产品经理日常一项重要工作就是收集整理产品需求,转化为产品需求文档,将需求传递给项目团队成员,完成需求功能开发测试上线。如何写好产品需求属于技术活,好的产品经理的需求有条理,由浅入深阐明问题及解决方案,而一般的方案会让人看过后不知所云,需要再次澄清需求。
如何写好产品需求,有小窍门或理论可以参考,比如金字塔原理,在产品初期,我们往往会犯思路不清晰、无法明确表达自己的想法,或者提炼不出产品核心需求点的问题。这时,运用金字塔原理可以帮助我们构建清晰的逻辑思路,更好地表达产品观点。
根据金字塔原理的指导,从分析需求产生的背景,到根据背景认清冲突点,分条列出冲突问题,归纳整理思路;最后根据已知问题,针对性地提出解决方案,寻求解决问题之道。以上步骤完成后,便可以将所有思路总结成文档,具体实施。这种构建方式可以很明确地表述自己的思想,增强代入感。
归纳总结共三点:
1、分析背景,提炼关键需求点
关键需求点不用长篇大论,最好能一句话说明要做的事情,如果要深入细节,再详细描述。
2、用归纳法理清你的思路
提炼关键需求点后,可以针对需求点提出相应解决方案,多个需求或解决方案之间可能存在逻辑关系或冲突,通过归纳法来总结梳理,帮助把握核心需求点、区分优先级。
3、寻找问题解决知道
归纳总结问题后,剩下就是针对问题寻找解决方案了,解决方案的好坏取决于产品经理的经验与学习能力。
Ⅱ 需求文档怎么写最有效
能将功能需求写清楚的就是好的需求文档,因为现在的需求文档一般都是给开发看,一般来说创业公司追求小步快跑快速迭代的开发模式的话,需求文档不是一个很有必要的东西,直接在原型上表述效率会更好。如果公司追求规范管理的话,建议还是需求文档,写清楚项目名称,迭代版本,及相关的日期规划。
Ⅲ 怎么写新产品的产品需求方案
一款新产品在推向市场做推广之前要考虑以下几个问题:找到市场上的同类产品的差异化,提高市场推广的销售份额;增加产品结构,提高品牌竞争力;拓展空白市场,增加产品的知名度。那么怎么写新产品的产品需求方案呢?下面一起和我看看吧。
篇一
一、写产品需求的准备工作
你要做的是一个让人无可争议的产品,为了做好他,你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。
建立良好的交流也非常重要,它会影响着产品团队。如果你的准备工作做的够好,你也会变得越来越有信心和说服力。
二、清楚了解产品需求
任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求,你的产品如何达到这个需求。
产品经理需要提出一个清晰、简明的价值主张,让它很容易被接受,要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单,但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO,他问你产品的意图是什么,你能在电梯到达之前回答这个问题吗?如果不能,你就还有工作需要做。也许是你的说明没有针对性,他可能表现出来和其他产品做的没有什么明显区别;也许你提出的观点不能和你的用户产生共鸣;也许你解决的是一个非常规的问题,可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节,从某些方面来说,一个有价值的观点应当是越简越好。
产品需求需要确切的指出这个产品发布的目标,同样的这个目标也有优先之分。例如,你的目标可能是:1)易用,2)零售价不足$100,3)和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目,你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性,也测算出可用性问题的严重程度,同样你可以说明没有重大的可用性问题。
这里的关键就是让每个人都知道产品成功的时候是什么样,还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。
三、确定用户原型、用户目标和用户任务
现在你已经明白你想要解决什么问题,下接下来就要深入了解目标用户和顾客,在这步中,和你的PD(产品设计)紧密联系非常重要。
1、用户原型
在这个阶段,PM需要和很多用户交流,需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类,然后决定那一类是我们的首要用户。
比如你正在做一个像eBay一样的互联网拍卖服务,你同时拥有买家和卖家,在这之中还有使用频率少的用户和经常使用的用户,不难想象还有个别特殊的用户,比如团体公司采购者。
PM(产品经理)和PD(产品设计)需要首先确定类型是最重要的,然后尽量对这个用户群的特征进行详细的描述,以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想象的,但是应该是典型的、可行的和真实的,让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。
注意缩小范围,让他仅仅描绘必不可少的。满足所有人是徒劳的,通常最后没人会满意,所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样,如果你不去精确的定位你的目标用户,你就只会存在模糊的概念,你会发现理解你用户的反应非常困难。你要倾向于设想,让你能更像你的用户。
2、用户目标(用户意愿)
一旦我们确定并描绘了我们主要的用户类型,我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单,但是解开根本问题是非常具有挑战性的,特别当你周围的人告诉你你已经解决了他们想要的。从CEO、销售代表、工程师到客户,每个人都太兴奋而不能帮助你找到解决根本问题的办法,他们会告诉你在某个地方添加一个快捷按钮,或则添加一个功能仅仅是因为竞争对手有,或则是改变成他们喜欢的颜色。
最好的解决办法取决于清晰的了解到底什么问题需要解决,每个用户模型可能有不同的目的,需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。
3、用户任务(tasks,用户为达到目标使用产品而需要做的任务)
掌握了用户原型与他们的目标愿望,我们就开始着手设计任务来满足他们的目标意愿,这是产品制作进程中最核心的部分,也是创造力和创新力被激发的地方。
许多优秀的产品仅是用更好更新的办法解决一个已有的问题,有时候这种办法仅仅是应用一个种新技术,但是大部分是来自深刻的见解而使一种新方法的产生。
注意我们虽然谈到了目标和任务但是还没有谈到具体的功能,这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。
以“必须功能”这个理由可以排除很多功能。讽刺的是,你用越少的功能,你的产品被发现得越来越强大。这是因为产品的功能越少,你的用户就会发现并使用更多的功能,成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的,我们大多数人都不能和我们的用户一样,我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。
四、写产品需求的原则
现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡,为你的产品标准作出最佳的决定是非常重要的。
在大多数的产品团队中,每个成员都有做好产品的原则,但很少有两个人有同样的想法,这些差异都会导致不可思议的结果。尝试和制订一系列指导整个团队的产品原则是非常有价值的,这些原则需要具体到域名和项目。
五、检验测试产品
这是一个拿出你想法的阶段,创造力和创新力拿出成就的地方.很多人都容易犯一个常见的错误,他们对产品设计规范太有信心,结果一旦得到beta的测试他们就必须调整产品。
但是肯定beta测试版并不是进行重大改变的时候,所以才会有许多首次发布的产品离目标太远。对于许多产品来说,这个时候你可以用大量的原型做很多的实验。首先,下面的三个非常重要的测试你可能需要做可行性测试
产品是否可以开发 你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的,但是有其他的办法可行是非常有希望的。工程师会发现在产品的某个阶段不可能逾越,现在知道比以后知道要好。
可用性测试
产品设计师将要和你紧密工作共同提出产品功能,让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求,同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试,从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用,但是实际是没有人能取代真实的目标用户。
概念测试(Proct Concept Testing)
光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。对于一部份小产品,您的想法写在纸就足够了,但是对于多数产品,为了预计产品是否达到目标,复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。
原型也许是一个物理设备,或者它也许是软件产品的一个预览版本。关键是它需要足够现实,您能用原型在实际目标顾客身上测试,并且他们可以给您质量反馈。
以前做原型主要有两个障碍。第一是缺乏良好的原型工具,需要花费很多的时间制作原型;另一个是管理方不知道原型和真实产品的区别,在不可预计的情况下,按照最终产品来要求原型。
今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型,可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样。
在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始,作出重要的变动会变得非常困难,花费也会变得很高。
六、对新产品进行验证和质疑
当你认为你弄懂了你需要解决的问题,现在是时候开始验证和质疑假设。假设甚至当作不知道是很容易的,但是切勿把不可知的结论当作指引,那会妨碍你获得成功。
七、在写产品需求时要考虑优先级
除了明确的要求,对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理,如果他们给予优先级,一般都是表明要求是否是“必须有, “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的,不可掉以轻心。
产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”,这些标注“必须拥有”的功能直接反应出产品的核心价值。
“重要”的分类也很重要,在产品销售前只要有机会就要满足这些功能。
“希望拥有”产品团队也应该注意到,即使大多数也都没有实现,在未来版本也适当的慢慢实现。
这些有时候是不够的,从1到n每一个分类优先排序都是很重要的。有几个原因:
首先,上市时间总是被关注,并且日程表经常下降,您说不定被迫使削减有些特点为了尽快进入市场。 你也不想产品团队先开发简单的功能而放松重要的功能,导致最后客户使用的关键功能还没完成。
其次,在产品设计和开发阶段,团队将会发现更多的问题产生并解决这些问题,所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。
这点就是说产品经理如何不给出优先级和重要等级,其他相关较少的因素也会跟着无法确定。
整个PRD是一个不断完善和思维提高的过程,明朗锐利就是可以成功的产品的,模糊就是失败的产品。在争论最激烈的时候也能容易做决定,并且帮助工程师做出计划。
八、测试产品需求完整性
现在你有一个PRD草稿,你需要测试它的完整性。工程师是否可以充分了解并达到目标?OA Team(质量管理团队)是否有足够的信息来做出测试计划,是否可以开始做案例?
当投资人或相关人审核了PRD,确定了各个需要说明的方面,所有的问题得到解决,现在你就可以按PRD进行产品开发。
九、管理产品
在产品实施期间,就算是最好PRD,也有不计其数的问题被解决。解决所有PRD中存在问题,如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。
如果你做了你的工作并准备记录在PRD,项目审查就会变得非常简单,因为任何一个部份都历历在目。
记住PRD是一个“活”的文件,在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西,如果你认为是必要的就在PRD中写进。
篇二
当今时代,唯一不变的事情就是变化,创新是企业生命之所在,创新已经成为时代发展的主旋律。对白酒企业而言,开发新产品具有十分重要的战略意义,因为随着白酒行业竞争的日益白热化,企业要想在市场上保持竞争优势,只有不断创新,开发新产品,才能巩固市场,不断提高企业的市场竞争力,保持市场可持续发展。因此,新产品是企业生存与发展的重要支柱,是确保企业基业长青的有力武器;对于营销人员来说,推广新产品是提升业绩,增加收入,体现个人业务能力的有效途径;对经销商和二批商来说,新产品是提高销量,增加利润,保证厂商双赢,保持市场可持续发展的有效办法。
然而现实中往往很多企业投入了大量的人力、物力、财力研发的适合市场的新产品却在推广的过程中早早的夭折了。为什么即使适合市场的新产品会在推广的过程中会夭折呢?事实证明原因如下:一、凡是新产品推广较好的企业都有推进计划,并按计划一步步进行落实。而那些推广不好的企业则是企业将新产品分给客户就万事大吉,不再采取其他积极推进措施。二、真正的销售是靠人来落实的,往往企业的销售人员和经销商会对新产品存在严重的抵触情绪,抵触的原因是,销售人员和经销商不愿意去费心费力推广新产品,他们都会把注意力集中在成熟产品做促销,迅速起量上,这样做既轻松销量提升也明显。那么,企业要确保新产品成功推广应采取哪些步骤呢?
确保新产品成功推广的“步骤”
一、确保销售队伍和经销商、二批商的关注度和士气、齐心协力推广新品
新产品上市前举办新产品上市培训会,充分调动渠道中各个成员的积极性。提高销售人员、经销商、二批商的积极性,共同参与到新产品推广中,形成“三级联动”推动新产品推广的氛围。如: 向销售人员、经销商和二批商进行“新产品推广的重要性”宣导,向他们介绍清楚新产品的诞生思路、它的优势和利益点在那里,具体的包装口味、价格描述是怎样的等等,使渠道中各成员对新品的上市做到心中有数,增强信心。另外针对销售人员、经销商和二批商进行新产品上市各项过程指标的专项考核,加快新产品铺市速度,形成新品销售氛围,让他们明白“过程做的好。结果自然就好”,只要能把新产品推广过程中的各个指标(铺市率、陈列、促销、价格体系等等)落实到位,新产品自然就会推广成功,销量自然就好。如:新产品在上市销售的过程中会有广告投放、铺货、经销商进货奖励、二批及零店促销、超市进店、消费者促销、销售人员开店奖励、等一系列动作,新品上市计划要对每一项工作做出具体规划和安排,确保新产品推广的各项活动有条不紊的进行。具体要做到:
1、新品上市前召开所有销售人员、经销山和二批商新产品推广培训会。
2、对所有销售人员、经销商专门订出新品销量任务;
3、日常销售报表和会议体现对新品销售业绩的格外关注,建立完善的业绩分析系统全程掌控新产品推广动态 ;
4、上市执行期销售例会中新品业绩成为主要议题。对不能如期完成新品推广任务的市场要求做出“差异说明”,并进行奖罚激励 ;
5、举办销售竞赛(如:新品销售冠军)对优胜者予以公开表彰和奖励;
6、人员奖金考核制度,把新品销量达成从总销量达成中提出来单独考核;
7、企业高层领导对新品推广不力市场亲自检核,指出工作漏洞并进行协助;
二、确保经销商进货并在正确的渠道分销
要确保经销商按照推进计划在规定的时间内按照企业的进货标准进新产品,并且把新产品在正确的渠道分销。因为在实际推广的过程中,企业的销售人员和经销商往往凭自己的主观判断新产品不好卖,所以就一拖再拖不进货或者适当进点但是没有放到正确的渠道去销售,就判断企业研发的新产品不好卖,肯定会影响新产品的成功推广。例如:有一家白酒企业在新产品上市初期,对所有渠道人员召开了新产品推广培训会,也制定了详细的推广计划。可是在具体推广的时候,A经销商主观认为新产品不好卖,就迟迟不肯进货,经销商连新产品进都没进是不可能推广的;B经销商到是按照企业的规定时间和数量进货了,可是把中高价位的新产品放到C、D类酒店和 C、D类商超渠道销售,结果导致合适的产品没有放到合适的终端店销售,使得新产品动销缓慢,就反映企业的新产品不好卖。
三、确保对于新产品推广的指导、协助必须参与进去
要确保渠道中个成员对产品推广的指导、协助必须参与进去。就是经销商进货后要做到让销售人员下市场车上必须装新产品,拜访终端店时必须把新产品上市的信息告知终端店并把促销政策准确无误的介绍给终端店(卖新产品的利润比老产品利润大)。如:C经销商是按照企业的要求进了新产品,可是新产品进了以后,每天业务员的送货车上不装新产品,业务员下市场也没有把新产品上市的信息告诉终端店,也没有把新产品的促销政策介绍给终端店,终端店也就不知道新产品上市的信息,也不知到销售新产品比销售老产品的利润空间大,结果导致新产品在该市场推广失败。因此渠道成员如果没有对新产品的指导、协助参与进去,就说新产品不好卖,新产品的推广肯定是不会成功的。
四、确保新产品的价格体系
确保新产品按照企业规定的价格体系销售,因为新产品上市前,企业是经过大量的市场调查,根据市场的实际研发出来适合市场的新产品。因此在新产品推广的过程中必须检查经销商的出货价是否正确,有没有按照企业规定的价格执行;终端的零售价格是否正确,有没有按照企业规定的统一零售价销售。在实际推广过程中往往渠道成员擅自更改企业新产品的价格体系销售,结果影响新产品的推广,反倒说企业研发的新产品不适合自己的市场不好卖。如:A企业的新产品在上市的时制定的价格体系:经销商开票价:20元/瓶(经销商的利润来自于企业的返利),终端店开票价:20元/瓶,终端店零售价25元/瓶。但是在实际推广的过程中,经销商私自把终端开票价改成25元/瓶,终端店零售价改成35元/瓶,结果导致新产品的价格体系脱离的了企业推广新产品打压竞品、抢占25元价位市场占有率的目的,结果使得终端店感觉新产品的包材支撑不了35元/瓶的价位,使得新产品市场铺市率低动销迟缓,使得新产品在该市场推广夭折。
五、确保新产品陈列和推销
要确保新产品按照企业的陈列标准陈列和确保终端店主主动推销。因为在新产品研发阶段企业是经过大量的市场调查的,从而确立新产品在该市场的竞争优势,在推广的时候制定相应的促销政策和陈列标准。因此在新产品推广的过程中必须确保按照企业的规定的陈列标准做好柜台陈列,并且在维护的过程中不厌其烦的告知终端店新产品的优势以及销售新产品的利润空间,以及销售新产品的奖励政策。如果陈列不合格,店主不知道销售新产品的利润和政策,那么新产品推广就不可能成功。如:A企业在新产品推广的过程中渠道成员都反映新产品不好卖。结果企业派市场部人员去市场走访过程中发现,终端店是签了陈列协议,但是新产品有的在终端店的库房根本就没有摆上柜台;有的即使摆放在柜台但也不在明显位置。当问到终端店新产品是多少钱进的,卖多少钱,终端店也不知道,意味着终端店销售新产品都不知道比销售同等价位的竞品利润空间大。结果导致新产品在该市场推广迟缓。
六、确保新产品的铺货率
铺货率检验是新品上市成功的基础,铺货率达不到一定水平,评估新品接受度根本没有意义,因此必须确保新产品在市场上达到规定的铺市率(低于60%的铺市率是很难判定新产品是否适合该市场的)。如:某企业在新产品推广的时候,经销商是打款发货了,结果经销商在新产品推广的时候,只把新产品放到跟他关系特好的几家终端店销售,因为这些终端店在吃独食,所以他们零售价卖的很高。结果导致新产品在该市场没有形成一定的市场占有率,市场占有率低使得市场影响力低。
七、确保力所能及的掌控的终端售点数量的铺市率
所谓为力所能及的终端网点的铺市率,就是指该终端店和经销商的客情关系很好,一直在销售经销商的其他的产品,但却没有销售新产品。如果此类终端都不知道新产品上市信息和销售新产品政策等或没有进货,证明经销商根本就没有推广新产品。如;
某经销商一直抵触说新产品不适合自己的市场,终端店不接受新产品等等,结果企业高层亲自到该市场走访并和终端店沟通,结果在沟通时了解到不是新产品不好卖,而是经销商就没有把新产品的优势和促销政策准确无误的介绍给他们。
八、确保新产品推广员工的奖金制度执行到位
企业在新产品推广初期都会制定推广新产品的特殊政策,如对于销售人员销售新产品提成比销售老产品高,新产品进店有开店奖励等,要确保让经销商的员工知道销售新产品的提成比销售老产品高,新产品进店还有开店奖励。如果经销商的员工不知道到这些激励政策更定不会去推新产品。如:某企业在新产品推广初期针对经销商的员工制定了相应的激励政策。但是经销商在实际推广的过程中把企业的激励政策自己克扣了,使得员工在新产品的推广过程中没有积极性,导致新产品推广迟缓。
“幸福的家庭都是相似的,不幸福的家庭各有各的不幸”。事实证明:要确保新产品成功推广,就必须制定严格的推进计划,并且不折不扣的按照推进步骤去执行。
篇三
1、产品用途
你的工作就是指出目标,团队需要知道他们的目的是什么,目标说明要尽可能的明确,请确保你的内容包括:
*那些问题你要解决,不是解决方案
*谁是目标用户
*细节很多,但是大图片必须清晰
*情景描述
2、产品功能特性
产品需求文档最主要的当然是需求。 具体的需求完全地将取决于您的领域,但是不管你是什么行业,您的产品团队将受益于陈述需求的清楚,毫不含糊的要求,而不是模糊的解决方案。描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验,还需要给工程团队留下足够多的灵活
3、发布标准
发布标准经常是不断变化的,但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如:性能,可测量性,
可靠性,可用性,可控性。
4、时间进度
其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的,你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标,最终完成一个成功的产品。
新产品的产品需求方案文档框架
A、总体说明
1.修订版本
2.产品目标
3.产品受众
4.名词解释
5.其它说明(流程图之类的可以放这里)
B、用例需求部分
1.用例需求1
2.用例需求2
C、用例需求优先级
D、进度表
写好新产品的产品需求方案需要注意的五个方面
1、修订版本,用户需求文档不可能开始就很完美,后期可能会进行多次修订,所以需要记录下,为什么改动,什么时候改动,谁改的。
2、产品目标,让参与这个产品的每一个人知道自己需要朝哪个方向工作。
3、确定产品的受众,让团队知道我们在为什么样的用户做产品。这样团队里每一个人都可以根据自己的理解去发挥自己的想象力。
4、用例需求描述,产品需求文档的核心模块。
5、时间进度与优先级,产品核心功能的实现基础,无论什么企业,资源有限,核心保证核心功能的开发就需要对产品需求文档设置优先级。
扩展阅读
什么是PRD?
该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”,这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
Ⅳ 如何写产品文档,产品文档有哪些流程
在线撰写产品文档越来越成为未来的趋势,使用摹客iDoc,轻松实现产品文档的在线协作、审阅,与原型、线框、高保真的紧密融合。
第一步:创建产品文档
在摹客iDoc 中可以免费创建在线的产品文档,摹客iDoc网址:www.mockplus.com/idoc
第二步:在线撰写产品文档
摹客iDoc 提供强大的产品文档撰写功能,可轻松引用设计稿,并在设计稿更新后自动同步到文档中,修改设计稿不必再次修改文档中引用的设计稿。
第三步:在线审阅产品文档
摹客iDoc 还提供在线评论、审阅产品文档的功能,审阅更及时,也可上传本地文档,支持doc、docx、pdf等格式的文档,工作更高效
Ⅳ 如何写商业需求文档(BRD)
商业需求文档(Business Requirement Document ) 即BRD文档,是基于商业目标或价值所描述的产品需求文档或报告,一般由团队产品总监、产品主管或产品主负责人撰写,主要面向投资者、老板或项目总负责人,解决战略层的问题:“做什么+怎么盈利”,相对更侧重于分析项目的价值和商业模式,产品细节相对较少。
1、产品/项目的背景概述
项目/产品的定位,描述项目并且让BOSS们了解产品的竞争优势和市场价值
2、产品/项目做成什么样子?
产品的核心目标用户、主要架构以及关键的产品路线图,突出“战略壁垒”
3、产品/项目收益、成本和风险分析
项目的收益、成本,ROI分析,项目的风险和对应的解决方案
以下为可参考的内容框架,一般以PPT形式,尽量控制在35P以内,关键突出项目/产品的价值喔:)
1、项目背景
1.1 需求来源与用户需求分析
1.2 市场背景与竞争格局
1.3 商业模式
主要解决问题:为什么要做?
2、项目规划
2.1 产品目标用户群
2.2 产品的核心内容结构
2.3 产品发展的关键路线图(Road Map)
主要解决问题:主要做什么?
3、项目受益、成本与风险分析
3.1 预期收入
3.2 成本预估
3.3 预期风险和解决措施
主要解决问题:这个产品/项目是否值得做?
BRD、MRD 和 PRD文档 之间的区别与联系有哪些?引用李明远老师在知乎的分享:
Ⅵ 如何写一份易用的产品需求文档
产品需求文档分很多种,这里我只说一种让程序员看起来舒服的需求文档格式吧:
作为程序员,在需求文档当中,最关注的内容是哪几种呢?
1、流程:包括业务流程和基本流程;
2、数据:包括输入数据和展示数据;
3、事件流:特别是分支事件流和例外事件流,感觉很多需求文档中,缺少了这部分;
那么,文档的模板是怎么样的呢?
1、需求说明:主要阐述为什么要做这个需求;
2、业务流程:最好使用VISIO来绘制,画出整个业务的流程图,特别是其中所要涉及的判定,分支等,都要画出来,越详细越好;
3、基本流程:继续使用VISIO,画出基本流程即可,一般来说都是业务流程中的最主要部分,但是可以加入更多的细节;
4、分支事件流:VISIO,各种分支事件的详细流程,越详细越好;
5、例外事件流:这里要使用表格,示例如下:主要是系统判定和对应的提示;6、输入数据:用户可以输入数据的字段,已经相应的定义,包括是否必填,字段长度,录入方式,对应规则等;
7、显示数据:页面显示给用户的数据,对应的字段,取数规则,对应规则等;
8、补充说明;这个需求文档模板,更倾向于传统的软件模板,而不是网络上比较流行的AXURE文档。
Ⅶ 产品需求文档模板
首先告诉你产品需求文档肯定是有的!一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板,肯定是已经吸收了各类人的偏好、意见,固化了很多符合实际业务必须的内容要求,能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式,可以让你在编辑文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础,减少额外的沟通成本,提高效率。
不过,在享受别人智力和经验梳理好的模板进行需求编写的同时,还是应该了解模板形成的原因,并在此过程中形成自己对于模板的理解,进而形成对于产品需求文档的理解,在理解中使用,裁剪和优化。
要理解和分析模板,理解和分析产品需求文档,可以运用以下几个方法:
一、描述-解释-预测-监控
描述,是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异,其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉,以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。
解释,是回答 “为什么”,是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机,内容中各部分之间的相关,依存、依赖和影响关系等进行说明,以便对于描述内容有更清晰、更细致、全面的了解。
预测,根据以因果关系为内容的内在联系,相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系,准确地表达内在联系,从中推导出正确的预测。
监控,是对于预测行为、现象的观察和监督,包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生,以及因此而采取的对应的反映动作;这些反映动作是预测过程中根据内在联系制定的“响应”机制,并任其自然发生或者通过提供“系统”的自制能力来实现。
二、需求准备、编写和检查
回归到产品经理的日常工作中,在时间占比上较为集中的就是产品需求管理了,包括了需求的准备、分析、编写和检查过程。在这个过程中,描述——解释——预测——监控这个通用的科学分析过程也同样使用,且可以贯穿其中,并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。
1. 描述
描述的过程是客观的进行“需求向”描述的过程,是一个“背景”信息的补充,用来说明,这个需求文档的源出是什么,是针对什么问题,这个问题是在具体什么领域,在怎样的范围内,涉及到的是那些人;在需求相应的功能设计实现之前,当前的解决方案存在的问题是什么,参与者是怎么解决的,解决的情况怎么样,是好,还是不好,还是勉强可以,对于新的需求的紧迫性是什么样的。此外,描述的过程还需提供一个基础的概念和流程的解释,用来统一作为背景去理解一个现实的业务场景和“沟通字典”,避免在沟通中因为误解而产生不必要的偏差。
需求准备的过程:了解需求来源(管理部门、市场部门、运营部门等),需求背景(行业、同业规则现状等);
需求分析的过程:了解需求目标、预期效果(时间、结果等)、使用者习惯、相关人影响;
需求编写的过程:描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围;
需求检查的过程:需求的背景、目标、过程、干系人、结果预测和预防的完整性检查;
2. 解释
解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题,同时还加入了“是什么”和“怎么样”的部分。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题,这个新的解决方法需要要做什么,对于原有的业务过程有哪些改变,会提升什么,会降低什么,会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分,是需求文档的最主要、最核心的内容部分,也是在内容上占比最大的一部分。
这里的解释根据产品需求面向的要解决的问题不同,而可能存在多个层面,多个维度的层面,比如对于运营的影响,对于前端市场的影响,对于用户的影响,对于财务、法务的影响;从技术开发、技术实现维度,比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响,还可能涉及到对于运维资源的影响等;因此对应到实际的产品需求工作中:
需求准备的过程:了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑;了解面向的内外部用户的产品使用水平、学习能力和使用习惯;
需求分析的过程:选择和制定最有效的,满足时间、资源投入等要求的方案;
需求编写的过程:详细描述需求的业务流程,通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品,产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出;每个业务节点明确的输出物和节点标志,重要性和优先级;系统架构、干系人角色和影响范围;
需求检查的过程:需求的流程、用户交互动作、系统信息交互等完整性检查;
3. 预测与监控
预测与监控在产品需求文档的管理上是联动的,是对于预测的事件发生的时候,进行管理的机制,监控=预测+干预。在产品需求文档的管理上,对于设计好的业务流程、使用功能,在实际过程中可能会出现这样或者那样的 “非规划”的使用,也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品,而且,往往相反。”因此,这部分内容很大的比例需要来对于用户的行为进行预测和监控,并提供“预防”或者“解决”方案。其中:
预防在于,预测产品的用户在使用的过程中,可能会进行的一些超过产品使用半径的操作,一旦进行这些操作,操作的任务流程会中断,掉出,进入其他业务流程中且无法回滚,从而使得操作无法进行下去,功能使用失败,使用者会感觉产品、功能没有包容性,缺乏引导性,导致了最后操作的失败,预想的结果没有实现,而且造成了一定的挫败感,甚至造成了一定的损失。预防的具体方法多采用导航、提示等,不同的系统都有各自标准化的控价,我们在这里不做展开。
解决在于,预测产品的用户在使用产品的过程中,因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下,需要提供额外的流程和控制来“回转”用户的操作,来帮助用户回到预先设定和他所需要的流程上来。解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中:
需求准备的过程:了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度;
需求分析的过程:选择和确定需求实现方案,评估行为管理方式和管理机制;
需求编写的过程:详细描述需求的业务流程和交互过程中可能出现的用户异常操作,相应异常操作中系统反应,系统对应的控制和引导;
需求检查的过程:需求“异常”流程和相应引导、控制地完整性检查;
在需求管理的过程中,就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤,是需求文档内容的组成部分,也是需求编写完成之后的检查。
四个模块构成了需求文档的完整性,且同时有各自独立,有对应的说明,引导、要求和标准。所谓标准文档,就可以按照这四个模块作为框架、内容和格式。
写在最后
产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体,我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认,并最终达成多方理解和共识的产品需求文档,能够最大限度的还原产品、功能的设计,保证产品、功能的实现,最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。
Ⅷ 如何才能写出好的产品文档
一般来说,产品文档分为产品需求文档和产品使用文档两种。产品需求文档主要面向的是产品的开发、设计者,期望是产品的实际开发人员了解产品的细节,让开发完成的产品达到前期设计需求的预期;产品使用文档面向的主要是使用者,使其通过产品文档掌握产品的功能使用,也就是我们常说的产品使用帮助;如果不搞清楚文档面向的对象,往往写出来达不到预想的效果。类似这样专业的文档文案,其实是有一定共通性的;掌握这类文案的写作技巧,尤其对我们IT从业人员来说,是一项非常不错的技能。笔者从业这两年,跟此类文档打过不少交道,在这里跟各位分享一些经验。
1、对象要清楚
开篇就提到了,清楚文档面向的对象的重要性。对于不同的对象,必须使用不同的写作思路来对待,尽可能的站在对方的角度去思考。他需要看到什么?什么内容对他有用?我如何阐述给他?对于产品设计人员,他所需要了解的是产品的样式、界面、交互等情况,对于实际编码人员,他则偏重于产品的可实现性,你的内容则需要偏注产品的功能细节和内部处理。所以,文档面向的对象决定了文档的功能和内容。确定文档面向的对象才能做到有的放矢。
2、条理要清晰
文档的条理清晰不仅让你的文档看起来比较顺畅,更让阅读者能够很清楚的理解。所以,下笔之前就应当知道自己的文档内容大致分为哪几个大的模块、模块下又细分了多少个子模块,然后在大纲的基础上,再进行详细的内容填充。笔者之前的经验,往往在文档下笔之前认真思考了好几天,总希望在下笔之前就希望把所有的问题都想清楚。这对于写作者来说,是一件不好的举动。其实,东西在脑子里转悠,不如在纸上来的直观。大纲列出来之后,然后再来反复的添加、修改,比你按笔不动要来的有效率得多。对于写作来说,最难的也是开始。
3、逻辑要严谨
产品类的文档不同于平常我们书写的文档类型。对于内容叙述的严谨性要求非常严格。因为你的文档不单单是一个你对这个项目、产品的理解,它更是需要做为一个协作的载体让其他的同事同时使用,更可能成为其他同事工作方向的指引。因此,严谨是必须的。所以,在满足了文档条理清楚的前提下,仔细斟酌、思考文档可能会出现歧义、漏缺的部分,反复修改文档成为了一项必须的工作。在大家协调工作的背景下,你一个人不可能将所有的问题都考虑清楚。所以往往出现同事指出你文档中存在的毛病和漏洞。但是你还是应当在前期多做一些考虑,将问题尽量减少。
4、用词要专业
专业的用词不当可以帮助你提升文档的专业度,更可以帮助你提升效率,减少重复和不必要的沟通成本。既然是行业那就需要行业标准,使用专业的行业术语是一种职业化的表现,这样既可以很快和同事达成共识,又让别人觉得你很专业。我想,同事之前这样的协作才是有效率的。当然,对于新手来说,如何掌握专业的用词,这就需要平时多看多读了。多了解小众的博客,多认识一些前辈和朋友,无论是对写作还是对工作的认识,都是很有帮助的。
5、格式要规范
对于一个IT行业从业人员来讲,规范化、流程化的工作模式是非常重要的。对于需要经他人手的文档、或者需要进行存档的文档来说,格式的规范与否是一个衡量你专业化程度高低的重要衡量标准。当然,说到这个规范,你在第一次写作之前就应该了解这个规范是一个什么样的规范。是行业规范?还是公司内部的规范?这取决于你所在公司或所从事项目的情况。对于大公司,你所要做的就是找之前前辈们写过的同类文档进行拜读,了解这些规范。对于小公司或者新创的项目,之前没有过同类产品文档的情况。你所要做的就是沿用标准规范再加上项目特点,尽可能细致的书写。相信,经过你的努力的,你写的文档将会成为该类文档的案例,成为规范。
其实无论是产品需求文档(PRD)、产品策划书还是商业计划书,其实都是需要我们下功夫仔细研究的。毕竟中国互联网发展才十几年,很多细节都还不是很专业。对于一个会思考的互联网人,武装自己的头脑,丰富自己的技能才能找到更好的职业发展。
Ⅸ 如何写互联网产品需求文档
你好,网上有很多产品需求文档的例子,你可以参考一下,大致有以下这些内容:
首先自己要能理解需求,知道具体是要做一个什么样的产品,产品的主要用户是谁,产品有哪些主要的功能
然后你能把这个需求描述给团队其他成员,让他们也能明白这个需求
最后在和团队其他成员沟通的过程中你能解决他们提出的一些问题
产品背景、需求描述、关键词/字、功能结构、功能流程图、页面流转图等
Ⅹ 产品需求文档应该包含哪些内容
我们先假如产品需求文档(PRD)是一个产品,那么该如何做出一个拥有良好用户体验的PRD?
首先先来考察下PRD的用户群体(User Persona):主要是开发人员,在繁忙的开发任务中最希望看到“简洁易懂”的产品需求文档。
梳理下PRD的功能:
传达出产品需求;
管理记录产品迭代过程;
各部门共享产品信息,以促进沟通;
因此一个好的PRD的原则是:
结构清晰
语言简洁易懂
实时共享
具体我们该如何制作?
答案很简单——一个PRD文档即可
现在,越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式,因为之前的word+原型的方式管理起来繁琐,而且还容易产生信息疏漏。
将原型和文本说明统一,直接分享一个链接,开发人员就能看到所有信息,是理想状态。
多级导航结构展示PRD信息
通常来讲,一个产品需求文档里包含“产品概述”、“流程图”、“功能详情和原型”,“全局说明”,“非功能性需求”。
如何把这些内容清晰有条理地呈现在一个文档里呢?使用一个网页般的多级导航结构即可。
产品概述部分用于展示文档修订历史、版本说明、开发周期、和产品介绍。
“文档修订历史”用来记录产品经理对该PRD文档的修改状况,也方便成员能及时了解到PRD是否有改动;
“版本说明”展示上线产品各版本的核心功能;
“开发周期”用于梳理开发、测试、上线的预计开始和结束日期。
“产品介绍”用来记录产品名称、简介、用户画像、使用场景、产品定位等等。
通过墨刀的分享链接还能直接让公司内部人员在线实时同步PRD的更新,不用再担心信息滞后或者文档不兼容问题。
让我们着手开始创建或者优化您的产品需求文档吧~
希望采纳!谢谢!
配图来自 “运维派”以及墨刀官网截图