产品需求

小诀窍：不妨尝试从交付质量上打败对手 关于作者：小姬，某知名互联网公司产品专家，对数据采集、生产、加工有所了解，期望多和大家交流数据知识，以数据作为提出好问题的基础，发觉商业价值。 0x00 前言 我将整理文章分享数据工作中的经验，因为业务内容上的差异，可能导致大家的理解不一致，无法体会到场景中的诸多特殊性，不过相信不断的沟通和交流，可以解决很多问题。今天我们首先分析一下 职场基本功，为什么要重视需求质量，常见的数据需求文档改怎么写。 以下，Enjoy： 0x01 为什么要重视需求质量 如果想快速的提高自己，但是不知道从哪里开始，不妨尝试从工作中将最为常见的需求文档质量提高，相信我，一份有优秀的需求文档，就可以让你打败了大多数的数据同行。 为什么要重视需求质量 PRD是产品经理最直接，最重要的交付物； PRD的功底最容易体现专业能力，依靠逻辑和描述能力，直观反映产品思路； PRD曝光次数较高，是最佳的印象产品，产品的开发依赖技术人员，PRD的设计才是产品人员的核心； 最佳赢得口碑，给人以靠谱的感觉的交付物； 锻炼编导能力，梳理思维逻辑，提高业务水平的最好方式。 我的数据需求产品文档主要有： 项目背景 、 项目范围 、 目标收益 、 需求详述 、 交互原型 、 功能说明 、 校验测试 七大模块。在实际的工作场景中会根据情况做调整，基本情况下形成自身的特点（产品文档规范）

CMMI的级别 (Capability Maturity Model Integration软件能力成熟度模型集成模型) 1．初始级 软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 2．可重复级 建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3．已定义级 已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4．量化管理级 分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。 5．优化管理级 过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 CMMI的过程域 2、3级共有18个过程域（PA）,主要内容如下，分四大类： 一、过程管理： 1．OPD：（Organizational Process Definition）组织级过程定义。建立和维护有用的组织过程资产。 2．OPF：（Organizational Process Focus）组织级过程焦点。在理解现有过程强项和弱项的基础上计划和实施组织过程改善。 3．OT：（Organizational

1、产品人员设计完原型和文档后，召开需求评审会，参会人员有开发，测试，产品。需求评审后之后，会产生一个完善之后的原型和需求文档。 2、测试组负责人需要依据需求文档，项目周期、项目特点、工具、人员安排制定测试计划。 3 4 5 6 7 8 9 10 11 转载请标明出处: Android 测试的流程（工作流程） 文章来源: Android 测试的流程（工作流程）

为了指导软件开发，可以用不同的方式将软件生命周期中的所有开发活动组织组织起来从而形成不同的开发模型。 瀑布模式 瀑布模型严格遵守软件生命周期各阶段的固定顺序:计划、分析、设计、编程、测试和维护，上一阶段完成才能进入到下一阶段，整个模型像一个飞流直下的瀑布一下，如图所示 特点: 阶段间具有顺序性和依赖性 前一阶段完成后,才能开始后一阶段 前一阶段的输出文本为后一阶段的输入文本 推迟实现的观点 质量保证: 每个阶段必须交付出合格的文档 对文档进行审核 缺点: 开始需要把需求做到最全 惧怕用户测试中的反馈,惧怕需求变更 过于理想化缺乏灵活性 螺旋模型 限制条件: 适应于内部的大规模软件开发:螺旋模型强调风险分析,许多客户都无法接受和相信这种分析因此 适合于大规模软件项目(执行风险分析将大大影响项目的利润,进行风险分析就毫无意义) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险 优点: 设计上的灵活性,可以在项目的各个阶段进行变更. 以小的分段来构建大型系统,使成本计算变得简单容易 客户始终参为保证了项目不偏离正确方向以及项目的可控性 客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互. 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品. 缺点: 很难让用户确信这种演化方法的结果是可以控制的.建设周期长,而软件技术发展比较快

