产品面试题

corn6

已于 2022-07-15 00:34:25 修改

阅读量182

点赞数

分类专栏： vue 文章标签：前端

于 2022-07-05 11:17:38 首次发布

本文链接：https://blog.csdn.net/corn6/article/details/125616066

版权

vue 专栏收录该内容

21 篇文章 1 订阅

订阅专栏

项目的完整周期？

启动（开发方接到客户的需求建议书 / 收集需求，根据要求进行项目识别，初步确定项目范围说明书，进行可行性研究。确定开展后，任命项目经理，组建项目团队，制定项目章程，召开项目启动会）
计划（设计系统，包括什么模块，每个模块包括什么功能，每个功能页面什么交互方式）
执行（编码，测试，发布）
监控
结束

产品经理的职责？

开发的进度管理
与用户进行沟通

it需求分析？

业务：从各种途径收集需求，在深入理解项目的基础上，（分析可行性，确定优先级，提炼需求，将需求转换为系统功能，完善功能的细节（模块、页面、交互），产出原型图、需求文档），制定项目开发计划；在项目的执行过程中，需求的变更，优先级的改变；在项目上线之后，继续收集需求，进行版本迭代
沟通：负责具体项目的管理，进行项目相关沟通与协调;
负责与客户沟通项目需求、项目进度、项目交付和项目验收；
管理：对项目进行风险控制，进度控制，制定项目研发计划、项目组成员的任务计划，并组织项目实施;
组织测试成员进行项目单元测试和项目测试；

在IT项目建设中，需求分析是最初也是最基础的一个步骤，需求分析人员是客户与研发之间沟通的桥梁，是项目研发成败的关键一环。

客户在建设IT项目时，业务人员为统一的需求出口口径，业务人员熟悉业务，知道业务的要求是什么，了解业务的痛点在哪。但需求背后的本质需求，业务人员多数时候是没有想清楚的，这个时候就需要我们的需求分析人员帮助客户了解他自己到底需要一个什么样的IT系统。

比如公司业务迅速发展，业务增长较快，但随之而来的售后服务问题也越来越多，服务运营人员数量有限根本忙不过来。现有IT支撑系统手段较为薄弱，系统与系统之间没有关联，服务人员需要来回切换查找不同的信息，综合不同信息来解决问题，问题处理效率低下。由于客户投诉不能及时解决，产生积压，导致客户问题处理时效越来越长，客户投诉愈演愈烈，形成恶性循环。

业务人员反馈说需要一个服务支撑系统，能够综合各类信息，快速解决业务故障问题，同时如果能够优化一下业务流程，降低客户投诉率是最好不过的了。当研发拿到这样的一个需求后，肯定是一个头大的状态，但如果需求分析师告诉研发，现在客户需要一个业务故障处理系统，包括业务概览、业务信息查询、业务故障诊断工具、故障处理记录查询、故障分析几个模块，每个模块分别的功能包括…，每个功能的要求是…，那么这个时候，研发人员的思路便清晰了，需求分析人员就是这么个桥梁。

需求分析既然这么重要，那么如何帮客户分析清楚想要的东西、如何设计系统功能，如何设计功能细节，则变的尤为关键，总的来说，可概括为如下几点：

学习业务，站在客户角度考虑问题
提炼需求，将需求转换为系统功能
深入设计，完善各类功能的各项细节

