精华内容
下载资源
问答
  • 产品经理如何写产品白皮书
    千次阅读
    2017-03-30 14:17:18
    

    产品白皮书是产品的必备文档之一,区别于产品简介,白皮书侧重于技术方面。下面介绍一下,本人最近写的一篇产品白皮书的架构,之所以只有架构,因为内容比较敏感,暂不奉上。


    1. 背景 

    在背景中介绍下产品的的必要性,可以根据PEST做分析,所谓PEST,即 Political(政治), Economic(经济), Social(社会) and Technological(科技),得出我们做的产品是很有必要和价值的。
    2. 产品概述 
    2.1. 产品概述 

    可以此处介绍下产品的整体技术架构。
    2.2. 产品硬件及部署模式 
    介绍硬件指标和落地的几种模式。
    3. 产品介绍 
    3.1. 产品功能结构 
    3.1.1. XXX 
    3.1.2. XXX
    3.1.3. XXX
    3.1.4. XXX
    3.1.5. XXX

    此处详细介绍产品各个功能,值得注意的是毕竟产品白皮书是对外的宣传手册,不能泄露核心信息,把握“描述多于定义、定性多于定量”的原则。
    4. 产品特点 
    4.1. xxxx 
    4.2. xxx 
    4.3. xxx

    介绍一些产品的亮点,区别于友商的,能让产品脱颖而出,让客户一目了然。
    5. 客户受益 

    介绍客户有了我们这款产品后有什么不同,起到什么样的效果。

    更多相关内容
  • 任何一款产品最初都来源于一个抽象的想法,这个抽象想法关注的可能只是产品功能,即这款产品能做哪些很酷的事,而不会考虑产品的具体特征,比如尺寸、颜色、电池续航时间等。 在这个阶段,我们通常都会假设它们...

    任何一款产品最初都来源于一个抽象的想法,这个抽象想法关注的可能只是产品的功能,即这款产品能做哪些很酷的事,而不会考虑产品的具体特征,比如尺寸、颜色、电池续航时间等。

    在这个阶段,我们通常都会假设它们都处于最理想的状态,即,尺寸恰到好处,颜色人见人爱,电池可以一直供电等。

    需求计划是把抽象想法转变为产品真实特征的过程,在这个过程中,你需要尽可能早地为这些特征撰写需求,当产品下线后,你碰到意外问题的可能性就会大大降低。

    通常情况下,当产品开发人员对产品的功能有清晰的了解时,就会直接进入设计开发阶段。

    当你拥有早期概念验证原型后,就可以向利益相关者展示你的想法。

    但是,在概念验证阶段之后,如果工程师开始挑选组件并设计原理图,而没有先对功能、行为、操作参数和设备的预期性能进行形式化,就会出现问题。

    什么是产品需求?

    产品需求只是你的设备打算做什么的定义,它是对产品预期功能的正式描述,也就是指产品上市销售之前必须要做到的一组事。

    以卫 Sir 负责过的指纹 U 盘产品为例,其需求大致如下:

    • 具备双分区:一个公共盘区,一个加密盘区;
    • 支持录入指纹、识别指纹的能力。

    在项目开始时,相关人员共同讨论,确定产品必须做到哪些事情,这些事情反映在文档上就形成了需求。

    需求文档主要有以下两个用途:

    1)在产品制造之前,原则上任何人都可以查看产品需求,从中了解产品主要用途以及有关尺寸、重量、可靠性等特征的信息。

    需要注意的是,在产品开发过程中,需求可能会发生变化,随着不断获取新信息,应该经常更新需求。

    需求更新过程应该确保以下几点:

    • 相关人员都要参与,也都会收到变更通知,以便对变化做出相应调整;
    • 考虑每个需求变更给其他需求造成的影响;
    • 考虑每个需求变更对测试造成的影响。

    随着开发的推进,那些“可选”需求和“亮点”需求最终会变成真实的产品特征。同时,测试也需要需求来驱动,明确要测试什么。

    2)产品开发工程师会把需求文档看作一系列指示,用来指导他们应该做什么。在项目最后会对产品进行测试,以确定产品能否上市销售,这种测试主要验证产品需求是否得到落实。

    有关需求计划的术语很多,也很容易让人困惑。你需要区分几个基本概念,包括需求、目标和规格,它们都可以描述产品功能。

    #1 – 需求:是指那些可量化且产品必须做到的事情。

    #2 – 目标:是你要尽量实现的事情,但是很难量化,也不容易做到。

    比如,你对电池续航的需求可能是“连续供电不少于 5 小时”,而你确定的目标可能是 7 小时,这有助于你在产品开发过程中把精力放在那些“有了会更好”的事情上。

    #3 – 规格:是一些可以量化的描述,来自开发过程的某个部分。

    比如,经过测试,你开发的产品(如,蓝牙耳机)满电情况下可以连续可靠地运行 6 个小时,你可以把这一点写在产品的宣传资料和用户手册中。

    那么,此时“充电一次运行 6 小时”就变成了产品规格,它描述的是产品实际能做到什么。

    规格可以变成需求,需求也可以变成规格。比如,如果之前选用的电池停产了,那么你可能会选其他续航时间不低于 6 小时的电池。

    你必须使用技术术语和口语术语,需要尽可能用一句话来描述你的电子产品创意。

    举个例子,下面是你与某位对工程学有所了解的朋友的对话:

    朋友:“你的产品灵感是什么?”

    你:“我喜欢种植自己的辣椒。但是,我经常旅行,所以我不能总是给它们浇水,很多时候也没办法照顾它们。昨晚突发灵感,我可以构建一种可以自动浇水并照顾植物的设备……”

    朋友:“那么你打算如何做呢?”

    你:“我将建立一个用于监视关键参数的盒子(例如。土壤湿度、光照和温度),然后根据植物的需要打开灯或给植物浇水,通过将此设备连接到互联网,我可以远程监控这些参数。”

    从产品的简单描述中,你已经可以提取一些功能要求,例如,感知土壤湿度、环境光和温度的能力。

    需求是描述产品应该做什么,而不是产品如何做的结构化语句。

    为什么需求有用?

    需求不仅仅是公司用来确保其设计团队履行设计开发任务的正式文书,而且对于设计工程师和项目经理来说都是非常有用和必要的工作指南,它们可以为你节省金钱和额外的工作。

    通过正确分类和定义电子产品的功能、特性、属性和约束,你可以更清晰地了解实际需要设计的内容。

    此外,需求还允许你分离和模块化管理产品功能,以便可以让研发设计人员自行研究和实现它们。

    在一个有多个人工作的项目中,拥有定义了所有功能,属性和约束的需求文档非常有用,可以清晰定义所需开发的内容。

    对于项目经理或团队负责人而言,产品功能和技术需求的结构分解可用于为团队设置任务,或使用甘特图等工具跟踪项目。

    一旦成功满足所有产品要求,它也可以充当交付里程碑,以指示该项目已完成。

    最后一点,良好的需求计划可以减少产品开发风险,即尽早确定并解决问题,而不是把问题拖到以后再去解决,那样付出的成本就太大了。

    来看一个简单但常见的产品开发失败的例子:由于需求缺失导致产品开发失败

    假设销售人员头脑里有了一个想法,他们想把装有嵌入式软件的新产品最先在国内发布,之后在欧洲发布。

    但是,他们并没有把这个想法以需求的形式告知软硬件开发者,这会造成什么后果呢?

    如果你在产品开发早期忽视了产品的国际化问题,直到产品开发快结束才意识到,就很有可能会出现以下一些不良后果。

    1)所选的软件平台,如,操作系统,可能过于精简,以至于无法轻松地通过语言包来更换文字界面。

    在根据用户语言更换不同的文本文件时,软件平台也没有提供任何内置方法。在这种情况下,开发者需要为每种语言手动构建新的显示布局,这会大大增加产品开发和测试的工作量。

    2)产品可能把一些用户数据通过互联网集中存到了某个中心数据库。

    由于不同国家有关数据安全的法律不同,后端数据库可能需要重新设计架构,重新开发,以确保从各国收集的重要个人数据只存储在相应国家的数据中心。

    需求的类型

    需求可以通过许多不同的方式进行分类,但是有两种主要类型:

    • 功能需求:系统应该执行或提供的功能;
    • 非功能性需求:指产品必须具备的某些属性或质量要求,即系统必须满足的条件或系统运行的约束。

    例如,移动电源具有测量电池温度的功能需求,并且具有能够在 0 到 40 摄氏度的温度范围内工作的非功能需求。

    需求必须遵循一些规则和结构:

    #1 – 独特的

    需求是其本身的实体,不能是两个或多个需求的组合。

    #2 – 明确的

    需求的所有读者应该对需求的内容有相同的理解,只能有一种解释。

    #3 – 可验证的

    如果不能正确验证需求,那么工程师将如何确定他们已满足需求呢?

    通常,你将进行内部验证,测试工程师会进行测量以检查硬件是否正常运行并符合其设计规格和要求。

    然后进行设计验证,在该测试中,将对产品的外壳,不同温度和湿度条件下进行更严格的测试,该验证阶段还包括 EMC 测试。

    最后,该产品将在实际操作条件下进行现场测试,或者将其集成到更大的系统中,或者使其与其他设备进行交互。

    #4 – 属性

    应该给需求赋予属性以支持前面提到的规则要求:

    • 标题:需求的描述性标题;
    • ID:不能重复的唯一标识;
    • 与安全相关:在某些安全性很重要的产品中,将需求分类为与安全相关是一种良好做法;
    • 优先级:在某些情况下,无法实现所有需求,因为它们会相互冲突。分配优先级可为设计人员提供信息,以选择最相关的需求;
    • 来源:这是指需求的来源,是客户,承包商还是外部的;
    • 理由/目的:对需求及其存在原因的简短描述;
    • 验证方法:该需求将如何验证、测试和分析;
    • 跟踪信息:需求必须是可追溯的。

    通常情况下,在产品需求完成之前可能会修改原产品需求的 50% 以上的内容,例如,可能会突然出现需要结合新技术或者新法规的情况,这会迫使你更改设计。

    需求变更需要由需求工程师,系统工程师或项目经理解决和管理,一般情况下,工程师可以使用工具或软件来寻求帮助。

    需求工具可以自动化并保留可追溯性和历史更改的记录,同时支持需求验证结果的记录。

    管理新出现的需求也很重要,这些需求仅在系统组合在一起时出现,很难预见,必须在其它需求的基础背景下分配它们,以避免孤立需求。

    # 5 – 电子产品的需求文档

    电子产品的需求文档没有单一的格式,每个设备都有其自己的规格和特殊性,当然,大多数电子产品可以遵循以下需求类别:

    • 产品说明:产品的一般高级描述,最好附有系统级框图;
    • 设计要求:产品在组件和设计方面需要具备的功能;
    • 功能要求:产品要执行的功能;
    • 环境和功能性环境要求:与对环境的影响及其在何处执行功能有关;
    • 机械要求:外壳相关要求;
    • 使用寿命要求:工作时间和工作温度;
    • 测试要求:产品需要通过的相关测试。

    如何写出好的需求?

    产品需求既能成就产品,也能毁掉产品。那么你如何才能写出好的需求呢?

    #1 – 产品需求是设计的约束

    一方面,产品需求是技术人员要实现的目标;另一方面,它也是设计的约束条件,因为它排除了产品的其他呈现方式。

    例如,你喜欢在设备中使用可更换电池,比如,5 号电池。

    它们个头小,价格低,又能提供足够的电能。与那些采用可充电电池供电的设备相比,如果可更换电池设备的电量用尽,可以轻松更换新电池,让设备立即运行,而不必找插座去充电。

    你可以买很多 5 号电池备用,着急的时候,你可以去任何一家超市或便利店买一次性电池来用。

    如果要你为一款便携式产品写需求,你可能加上这样一条需求,“必须使用可更换的 5 号电池供电”。

    但是,这个看似简单的需求会给设计带来如下诸多影响,这个需求限定了产品的最小尺寸,产品必须装得下电池,产品外壳必须设计有电池仓盖,电池仓内部要有相应装置供电池装载,这些都会增加设计时间。

    如果电池仓盖合上时不用螺丝,而采用扣紧的方式,那么可选用的外壳材料也可能会受限,可选用的成型工艺也会受限。

    这个需求会影响产品的机械架构,电池需要放置在靠近外壳的地方,以便于更换,而这可能会导致一些元件布局方式无法实现,比如,某些布局可以有效地减小产品尺寸、提高散热效率等。

    在某些场景下,确实需要指定电池类型,必须保证可以更换电池。例如,相机或其他高耗电的便携产品。

    但是,除非你真的觉得更换电池这项功能非常重要,否则最好不要把能够更换电池写进需求里。

    以便设计师设计电源时满足那些真正对产品至关重要的需求,比如产品尺寸、重量、电池续航时间等。

    编写需求时,要认真提要求,只提那些真正重要的内容,让设计师在这些约束下发挥创造力,创造出更好的产品。

    #2 – 需求必须是可测试的

    好需求的显著标志之一就是意思清晰、不含糊。这样的需求得到满足时,应该不会有人提出任何异议,需求应该是可测试的。

    “这款产品应该是安全的”这类说法在很大程度上只是反映了我们的美好愿望,它太过笼统,不能算作产品需求。

    “安全”由谁定义?如何测试产品是否安全?你如果想把上述说法换成标准的产品需求,应该修改成这样:这款产品要符合目标销售地区的所有安全法规。

    这样一来,定义“安全”的担子就转移到了监管部门,这样做是有意义的,因为你需要满足法律法规的要求。

    比如有一款便携产品,使用时人们主要把它放在口袋里。为此,你编写了这样一个需求,“这款产品应该适合装在口袋里”。

    然而,口袋形状各异,尺寸也不一样,既有衬衫上的小口袋,也有工作服上的大口袋,口袋是各种各样的,上述需求就模糊不清了。

    你可以为该产品估计一个大致的尺寸,使之适合装入大多数口袋,比如:“这款产品的尺寸应该不超过 8 cm×10 cm×2 cm。”

    虽然这样做可能会导致产品尺寸过大或过小,但是设计师至少有了设计依据可参照。

    另外,还有一种方法,可以为产品编写合适的尺寸需求,即从用户角度去描述它,比如“经过测试,在目标市场中有 90% 的用户认为这款产品应该很容易装进他们的口袋里”。

    这就是一个“好的需求”,因为归根结底,所谓的“好”与“不好”,都是用户对产品的看法,而不是你对产品的看法。

    像这样一个需求还蕴含着其他细节,比如产品应该可以很轻松地放入或拿出口袋。

    从不利的方面看,要测试是否实现了这个需求,需要召集一大群人,让他们亲身体验产品,然后询问他们的使用体验,这远比拿把尺子来测量要费力得多。

    #3 – 需求是以接口为中心的

    本质上,产品就是一组接口,这些接口与外部世界相通,产品内部“填充”着让这些接口正常工作的“东西”。

    产品需求应该主要关注产品和外部世界之间的接口:

    • 产品和用户之间的接口,如,用户界面;
    • 产品和其他产品之间的接口,如,USB 端口、互联网服务等 。

    与接口有关的需求一般是指你想让产品做什么,而与产品内部“填充物”有关的需求是指你如何让产品做它应该做的事情。

    大部分需求是前一种,后一种需求通常用来告诉设计师和开发者如何去做自己的工作,这是他们需要做的事,编写需求应该尽量围绕你想让产品做的事情展开。

    提前把人机接口需求做完美相当困难,与人机界面一样,在产品开发过程中,物物接口也需要早做测试。

    有些接口更容易指定。例如,如果你的产品通过蓝牙和计算机通信,那么蓝牙接口要统一好。但是,如果上升到蓝牙通信内容这个层面,问题会变得更复杂,复杂程度取决于通信的内容。

    在蓝牙通信中,有些类型的数据是有固定标准的,比如耳机和手机、音乐播放器和无线音箱等。

    但是,如果标准蓝牙接口规范不支持传送的数据,你就需要重新自定义高层数据格式和协议,以便发送方和接收方能够相互理解。

    其他“标准”接口的标准化也存在很大差异。例如,类似于蓝牙,USB 这个通信“管道”也支持某些高层接口定义,在某些使用场景中对传送的信息进行解释和标准化,比如键盘、鼠标、游戏控制器、大容量存储器等。

    但是,即便产品的 USB 通信符合其中一个场景,从供电和耗电来说,USB 设备还是非常复杂的。

    电力标准有很多种,许多USB 设备遵守这些标准。对产品中所有使用 USB 与任何其他设备连接的接口尽早进行测试。

    你从零开始对任何接口所提出的初始需求,比如内部子系统之间的接口需求,很有可能是不完整、有歧义的,甚至是完全错误的。

    接口设计是一门技术活儿,除非你先前设计过并且投产过非常相似的接口,否则,一般会或多或少出一些岔子。

    在开始开发产品之前,合理提出这些需求是非常重要的。此外,还应尽早为测试子系统做好规定,并随着开发推进更新规定。

    在项目刚开始时忽视需求的做法是愚蠢的,但是那种一开始就认为自己完全能够做出完美需求的想法也好不到哪儿去。

    随着产品开发的进展以及将产品暴露给外界,原来的产品需求会发生变化。因此,你要尽早并经常向外界暴露产品,以此完善需求。

    结论

    需求代表了工程师要实现的一组设计目标,并且代表了管理人员评估成本和项目时间的一种方式。

    还需要使用工具来适当地管理需求,特别是在项目规模大且许多人都在使用它的情况下。

    就一款产品来说,确定需求细节看似简单,实际上却并非如此。

    花时间做需求计划可能要比实际实现需求更痛苦,不过有一点可以确认:在需求计划上花费的每一秒,都会为以后实现需求省下大量时间。

    这一点对于硬件产品来说尤为重要,因为电路或机械部件的调整往往需要耗费几周甚至几个月的时间。

    在开发之前,先把所有细节整理好有助于避免以后反复修改,这可以为整个项目节省大量时间和支出。

    #专栏作家#

    卫Sir,公众号:简一商业,人人都是产品经理专栏作家。关注智能硬件领域,擅长市场分析、产品设计开发、生产管理等,喜欢阅读和爬山。

    展开全文
  • c51特殊功能寄存器定义及作用

    千次阅读 2021-05-22 04:05:33
    在新的MCS-51系列产品中,SFR在功能上经常组合为16位值,当SFR的高字节地址直接位于低字节之后时,对16位SFR的值可以直接进行访问。例如52子系列的定时器/计数器2就是这种情况。为了有效地访问这类SFR,可使用...

    单片机C51语言是由C语言继承而来的。和C语言不同的是,C51语言运行于单片机平台,而C语言则运行于普通的桌面平台。C51语言具有C语言结构清晰的优点,便于学习,同时具有汇编语言的硬件操作能力。对于具有C语言编程基础的读者,能够轻松地掌握单片机C51语言的程序设计。

    c51主要特点

    单片机C51语言兼备高级语言与低级语言的优点。

    语法结构和标准C语言基本一致,语言简洁,便于学习。

    2f348e6006a5252c14385db3f8568ee3.png

    单片机C51实验板

    运行于单片机平台,支持的微处理器种类繁多,可移植性好。对于兼容的8051系列单片机,只要将一个硬件型号下的程序稍加修改,甚至不加改变,就可移植到另一个不同型号的单片机中运行。

    具有高级语言的特点,尽量减少底层硬件寄存器的操作。

    单片机C51语言提供了完备的数据类型、运算符及函数供使用。

    C51语言是一种结构化程序设计语言,可以使用一对花括号“{}”将一系列语句组合成一个复合语句,程序结构清晰明了。

    C51语言代码执行的效率方面十分接近汇编语言,且比汇编语言的程序易于理解,便于代码共享。

    “Hello world”程序

    c51特殊功能寄存器定义与作用

    在开始讲对C51单片机中特殊寄存器(SPR)的定义前,先简单介绍下我们在进行51单片机开发时经常看到的两个关键字“sbit”和”sfr“:

    sfr用于将一个单片机的特殊功能寄存器(specialfuncTIonregister)赋值给一个变量,这样在后面的程序中就可以中这个变量指引(referto)该寄存器

    sbit与sfr用法类似,只是sbit是位操作,用于将某个sfr中具体位赋值给一个变量,这样后面程序就可用通过该变量为该位清0或置1。

    接着我们以STC系列的51单片机为例简单的了解下单片机的特殊功能寄存器布局,如下:

    b8d5f190cf22447bef686f068bc71350.png

    MCS-51单片机中,除了程序计数器PC和4组工作寄存器组外,其它所有的寄存器均为特殊功能寄存器(SPR),分散在片内RAM区的高128字节中,地址范围为80H~0FFH。SFR中有11个寄存器具有位寻址能力,它们的字节地址都能被8整除,即字节地址是以8或0为尾数的。

    为了能直接访问这些SPR,FranklinC51提供了一种自主形式的定义方法,这种定义方法与标准C语言不兼容,只适合与对MCS-51系列单片机进行C语言编程,特殊的能寄存器C51定义的一般语法格式如下:

    sfrsfr-name=intconstant;

    “sfr”是定义语句的关键字,其后必须跟一个MSC-51单片机真实存在的特殊功能寄存器名,“=”后面必须是一个整型常数,不允许带有运算符的表达式,是特殊功能寄存器“sfr-name”的字节地址,这个常数值的范围必须在SFR地址范围内,位于0x80~0xFF。

    例如:

    sfrSCON=0x98;    /* 串口控制寄存在器地址98H*/

    sfrTMOD=0x89;   /*定时器/计数器方式控制寄存器地址89H*/

    MCS-51系列单片机的特殊功能寄存器的数量与类型不尽相同,因此建议将所有特殊的“sfr”定义放入一个头文件中,该文件应包括MCS-51单片机系列机型中的SFR定义。C51编译器的“reg51.h”头文件是这样一个文件。

    在新的MCS-51系列产品中,SFR在功能上经常组合为16位值,当SFR的高字节地址直接位于低字节之后时,对16位SFR的值可以直接进行访问。例如52子系列的定时器/计数器2就是这种情况。为了有效地访问这类SFR,可使用关键字“sfr16”来定义,其定义语句的语法格式与8位SFR相同,只是“=”后面的地址必须用16位于的SFR的低字节地址,即低字节地址作为“sfr16”的定义地址。例如:

    sfr16T2=0xCC/*定时器/计数器2;T2低8位地址为0CCH,T2高8位地址为0CDH*/

    这种定义适用于所有的新的16位SFR,但不能用于定时器/计数器0和1。

    对于位寻址的SFR中的位,C51的扩充功能支持特殊位的定义,像SFR一样不与标准C兼容,使用“sbit” 来定义位寻址单元。

    定义语句的一般语法格式有如下三种:

    第一种格式:sbitbit-name=sfr-name^intconstant ;

    “sbit”是定义语句的关键字,后跟一个寻址位符号名(该位符号名必须是MCS-51单片机中规定的位名称),“=”后的“sfr=name”中的位号,必须是0~7范围中的数。例如:

    sfrPSW=0Xd0;   /*定义PSW予寄存器地址为D0H*/

    sfrOV=PSW^2;   /*定义OV位为PSW.2,地址为D2H/*

    sfrCY=PSW^7;   /*定义CY位为PSW.7 地址为D7H^*/

    第二种格式:sbitbit-name=intconstant^intconstant;

    “=”后的intconstant为寻址地址们所在的特殊功能寄存器的字节地址,“^” 符号后的intconstant为寻址位在特殊功能寄存器中的位号。例如:

    sbitOV=0Xd0^2; /*定义OV位地址是D0H字节中的第2位*/

    sbitCY=0XD0^7; /*定义CY位地址是D0H字节中的第7位*/

    第三种格式:sbitbit-name=intconstant;

    “=”后的intconstant为寻址位的绝对地址。例如:

    sbitOV=0XD2;    /*定义OV位地址为D2H*/

    sbitOY=0XD7;    /*定义CY位地址为D7H*/

    特殊功能位代表了一个独立的定义类,不能与其它位定义和位域互换。

    了解完了关于特殊功能寄存器的定义,有人又会产生疑问:

    我们用sfrP0=0&TImes;80表示P0,用sfrSP=0&TImes;81表示SP,这个没有歧义。但有疑问的是:假如用sbitP0_1=0&TImes;81表示P0口的第一位,那么我想表示SP寄存器的第0位怎么办呢?如果也是定义成sbitSP_0=0×81那么明显会有二义性,编译器理解不了。其实这个问题是不存在的,从图1中可以看出,SPR又可以分为两个区域:可位寻址区和不可位寻址区。可位寻址区的寄存器地址能够被8整除,而不可位寻址区的寄存器地址不满足这一要求。因此例子中的sbitSP_0=0×81对于SP寄存器这是无效的应该写成sfrSP=0x81。

    例如:sbitP1^1=0x81;sfrSP=0x81;

    它们虽然都引用了同一个地址0×81,但是对于编译器来说,这两者的含义完全不同,前者因为有sfr关键字,所以是字节地址。后者因为是sbit关键字,所以是位寻址,表示的是一个bit。

    展开全文
  • 产品经理如何PRD文档[最全]

    万次阅读 2019-04-29 09:06:47
    做好产品需求文档的这十步,是...你做的是一个让人无可争议的产品,为了做好他,你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析...

    做好产品需求文档的这十步,是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面,但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

    第一步:做好准备工作

    你要做的是一个让人无可争议的产品,为了做好他,你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

    建立良好的交流也非常重要,它会影响着产品团队。如果你的准备工作做的够好,你也会变得越来越有信心和说服力。

    第二步:确定产品的目的

    任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求,你的产品如何达到这个需求。

    产品经理需要提出一个清晰、简明的价值主张,让它很容易被接受,要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单,但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO,他问你产品的意图是什么,你能在电梯到达之前回答这个问题吗?如果不能,你就还有工作需要做。也许是你的说明没有针对性,他可能表现出来和其他产品做的没有什么明显区别;也许你提出的观点不能和你的用户产生共鸣;也许你解决的是一个非常规的问题,可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节,从某些方面来说,一个有价值的观点应当是越简越好。

    产品需求需要确切的指出这个产品发布的目标,同样的这个目标也有优先之分。例如,你的目标可能是:1)易用,2)零售价不足$100,3)和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目,你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性,也测算出可用性问题的严重程度,同样你可以说明没有重大的可用性问题。

    这里的关键就是让每个人都知道产品成功的时候是什么样,还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

    第三步:确定用户原型、用户目标和用户任务

    现在你已经明白你想要解决什么问题,下接下来就要深入了解目标用户和顾客,在这步中,和你的PD(产品设计)紧密联系非常重要。

    用户原型

    在这个阶段,PM需要和很多用户交流,需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类,然后决定那一类是我们的首要用户。

    比如你正在做一个像eBay一样的互联网拍卖服务,你同时拥有买家和卖家,在这之中还有使用频率少的用户和经常使用的用户,不难想象还有个别特殊的用户,比如团体公司采购者。

    PM(产品经理)和PD(产品设计)需要首先确定类型是最重要的,然后尽量对这个用户群的特征进行详细的描述,以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想像的,但是应该是典型的、可行的和真实的,让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。

    举个例子:

    “里昂是一个超级卖家,46岁,男性,居住在Fresno,经营小型摩托车配件。虽然他开着一个小店,但是他的生意大部分来自Ebay,每个月平均有400多次交易。他出售的东西品种非常多,但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷,还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。

    里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。里昂已经在Ebay上销售产品已经三年了,他学会了在ebay应该掌握的东西,他非常自豪的拥有超过5000的信用度。如果Ebay更改了网站,特别是销售的过程方面,对于他来说改变习惯、学习这些变更是非常困难的。 里昂已经形成了自己的习惯,星期一列出销售的商品,星期五拍卖结束,设法让在收到货款的几个小时内出货。”

    但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时,我就要问问自己里昂会是什么发应,为了让他能顺利的使用这个功能我们需要做什么。

    注意缩小范围,让他仅仅描绘必不可少的。满足所有人是徒劳的,通常最后没人会满意,所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样,如果你不去精确的定位你的目标用户,你就只会存在模糊的概念,你会发现理解你用户的反应非常困难。你要倾向于设想,让你能更像你的用户。

    用户目标(用户意愿)

    一旦我们确定并描绘了我们主要的用户类型,我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单,但是解开根本问题是非常具有挑战性的,特别当你周围的人告诉你你已经解决了他们想要的。

    从CEO、销售代表、工程师到客户,每个人都太兴奋而不能帮助你找到解决根本问题的办法,他们会告诉你在某个地方添加一个快捷按钮,或则添加一个功能仅仅是因为竞争对手有,或则是改变成他们喜欢的颜色。

    最好的解决办法取决于清晰的了解到底什么问题需要解决,每个用户模型可能有不同的目的,需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。

    用户任务(tasks,用户为达到目标使用产品而需要做的任务)

    掌握了用户原型与他们的目标愿望,我们就开始着手设计任务来满足他们的目标意愿,这是产品制作进程中最核心的部分,也是创造力和创新力被激发的地方。

    许多优秀的产品仅是用更好更新的办法解决一个已有的问题,有时候这种办法仅仅是应用一个种新技术,但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo(美国市场占有率第一的数字录像机)在电视节目录制的老问题上面想出一个全新的办法,让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

    注意我们虽然谈到了目标和任务但是还没有谈到具体的功能,这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。

    以“必须功能”这个理由可以排除很多功能。讽刺的是,你用越少的功能,你的产品被发现得越来越强大。这是因为产品的功能越少,你的用户就会发现并使用更多的功能,成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的,我们大多数人都不能和我们的用户一样,我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

    第四步:定义产品原则

    现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡,为你的产品标准作出最佳的决定是非常重要的。

    在大多数的产品团队中,每个成员都有做好产品的原则,但很少有两个人有同样的想法,这些差异都会导致不可思议的结果。

    尝试和制订一系列指导整个团队的产品原则是非常有价值的,这些原则需要具体到域名和项目。

    用TiVo举例,在产品团队工作开始时,以下这些产品规范就被建立,并在团队里传达:

    1.它是娱乐的

    2.一个傻瓜式的电视

    3.一个该死的视频设备

    4.平滑柔顺的

    5.没有模式和深层次

    6.尊重观众的隐私权

    7.像电视一样强大

    这些规范很大的影响到产品的定义而且在很大程度上加大了难度,但是他们确实是成功产品的来源。比如易趣的口号就是:1、易于使用 2、安全 3、有趣

    它将在该项目中,在面对众多问题而作出决定的时候进行指南.

    第五步:产品原型和检验

    这是一个拿出你想法的阶段,创造力和创新力拿出成就的地方.

    很多人都容易犯一个常见的错误,他们对产品设计规范太有信心,结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候,所以才会有许多首次发布的产品离目标太远。

    对于许多产品来说,这个时候你可以用大量的原型做很多的实验。首先,下面的三个非常重要的测试你可能需要做

    可行性测试

    一个直接的问题就是产品是否可以开发,你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的,但是有其他的办法可行是非常有希望的。

    工程师会发现在产品的某个阶段不可能逾越,现在知道比以后知道要好。

    可用性测试

    产品设计师将要和你紧密工作共同提出产品功能,让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求,同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试,从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用,但是实际是没有人能取代真实的目标用户。

    概念测试(Product Concept Testing)

    光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。

    对于一部份小产品,您的想法写在纸就足够了,但是对于多数产品,为了预计产品是否达到目标,复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。

    原型也许是一个物理设备,或者它也许是软件产品的一个预览版本。关键是它需要足够现实,您能用原型在实际目标顾客身上测试,并且他们可以给您质量反馈。

    以前做原型主要有两个障碍。第一是缺乏良好的原型工具,需要花费很多的时间制作原型;另一个是管理方不知道原型和真实产品的区别,在不可预计的情况下,按照最终产品来要求原型。

    今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型,可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样。

    在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始,作出重要的变动会变得非常困难,花费也会变得很高。

    第六步:验证和质疑

    当你认为你弄懂了你需要解决的问题,现在是时候开始验证和质疑假设。

    假设甚至当作不知道是很容易的,但是切勿把不可知的结论当作指引,那会妨碍你获得成功。天文学最初定义是研究太阳和其他行星如何围绕自己转,本身的定义就是一个臆断,反而阻止人们获得真相。

    第七步:写

    当然你需要把这些都写下来,大多数的PRD都是word文档,但也有一些是帮助文档,PowerPoint,或则写在白纸上。当然用什么格式不是很重要,重要的是让团队成功能轻松的看懂,不会遗漏,还有就是PRD可以随着项目开发而更新。

    记住对话是两个人之间的,但是PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的,所以不必担心要有什么漂亮的外观、PRD写的有多厚,只要它是可读的、可理解的、是需要的内容。

    PRD文档主要有四个部份组成

    产品用途

    你的工作就是指出目标,团队需要知道他们的目的是什么,目标说明要尽可能的明确,请确保你的内容包括:

    *那些问题你要解决,不是解决方案

    *谁是目标用户

    *细节很多,但是大图片必须清晰

    *情景描述

    多开展集思广益的会议和临时口头的讨论,从而更好的写出来,更会让团队深入了解。

    产品功能特性

    产品需求文档最主要的当然是需求。 具体的需求完全地将取决于您的领域,但是不管你是什么行业,您的产品团队将受益于陈述需求的清楚,毫不含糊的要求,而不是模糊的解决方案。

    描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验,还需要给工程团队留下足够多的灵活自主空间。

    同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”,对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的,如果某人决定削减要求,想要深入了解就会非常困难。 从要求到目的明确说明将会是文档更加清晰。

    发布标准

    发布标准经常是不断变化的,但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如:性能,可测量性,可靠性,可用性,可控性。

    时间进度

    其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的,你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标,最终完成一个成功的产品。

    第八步 优先级

    除了明确的要求,对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理,如果他们给予优先级,一般都是表明要求是否是“必须有, “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的,不可掉以轻心。

    产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”,这些标注“必须拥有”的功能直接反应出产品的核心价值。

    “重要”的分类也很重要,在产品销售前只要有机会就要满足这些功能。

    “希望拥有”产品团队也应该注意到,即使大多数也都没有实现,在未来版本也适当的慢慢实现。

    这些有时候是不够的,从1到n每一个分类优先排序都是很重要的。有几个原因:

    首先,上市时间总是被关注,并且日程表经常下降,您说不定被迫使削减有些特点为了尽快进入市场。 你也不想产品团队先开发简单的功能而放松重要的功能,导致最后客户使用的关键功能还没完成。

    其次,在产品设计和开发阶段,团队将会发现更多的问题产生并解决这些问题,所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。

    这点就是说产品经理如何不给出优先级和重要等级,其他相关较少的因素也会跟着无法确定。

    整个PRD是一个不断完善和思维提高的过程,明朗锐利就是可以成功的产品的,模糊就是失败的产品。在争论最激烈的时候也能容易做决定,并且帮助工程师做出计划。

    第九步 测试完整性

    现在你有一个PRD草稿,你需要测试它的完整性。工程师是否可以充分了解并达到目标?OA Team(质量管理团队)是否有足够的信息来做出测试计划,是否可以开始做案例?

    当投资人或相关人审核了PRD,确定了各个需要说明的方面,所有的问题得到解决,现在你就可以按PRD进行产品开发。

    第十步 管理产品

    在产品实施期间,就算是最好PRD,也有不计其数的问题被解决。解决所有PRD中存在问题,如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。

    如果你做了你的工作并准备记录在PRD,项目审查就会变得非常简单,因为任何一个部份都历历在目。

    记住PRD是一个“活”的文件,在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西,如果你认为是必要的就在PRD中写进。

    本文大体已经结束,全面的阐述一个PRD的产生和管理过程,感谢SVPG的分享。

    PRD模版 可以关注 公众号 痞M二点五 输入 产品 获取 公众号 会每周定期分享大厂内容

    展开全文
  • python中定义

    千次阅读 2020-11-23 19:49:05
    广告关闭腾讯云11.11云上盛惠 ,精选热门产品助力上云,云服务器首年88元起,买的越多返的越多,最高返5000元!什么是宏? 宏类似python中的函数,可以传参数进去,但不能有返回值! 在实际开发项目中,可以将一些...
  • 万字长文|如何定义“失败的产品经理”

    万次阅读 多人点赞 2020-05-23 22:27:56
    前言:总有一种错觉,别人家的产品经理都是神一样,动不动改变世界的那种。就没有失败的产品经理吗? 提出问题的背景 前阵子刚刚和阿里、百度的产品经理聊过产品这块,总结输出了《腾讯产品流程》和...
  • python定义变量

    千次阅读 2020-11-20 20:14:22
    python变量的定义 功能:存储数据、被调用、标识数据(变量数据存储在内存里,数据是临时的)name = abc#name:变量名abc:变量name的值 print (name) #调用name变量,并打印变量 重点注意: python中字符带单引号...
  • 如何定义需求的优先级也是挺能看出产品经理的能力水平的,在上一节已经详细阐述了评估哪些需求该做,哪些需求不该做,对于已经决定做的需求,这样的需求数量很多,是现在做,还是以后做,不可能在同一时间内全部...
  • 产品需求文档(PRD)对每个产品经理来说都不陌生,它是产品项目由"概念化"阶段进入到"...可以理解为,PRD是产品经理关于产品功能的宣导和传达,它通过清晰扼要的表述将产品意图呈...
  • 一只产品小白,最近在总结过去的产品实习过程中的相关资料,故此文。 本文主要目的在沉淀产品经理日常工作中撰写产品需求文档的通用方法。 一、产品需求文档是什么 在日常的工作中,产品经理需要针对特定需求...
  • 当把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时,战略就变成了范围 一、范围层定义 定义项目范围包括两件事: 这个过程是有价值的 ——过程的价值在于: 当整个事情还处于假设阶段的时候,它...
  • 产品思维设计API(三)——版本控制,没有你想的这么简单前言 最近公司内部在重构项目代码,包括API方向的重构,期间遇到了很多的问题,不由得让我重新思考了下。 - 一个优雅的API该如何设计? - 前后端分离...
  • 项目范围管理:范围定义

    千次阅读 2020-07-28 11:43:34
    定义范围是制定项目和产品详细描述的过程。 定义范围的主要作用是:明确所收集的需求哪些将包括在项目范围内,哪些将排除在项目范围外,从而明确项目、服务或输出的边界。 范围定义的内容和作用:由于在收集需求...
  • 产品经理主要有两项职责:①评估产品机会 ② 定义要开发的产品;前者我们在上篇的《如何获得产品立项》文章中已经大致介绍过;而定义开发的产品则需要通过产品需求文档(PRD)来描述产品的特征和功能。本篇主要分享下...
  • 产品需求文档(PRD)到底怎么

    千次阅读 2015-09-28 09:12:15
    产品经常会PRD,但是如果没有一套完整的写作思路和框架,出的PRD质量就不会太好,导致遗漏重要信息,在项目过程中被开发、前端、测试吐槽。趁这个周末有空,来梳理下一下PRD的逻辑。 一、什么是PRD? PRD...
  • 软件工程定义

    千次阅读 2019-04-01 21:09:25
    产品为多个不同用户提供不同功能。 6、Web应用 是一类以网络为中心的软件 随着Web2.0的出现,网络应用正在发展为复杂的计算环境,不仅为最终用户提供独立的特性、计算功能和内容信息,还和数据库和商务应用程序...
  • 高科技公司的 CEO 要写代码吗?

    万次阅读 多人点赞 2020-09-01 17:44:58
    导读:周末与一老朋友相聚,聊起创业,聊起涛思数据,他说,"老陶,看你朋友圈,经常看到你在程序,你应该是在作秀吧,涛思数据融资都超过2000万美元,你这个创始人不太可能也不需要敲...
  • 怎么写产品分析报告

    千次阅读 2018-04-11 11:23:24
     范围层:规格功能,某个功能是否应该成为这个产品功能之一,各种功能的组合方式是什么样的。 结构层:流程结构,用户如何达到某个页面,并且它们走完流程之后能去哪儿。 框架层:页面布局,按钮,表格和文本...
  • java 项目需求文档怎么

    千次阅读 2021-02-12 15:24:02
    传达产品开发需求;保证团队成员沟通顺畅;制定产品质量控制标准。产品需求文档的在项目中的重要性已经不言而喻。那么对于产品经理来说,有哪些技巧可以更好地完成产品需求文档的撰写呢?产品需求文档包含哪些内容?...
  • 源代码在最下方 工具/材料 电脑 C++编译器 操作方法 01 首先,先把头文件和类的基本框架上去 02 然后,我们来做第一个要求,创立基本成员length,width,height,这里设置了double型,其他类型也可以。 03 接着,...
  • 有的认为还需要简单自测一下,确保功能能跑通;还有的认为需要把自动化用例完并测试通过。 为了避免这个问题,在敏捷软件开发中,常用Definition of Done“完成的定义”来表示工作是否已完成,不同的活动有不同的...
  • Android中如何优雅的定义常量

    万次阅读 2018-08-04 11:26:17
    在Android开发中如何更好的定义常量 本篇博客是笔者的第一篇博客,其实很早之前就有了博客的想法,但是奈何万事开头难,一直没有下定决心,随着自己经验的增加,有些知识会经常遗忘,对于某些难题,可能当时有了...
  • SDS(Software Defined Storage)即软件定义存储,简单地说就是将存储硬件和软件进行分离,采用标准化硬件作为载体(如X86架构),基于软件实现企业级存储功能和服务。相对于传统存储硬件盒子,SDS中存储软件成为了...
  • 从最先开始的需求调研,到最后的产品成型,自己亲自过手的需求报告大概也有十来篇了,与高层领导过会并定型的报告有6篇。这些报告既有关于新产品规划的,又有老产品迭代升级的。作为一个阶段性的总结,我认为有必要...
  • ISO26262功能安全--产品开发过程

    千次阅读 多人点赞 2019-10-18 14:37:48
    2.1 相关项定义 2.2 HARA分析 2.3 功能安全目标 2.4 安全需求与安全概念 3. 系统阶段——闭门造神车,我们开始修炼 3.1 技术安全需求(TSC) 3.2 系统架构设计 3.3 安全分析与独立性分析 3.4 软硬件接口...
  • 性能测试定义和性能指标

    千次阅读 2019-05-27 20:17:32
    根据实际工作中我们接触最多的类型,可以概括分为功能测试和非功能测试两种。 功能测试又可以包括冒烟测试、回归测试、SIT测试、UAT测试等等。 非功能测试通常又包括性能测试、负载测试、压力测试、疲劳测试、安全...
  • 软件定义安全的一点点理解

    千次阅读 2019-01-15 10:39:17
    第一次博客,内容、排版都不太好,请见谅。文章内容部分来源绿盟的《软件定义下的新型安全架构和实践》、《软件定义安全》以及《软件定义安全:SDN/NFV新型网络的安全揭秘》这本书。 1.SDN/NFV 软件定义网络...
  • JTAG(Joint Test Action Group,联合测试行动小组)是一种国际标准测试协议,用于系统仿真、调试及芯片内部测试。它通过访问芯片内部封装好的测试电路TAP(Test Access Port,测试访问... 引脚功能 1、13
  • 各个ECU会周期性的发出各种信号,如果需要在另外一个子网当中使用,还需要网关进行转发,出于负载的考虑,网关通常不会把所有信号都转发,如果预先定义功能中,不包含某个信号,而后续又使用,除了修改业务所在...
  • 功能测试用例怎么

    万次阅读 多人点赞 2019-01-10 13:27:02
    学了很久的测试,第一次尝试自己了一个web登入功能的用例测试: 1、单个模块的测试用例 测试类型 功能测试 模块名称 XXXXX系统用户登入 用例描述 该用例用来测试在登入界面,用户能否正常登入,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 275,771
精华内容 110,308
关键字:

产品功能定义要怎么写