这是敏捷开发一千零一问系列的第四篇。（ 之一 ， 之二 ， 之三 ， 问题总目录 ） 这个系列的文章太多，除了用于总结性篇章外，请访问“问题总目录”查找感兴趣的具体问题。 初始问题 对于不断更新的需求，导致需求优先级的判断出现了错误，知道项目周期后期才发现，怎么办？ 答案 1. （临时方案）确保所有排序均是由PO完成的 常常出现所谓现场客户、由客户出PO、由一个销售当PO的情况，都是应该避免的。 PO一方面要熟悉具体的需求和原始目的（广度与细度的要求），另一方面则应该对产品的商业目标、终极目的了然于胸（高度与深度），才能站在企业立场而非简单的客户价值立场。 从这一方面看，“有无限时间陪着我们的现场客户”和“一个销售”，其细度有余，高度不足，很容易带入歧途；而由“客户出PO”则会被客户牵着鼻子走，客户的想法一变，项目就会变化，也不符合企业的利益。 2. （最终方案）优先级排序应该基于较为稳定的商业计划，要确保有产品总监或项目总监来把控产品或项目方向 一般的产品经理和项目经理排列优先级的依据一般有两个：一个是客户价值方面，一个是开发因素方面（比如对架构的影响、需求间的依赖）。但这些都相对浅薄的理解。 真正决定什么优先的因素，是产品或项目的商业目标，并因此制定版本计划，在版本中体现优先级。 作为产品，每个版本都是为了打败某个竞争对手，取代某个已有产品，获取某类客户的过程。 从这个角度看

B端，或者2B，一般指的是英文中的 to busniss，中文即面向企业的含义。 与B端相对应的，是C端，或者2C，同样指的是英文中的 to customer，即面向消费者的意思。 因此，人们平常所说的B端产品，就是指面向企业的产品，比如企业中用到的一整套内部办公软件，内部财务结算软件，办公erp平台，以及帮助企业实现数字化转型的云计算平台，大数据分析平台，AI人工智能平台，这些都属于面向企业的B端产品。 而与之相对的C端产品，就是指直接面向普罗大众的产品，直接面向消费者群体。其中，互联网app便是其中的产品之一，包括微信、QQ、外卖app、淘宝、抖音等都是直接面向消费者的C端互联网产品。 在产品研发的层面，B端产品经理和C端产品经理的工作职责也是不一样的。 相比起C端产品更加追求用户的新鲜感和体验感，B端产品更加注重为客户降低生产成本，提升生产效率。 因此，C端产品经理需要发动大脑去想如何满足用户的衣食住行需求，并非常重视满足用户的新鲜感；而B端产品经理则要更加贴合企业实际，将客户需求转换为产品功能，提升客户的生产和办公效率，降低生产成本。 一、产品需求文档是什么？ 产品需求文档作为从需求到功能的具体实现指南，是所有开发、测试人员在产品开发过程中的必备文档。个人认为，不管是B端还是C端，产品需求文档都应该具有以下特点： 结构鲜明、逻辑完整、表达准确、通俗易懂。 结构鲜明

<Hunter>需求规格说明书 所属学院： 数学与计算机科学学院 团队名称： Computer-Hunters 指导老师： 汪璟玢、张栋 项目成员： 邱健强、李清宇 、朱煜喆、 江海天、沈溢煌、吴俊杰、林志全、黄杨龙、 阿说阿加、陈聪 修订历史记录 日期 版本 说明 作者 2019.10.25 V1.0 第一个版本，根据项目主体架构形成 Computer-Hunters 第一章：引言 1.1目的 本节描述软件产品需求规格说明书（SRS）的目的是： 为准确描述“hunter”软件定位，明确软件需求，也作为用户和软件开发人员之间相互了解的基础；减少开发工作以及便于软件升级和产品转移撰写本文档。本篇软件规格需求说明书详细描述了“hunter”这一软件的用户需求、软件规格等内容。方便用户深入了解该软件，同时也是开发者进行开发、测试以及软件验收的主要依据。 1.2项目背景 软件名称：hunter-电脑猎手 开发者：福州大学2019软件工程实践课程“hunter-电脑猎手”小组 项目组长：吴俊杰 开发人数：10人 本项目经过大量资料搜集，客户需求问答调查等方式充分了解潜在用户需求，从用户的需求以及对于当前市场上产品不能解决的用户问题出发，经过组内讨论从而确定了软件定位和主要功能。本产品目的在于为选择电脑问题较大，对于电脑性能，配置感到陌生的群体提供更多便捷。并且暂不以盈利为目的