学习业务，站在客户角度考虑问题
学习业务，了解业务，成为客户行业的"专家"，虽然不在业务一线工作，但需要理解业务一线的工作情况，熟悉业务背景、明确业务对象、定位好业务人员角色，站在客户角度去熟悉业务，考虑问题、定位问题、解决问题，针对流程繁琐的业务，可在思路上对业务流程进行改进，乃至在业务发展上，也有一定的见解，着对系统的规划演进起到重要作用。
提炼需求，将需求转换为系统功能
第二点，提炼需求，将需求转换为系统功能，这一步对于经验较为丰富的需求分析人员来讲，那就是水到渠成的事情，什么样的业务对应大概什么类型的功能，当接到项目需求的时候，心里其实已经有个谱了，需求调研分析阶段，只不过是对自己思路的验证、已有产品的功能对应，在尽可能小的工作量下，对现有产品的功能进行改进，如此而已。但同时也会引发另一个问题，那就是思路固化、闭门造车，一套原型走天下，一条胡同走到头，其结果不能说不好，但总归是少了点创新的意思。
针对刚接触的新人来说，借鉴同事前辈的经验是个很不错的选择，在前辈的基础上加以思考，择优弃弊，将其转换为自己的一套思路方法。当然也可以根据自己对业务的理解，一点点进行梳理，比如前面所举得例子中提到，运营人员需要到多个系统来回查询不同的信息，综合不同的信息来解决问题，那么基于这个痛点，是否可以将业务人员关注的信息给集成起来呢，提供一个查询的功能，只需要查询一次就可以看到所有关注的信息。具体的来说提供一个业务信息查询功能，支持多个条件的自定义查询如按照业务标识进行查询、按照业务类型进行某一类查询，以表格的方式进行呈现，可点击某一条具体业务查看详情，呈现的详细信息包括业务名称、业务类型…等信息。那么为了集成各类信息，如何从外部各个系统获取这些信息呢，用什么接口合适，具体字段指标的格式、定义是否统一呢，指标采集周期如何，数据采集到系统后是否要进行标准化的处理呢？数据经过标准化之后是否要统一进行数据汇聚计算呢？系统内的功能如何使用这些数据呢，详细的说，就是到哪张表里获取哪些字段。
明确了数据从数据源、指标定义、数据周期、数据抽取方式、数据标准化方式、数据入库、数据汇聚方式后，我们系统的数据基础已经打好了，后面就是系统功能如何基于我们的数据基础进行系统逻辑计算，简单点来说直接到哪个表里获取哪些字段，复杂点来说综合不同数据信息进行各类业务逻辑处理。如刚才所举例的例子，各类数据都统一按照系统自有的数据模型采集入库后，一个简单的查库就可以满足了。
深入设计，完善各类功能的各项细节
在将需求提炼为系统功能后，更进一步的就是功能的详细设计，这一步是逻辑的体现，很大程度决定了测试的工作量多少，功能设计的不够完善，很多细节没有考虑到，研发在开发阶段，也会有诸多问题，特别的可能会影响整个功能模块的设计。拿上面所举的例子来说，我们要实现一个业务信息的查询功能，分为查询条件、表格列表、详情呈现三大要求。
查询条件：包含业务标识查询，业务类型查询两种，业务标识需要支持关键字模糊查询，业务类型为固定的类别，因此考虑下拉条件查询，下拉字典有…，业务标识与业务类型为且的关系
表格列表：默认列表的呈现字段有…，默认呈现顺序如刚才所列，可按照某某字段进行倒叙、升序排序，字段过长时部分隐藏呈现，单页最多呈现20条，采用分页/滑动条的方式
详情呈现：详情包括***几大类，**类中的字段信息有…(呈现的样式、布局可简单在DMEO中设计，详细的由UI来设计)
如上我们便将几个功能点的一般详细要求思考清楚了，那么基于基本的功能要求之外，是否可考虑在进一步的功能优化、或者说扩展呢，比如查询结果的导出、详情信息分享、表格默认呈现字段自定义等等，这些就需要结合业务要求进行设计和考虑了。

总结
其实需求的调研分析，很多类型都是通用的，比如拓扑类的、图表类的、表格类的、报表类的等等，每个类型考虑的要点多数情况下是想通的，因此我们可以针对不同类型出具一个需求调研分析的模板，来快速进行思路整理和分析，也同时能够快速教会新人上手工作。

