产品需求

1.问：你在 测试 中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。 　　首先，将问题提交到 缺陷管理 库，类似禅道，进行备案， 　　根据需求文档，产品说明，设计文档等，确认实际结果是否与计划有不一致的地方， 　　如果没有文档，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 　　根据一般用户的使用习惯，来确认 　　与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 　　合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪 　　等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。 　　 2. 给你一个网站，你如何测试？ 　　首先，查找需求说明、网站设计等相关文档，分析测试需求。 　　制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试； 性能测试 ； 数据库 测试；安全性测试；兼容性测试 　　设计 测试用例 ： 　　功能性测试可以包括，但不限于以下几个方面： 　　链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 　　提交功能的测试。 　　多媒体元素是否可以正确加载和显示。 　　多语言支持是否能够正确显示选择的语言等。 　　界面测试可以包括但不限于一下几个方面： 　　页面是否风格统一

话不多说， 十一种软件开发模式简介 边做边改模式（Build-and-Fix Model） 瀑布模式（Waterfall Model） 迭代模式（stagewise model） 快速原型模式（Rapid Prototype Model） 增量模式（Incremental Model） 螺旋模式（Spiral Model） 敏捷模式 (Agile development) 演化模式（evolutionary model） 喷泉模式（fountain model, (面向对象的生存期模型, 面向对象（Object Oriented,OO）模型）） 智能模式（四代技术（4GL）) 混合模式（hybrid model） 软件开发模式简介 边做边改模式（Build-and-Fix Model） 好吧，其实现在许多产品实际都是使用的“边做边改”模型来开发的，特别是很多小公司产品周期压缩的太短。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户和测试等等满意为止。 这是一种类似作坊的开发方式，边做边改模型的优点毫无疑问就是前期出成效快。

一、如何对需求不确定的创新产品进行分析和设计？ 　　1.获取不确定用户需求信息后，对其进行分析和处理。根据用户需求信息具有模糊语义、缺失信息、冗余信息的特点，首先采用模糊集对模糊语义信息做量化处理，再利用模糊集中的隶属度将其离散化；然后，采用粗糙集对需求信息做粒化处理以补全缺失信息，再利用其属性约简消除需求信息中的冗余信息。这将为后续映射产品设计参数做准备。 　　2.使用TRIZ理论拓展用户需求。构建产品特性模型，建立产品实例库。使用NN聚类分析中的广义欧氏距离，比较需求信息与产品实例库中的产品信息，在产品实例库中选取较接近的多个实例产品。建立了基于F-AHP的评价模型对其进行综合评价，以选出用户最满意的产品。 　　3.对应于产品设计参数为连续数值，建立SVR（回归）映射模型；为离散数值，建立SVC（分类）映射模型。使用TRIZ理论解决在产品映射过程中产生的冲突，并根据冲突消解方案调整产品设计参数。然后，使用LSSVC聚类方法对产品进行模块化设计，并通过产品设计参数和模块之间的关系，对相似实例产品的模块进行修改、调整或变型设计。 二、以“未来的图书是什么样的？”为例给出您的分析和设计 　　互联网发展到今天，电子图书的模式虽然已经出现了很多年，但是到现在仍然没有成为人们阅读的主流方式。主要原因有下： 　　电子图书的载体主要为平板电脑或手提电脑，但手提电脑不方便携带，平板电脑普及率不高

需求分析 需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。具体分为功能性需求、非功能性需求与设计约束三个方面。 如何对需求不确定的创新产品进行分析和设计？ 分析同类产品当前发展现状。找到产品发展的现状以及发展方向，对于产品发展的不确定性要有分析和评估。 针对针对产品目前存在的问题进行分析。 使用功能分解方法。将新产品作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。 建造一个基本原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么。 在原有的基础上不断进行产品的迭代。 对产品的新特性予以不断的改进。 结合新特性对产品进行建模 以