此文为汇总文，如有更好回答，欢迎评论。问题来源网络 1、怎么理解产品经理这个岗位？什么样的产品经理才是优秀的产品经理？ 从整体来看，产品经理就是负责把用户需求或业务需求转化为产品需求的人，为产品的具体设计、执行和成果负责。具体主要有三项职责：产品规划、产品设计和产品执行。 我认为优秀的产品经理以下两种能力强于别人： 抽象能力：把复杂的场景和需求抽象为产品的能力； 取舍能力：在合适时间做出正确的选择。 2、你认为产品经理最重要/最核心的能力是什么？说出三点。 逻辑思维能力：制定方案； 协调沟通能力：制定管理计划； 执行力：产出结果。 3、分析一下如何进行版本控制？ 目标： 1）保证各个环境(开发、测试、主干)的独立，避免相互影响； 2）减少最终发布时合并主干出现冲突的概率； 3）降低冲突处理的难度。 原则： 多个版本（开发版本，测试版本，发布版本）； 多次合并。 4、如何进行产品架构？ 可以结合用户体验的5大要素来讲，包括战略层（定位与目标用户）、范围层（功能列表及优先级）、结构层（功能关系、信息架构）、框架层（流程与逻辑）、表现层（UI、交互）。 这里，我以人体来举例： 骨骼：思考产品的结构，来源于对用户需求的理解，也来源于定位，例子：微信，豌豆荚的过去和现在; 肌肉：最重要的几个核心功能分别是什么，例子：微博最重要的几个功能时什么？ 血液：其他功能还有那些

为什么要做竞品分析？无非就是当你有了一个初步的产品想法之后，但是却不能够明确这个想法到底靠不靠谱，它是否真的解决了用户的某些需求，这些需求算不算痛点，也不知道市面上是否已经有了与你想法相似的产品，他们是怎么做的，是否做得足够好，还有哪些待挖掘的机会等等。 此时你脑中的想法一定只是个demo版，非常的初级，是一个朦朦胧胧的状态，甚至你都说不清它到底是来源于哪里，可以是从以往生活经历中随意调取到的一个记忆点，或者是某个月黑风高的夜晚做的一个不知所以然的梦。 例如你在某一天的下午突然冒出一个念头，觉得自己想开个肠粉店，为什么会突然有这样的想法，很有可能就是你中午吃饭的时候闻到一阵飘来的肠粉的香味，而到了下午辘辘饥肠的时候脑里面就自动调取了这一部分记忆使之你有了这个莫名其妙的想法。 当然，想法的来源有时也非常明确，例如说你可能对某个产品的形态很感兴趣，所以你有了做这个产品的想法，或者是当你体验了某个应用商店app，有种透彻了解这类产品的想法，还有就是leader直接给予你的产品任务，例如他会跟你说阿毛啊，我们接下来公司想做一款新产品，是社交通讯类的产品，你好好去研究一下，看看怎么做更好。 因此，这时候的产品想法相对于前者来说来源就是明确的，但是不管来源是否明确，都存在着靠谱或者不靠谱的可能，无法判断这个想法是否有市场机会，你不能一拍脑袋就断定这个想法可不可行，想要真正明确这个想法是否有戏

需求分析： 整体流程图： 需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind 分析流程： 1. 需求提取： 分析依据（包括：需求矩阵、产品交互图、需求说明书） 获取需求的纬度 客户价值 可以为客户带来哪些价值？ 可以解决哪些问题？ 根据以上问题定位功能是否合理 UI功能 - 展示功能 模块关联-历史模块 新功能模块关联 考虑是否关联？耦合部分是否需要支持？ 客户使用场景-部署方式 网络特性 客户使用服务器常见外设 性能参数-性能要求 网卡最低速率 硬件支持 输出（提取最原始的测试需求） 2. 需求分析： 分析依据（五维分析） 用户场景 功能是否和场景强关联 网络拓扑能否满足客户需求 和竞争对手比较差异 功能是否能满足客户实际应用场景 是否考虑了用户的实际操作 明确性 范围明确性（参数、类型长度范围） 清晰性限制等范畴 无法预知影响的需求提出进行确定，风险 二义性 概念模糊【大概念、第三方支持、与上个版本相同】 支持与不支持等范畴 一个需求描述能出现多种理解 完整性 需求一致性【用户需求、需求规格、需求矩阵三者是否同意】 需求完整【隐形需求】 关联性【与新老功能、与外置软件设备】 可测试性 实现测试需要的工具、方法【调试、接口命令】 定位方式【日志等形式观察】 复杂环境、容量边界、操作时过程不可见 输出 测试需求跟踪 缺陷预防bug 工具需求