与用户进行充分沟通
　　通常，与用户沟通前的准备时间要远远大于正式会面沟通的时间。一般情况下，用户在和你连续交谈两个小时之后，就会失去热情和耐心，这是大部分人的共同特点。所以充分的准备工作至关重要。
　　准备工作包括对项目整体环境熟悉的准备工作和对具体业务进行调研前的准备工作。项目整体环境的熟悉工作需要了解:项目的背景、项目的目的、项目的利益相关方等信息，以便对当前项目的鹰钵情况有一定了解。
　　对具体业务调研前的准备工作包括:需求调研问题的准备、需求调研模板的设计、需求调研时间安排等内容。要充分珍视用户的时间，尽量避免由于准备工作不足而反复约见用户，给用户造成效率低下的印象。一旦发生这样的错误，以后可能就会很难约见到用户。
主动积极了解客户业务和相关知识
　　在计算机技术方面我们可能非常专业，但对于具体的用户业务可能并不十分清楚。这个项目对用户是否有帮助、某一系统功能是否有用、某一流程处理是否合理，在不了解用户业务的情况下，我们将很难做出判断。
　　因此只有在了解业务的基础上，我们才和用户有共同的沟通语言和业务理解，才能真正理解系统应具有哪些功能。笔者曾在经销商管理系统调研过程中，由于财务方面的知识有限，使得在对经销商财务部门的调研中对部分问题不是特别的理解。
　　当时，笔者向用户虚心进行请教，并在调研结束后及时对自己的财务知识进行了补充。应用领域的知识是无边无际的，在各种项目的调研过程中，肯定会出现由于需求分析者缺乏某一领域的知识而影响需求分析工作的准确、顺利进行。遇到此类问题时，需求分析者应虚心向用户请教，同时应及时补充应用领域的知识。最好能够在调研前做好充分的准备。
引导用户，使用户充分表达自己的想法
　　在与用户交谈中，如何引导用户说出他们的需求是非常关键的。恰当的提问，会使用户滔滔不绝，充分发表自己的意见和建议。而不恰当的提问，可能会导致用户无法回答或敷衍了事地进行回答。提问可分为封闭式提问和开放式提问。
　　封闭式提问目的明确。如:现在你们的送货单是手工填写还是电脑打印?但过多使用封闭式提问，会导致谈话枯燥，让用户感觉自己好像在接受审问。开放式提问是请对方对某一事物做进一步的解释，可使谈话达到一定的深度和广度。
　　如:你认为目前的工作中存在哪些可以改进的地方?开放式提问缺点是容易使谈话内容偏离主题。因此在谈话过程中，应采用封闭式和开放式提问相结合的方式。以简单问题开始、从用户熟悉的内容开始。每次只提一个问题、集中一个重点，宁问勿猜。并尽量避免使用IT相关的一些术语，以便用户能够很好地理解我们的表达。
对用户进行正确分类
　　组织中的用户在很多方面存在差异，例如:使用系统的频度和程度、计算机系统知识、所进行的业
　　务过程以及个人的素质和喜好等。根据用户的特点，可对用户进行一定的分类。将用户分类并归纳各自特点，详细描述他们的个性特点及任务状况，将有助于需求的获取和分析。
　　不同的问题需要询问不同的人，对于操作细节的问题，要和实际负责操作的用户进行沟通，而对于关乎全局的问题，则要和相应的管理层用户进行沟通。如通过组织架构图得知仓库部门有三种角色:仓库主管、发货理货员、系统操作员。
　　我们发现仓库主管是对全盘业务相当熟悉的人，他负责协调本部门的全局事务;而发货理货员是部门的主要业务执行人;系统操作员则是仓库管理系统的直接操作者。若我们调研的目的是搞清该部门的整体性流程，我们会很自然地选择仓库主管作为访谈的对象。
应实地了解用户工作流程
　　实地观察用户执行业务任务的过程。了解用户什么时候获得什么数据，并怎样使用这些数据，业务处理过程中需要处理哪些单据，需要和哪些角色的用户发生关联等。这都将有助于明确产品的功能需求。
　　经验证明，与人们面谈关于他们如何完成任务时会有许多限制和不准确性，而这是任务观察可以直接解决的。特别是对于某些组织中普遍接受的规则和方法，用户认为你也应理所当然知道，而不曾提起时。
　　近年来，由于人机交互的复杂性惊人地增加，人机交互的观察和记录已引起人们的广泛注意。观察是一个主观的领域，很大程度上依赖于需求分析者的经验。在经销商管理系统的需求分析中，通过观察发现:某些客户要求送货单中的商品价格为含税价格，而有些客户则要求送货单上的商品价格为不含税价格;有些商品的税率为13%，而有的商品税率为17%;
　　有些客户要求送货单上的金额小数点后保留四位，有的客户又要求送货单上必须提供自己公司的商品编码等。而这些都是在调研中，用户不曾提起的内容。
分析需求可行性
　　柳传志曾说:“没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选，这样的事也不干。”
　　柳传志为联想集团的决策确立了上述准则，同时也为可以行性分析指明了重点。可行性分析主要是针对某一需求决定是做还是不做。一般可行性主要考虑两个方面的因素:技术和人。技术方面主要是分析在给定的时间段内是否可实现所需的功能并满足产品的质量要求等相关指标。
　　很多时候，用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想，将为项目的后续工作带来很大的风险。因此应尽量避免在需求分析中包含技术实施上有难度的功能。如在笔者曾经负责的一个项目中，用户要求新的管理系统应实现和用友、金蝶等管理系统的数据接口，以方便这些系统中的数据导人新的管理系统。
　　许诺提供与用友、金蝶等系统的数据接口，将为新系统的成功实施带来很大的风险。因为熟悉这些系统需要时间，开发与它们的接口也需要时间，而且用友、金蝶等这些系统存在多个不同的版本。因此与外部系统接口的可行性定义为:不可行。
　　人的方面主要考虑目标用户是否具有相应的素质和能力。在实际项目中，笔者曾对快速消费品行业经销商批次管理的可行性进行了分析。首先，批次管理将涉及到所有产品的出入库操作，并存在一个产品有多个批次的情况，因此批次管理对操作人员的能力和素质要求比较高。
　　其次，快速消费品行业的特点决定了产品的出入库操作极为频繁，因此，操作人员的工作强度比较大。再次，大部分经销商的仓库所在地都距离城镇比较远，因此工作人员的文化水平普遍不高。在综合考虑后，将批次管理的可行性定义为低。
　　对于复杂的项目，还应从经济方面和环境方面进行考虑。经济方面主要从投入、收益、短期、长远利益等方面进行分析。环境方面主要考虑市场环境和政策因素。
确定需求的优先级别
　　当客户的期望很高、开发时间很短且资源有限时，设定需求的相对优先级将有助于项目管理人员解决冲突、安排阶段性交付并做出必要的取舍。建立每个需求的重要性有助于规划软件的构造，以最少的费用提供产品的最大功能。
　　特别是对渐进式的项目，优先级的设定就显得更为重要，因为在这些开发中，项目时间安排极为紧迫并且交付日期不可改变，一些低优先级的需求就需要推迟到后续版本中进行实现或直接取消。
　　当众多用户因期望不同而就某些需求优先级的设定难以达成一致意见时，需求分析者可指出每一需求所需的费用、难度、技术风险或其他特定的与权衡需求有关的指标，来客观评价每一需求的优先级。
正确理解需求分析文档确认
　　需求分析是一项繁琐枯燥的工作，需要和用户不断的商讨、确认和反复。但大部分用户并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心在笔者曾负责的经销商管理系统中，经销商认为，库存过高将占用企业运转资金，增加企业负担;库存过低则无法满足客户订单，从而导致交货周期延长，降低企业市场竞争力。由于经销商对当前可用库存十分关注，因此可用库存的优先级被定义为:高优先级。仔细考虑或回答你的问题。这很容易使你错误地认为用户已经真正地了解并认可了你的分析文档。
　　在需求分析文档上签字确认，通常被认为是用户同意需求分析内容的标志行为。而实际操作中，签字确认工作并未得到用户的充分重视。“他们要求我在需求文档上签名，于是我就签了，否则开发人员不开始编码。”用户的这种态度将可能给项目带来潜在的风险，如不断地进行需求变更等。
　　对于需要用户确认的需求分析文档，最好在用户确认前，就文档内容对用户进行一定的讲解，以确保用户完全理解并认可文档中的内容。若用户对文档中的内容存在修改意见，则修改后再与用户进行确认，直至用户完全认可文档中的内容为止。通常为对项目有一个整体、准确的理解，需求分析所包含的内容通常大于项目范围所包含的内容。
　　因此，应让用户理解对于某些功能的讨论并不意味着即将在系统中实现它。应使用户明白对需求分析文档的签字确认是建立一个需求的基线，进一步的变更可在此基线上通过项目定义的变更过程来进行。需求确认将给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的用户与需求分析人员的关系，为项目的成功奠定坚实的基础。将知识从一个地方传送到另一个地方并不是一件简单的事情，而且原始的需求通常是以不完整的形式呈现的。它也许只是在某个现有系统的用户脑中，甚至有时用户都没有意识到他们知道什么。同时需求分析工作者也应在日常工作中加强学习，不断总结，使自己的需求分析能力得到不断的提升。