一.如何对需求不确定的创新产品进行分析和设计？简要总结一下有哪些方法和策略 需求分析是产品研发前期的铺垫工作，也是重要的基础工作之一。需求工作中的缺陷将给项目成果带来极大风险，在推出产品时，体现在质量、功能、场景等情境下影响着用户的满意度和期望值。简言之,需求分析的任务就是分析使用该产品的用户需求是什么，解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求。如果投入大量的人力、物力、财力、时间去设计生产一款产品却没有用户要，那所有的所有的投入都是徒劳的。比如，用户需要使用一个for Linux的软件，而开发者却没有询问而开发了for Windows的软件。开发者费劲千辛万苦完成设计后，才发现这个问题，那真的是欲哭无泪了。 1.需求分析的步骤： （1）需求征集、获取：观察、访谈、情景、调查问卷、会议。 （2）需求分析和协商：与甲方讨论需求，明确需求。 （3）需求建模：use-case建模、静态模型、动态模型。 （4）形成需求文档：形成标准的软件需求规格说明书。 （5）需求确认：与用户进行确认需求。 （6）需求管理 2.需求分析方法 结构化分析方法：使用标准化的方法，开发和推出各种名为“结构化分析”的方法论，而 Tom DeMacro 则是这个领域最有代表性和权威性的专家。 软系统方法：这是一个过渡性的方法论，并未真正流行过

1.如何对需求不确定的创新产品进行分析和设计 　　需求分析指的是在创建一个新的或改变一个现存的系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。 　　因此，设计一个需求不确定的创新产品首先需要分析当前用户痛点，并对其进行深入分析，探讨用哪些方式有可能解决这类痛点，根据这些方式定义新系统的功能和范围。 2. 下面以“未来的图书是什么样的？”为例给出我的分析和设计 　　图书的用途：图书的主要用途是阅读，是人类获取知识、传承经验的重要媒介。 　　现有图书的缺点：只有静态的文字体验，缺乏和读者动态的交互 　　　　　　　　　　文字量大而信息输入速度慢，容易引起读者不耐烦 　　　　　　　　　　版权问题，纸质书影印的盗版和电子版盗版泛滥 　　未来图书可以针对上述问题做一些改进： 　　1.对于缺乏与读者交互问题，可以利用现有AR、VR技术实现多通道的人机交互。 　　例如，给书嵌入传感器和智能芯片，孩子在阅读童话故事时，戴上AR眼睛，智能书可以识别当前所在页数，内嵌芯片将当前页的数据传输给AR眼镜，AR眼镜在书本上展示一个立体的童话人物的3D影像，孩子可以用手与其互动，可以极大地提升孩子的阅读兴趣和体验。 　　2

创新产品的需求分析：未来的图书会是什么样子？ 前言 产品创新是很简单的，但要使创新的产品得到成功就是一件很困难的事情，而对创新产品的需求说明则是难上加难。 众所周知，需求分析是软件生命周期中相当重要的一个阶段。需求分析阶段的主要任务是通过开发人员与用户之间的广泛交流， 不断澄清一些模糊的概念，最终形成一个完整的、清晰的、一致的需求说明。而对创新产品的需求分析则意味着用户可能也不是很清楚他具体想要的是什么， 而开发者也应该不知道用户到底想要什么。需求分析是软件工程至关重要的一环，只有做好需求分析后面的工作才有意义。 可以使用的方法和策略 需求确定 当用户把他的创新产品的需求提交过来时，一定要首先考虑的是为什么是这个需求，这个需求真的有存在的必要吗？若不存在则会出现什么情况呢？ 因为这是创新产品的需求，缺少相应的例子，用户可能脑子一热啥东西都往上加，这个要实现，那个也要实现， 但作为产品经理或者开发者不能任用户任意为之，一定要与用户多次沟通，帮他理清思绪，真正地获取确切的需求。 头脑风暴 怎么才能确定这个需求恰好是我们需要的呢？其中一个可行的方法是头脑风暴，和这个项目的潜在的用户进行头脑风暴， 即想象一切的可能出现的功能，然后看这个功能在当前的技术背景下是否可以实现。这样做的好处在于既可以集思广益又不至于脱离实际。 未来的图书设想 有句话说得好，” 若你想预知未来，那么你就需要了解过去

如何对需求不确定的创新产品进行分析和设计？简要总结一下有哪些方法和策略 　　a)虽然具体的需求不能确定，但是产品的某些必要功能以及大体定位是能够确定的，首先分别从客户群体以及技术实现人员出发，确定下来必需而又具有可行性的功能，在此基础上再进行创新性的设计。 　　b).充分分析同类产品的优点与缺点（尤其是缺点），在不与整体策略冲突的前提下尽量吸收同类产品的优点（至少避免出现过时的设计，比如在触摸屏时代采用大哥大的设计），最重要的是充分分析用户在使用产品时所受到的限制（尤其是用户时时受限却又不易察觉的地方），试图在新设计上能够解放这些限制。 　　c)敏锐察觉新技术与新潮流，将新元素应用到产品的实现中或者添加到功能设计中，与时代结合。 　　d)分析产品的用户群体、使用场景以及基本功能，并且试图将相同场景或者用户群体所使用的其他种类产品进行组合。 以“未来的图书是什么样的？”为例给出您的分析和设计 在我看来，未来的图书可能会通过AR的方式来呈现，将文字直接投射到视网膜上，并且会伴有一些插图等。 随着AR或者电子纸张技术的成熟和成本降低，未来的图书可能会更加的电子化，人们可能会逐渐习惯从大的集中式电子书贩卖商城上购买电子书阅读（类似于亚马逊电子书商城）。电子书的版权也能够更加得到保障。同时电子书的成本也将大大降低，从而降低书籍的购买成本（现今纸质版专业书动辄上百一本）。

一、如何对需求不确定的创新产品进行分析和设计？简要总结一下有哪些方法和策略 1.对市场环境进行调研 虽然创新产品的需求是不确定的，但是市场过去和当下的一些产品案例仍然具有参考意义。通过观察市场意见，探索客观环境，定义并描述设计需要解决的实际问题。 2.采用快速原型模型把用户界面先做出原型，给用户确认并且从客户那里获得反馈进行改进，逐次迭代，逐渐向一个理想的版本靠近，开发采用快速迭代。 快速原型模型适合预先不能确切定义需求的软件系统的开发，需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。适用于需求不确定的创新产品。 迭代模型是RUP（Rational Unified Process，统一软件开发过程，统一软件过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上

缘起 2017年3月，应移动事业群智能营销平台项目管理部负责人邀请，我开始支持智能营销平台CRM团队。智能营销平台是阿里文娱广告团队，是阿里巴巴淘外变现的主力军。CRM团队负责开发和维护CRM系统。CRM系统服务于销售和代理商，串起商机管理、客户开发、合同管理、风控审核、账户管理、财务结算等业务链条。CRM系统的质量和交付速度，直接影响销售和代理商服务广告主的效率和体验。 3月初我访谈了销售、产品、开发、测试等团队核心成员，并观察了团队的周会、站会和需求讨论会。当时团队的目标是在3月25日交付框架合同功能，主要工作围绕框架合同功能开展。根据访谈内容梳理出框架合同项目研发过程的时间线如下： 从图中可以看出，这个项目基本按照瀑布模式推进，开发2个月后整体提测，测试1个月后一次性发布。开发2个多月后，业务方才有机会试用产品并给出反馈。 这个项目暴露了瀑布模式的弊端： 1.接力棒的协作模式带来信息差 瀑布模式下，业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理，再从产品经理传递给研发团队。信息每经过一次传递都有损失，业务方、研发团队得到的大部分是二手信息；产品经理成为团队沟通的瓶颈，业务方和研发团队直接讨论可以解决的问题，要经过两轮甚至多轮沟通才能达成共识；业务方和研发团队缺乏相互理解，研发团队不了解需求背后真正的业务诉求，业务方不了解技术方案背后的权衡。 2