产品经理必懂技术术语？6、高并发高并发指的是web系统在短时间内遇到大量请求的情况。比如双11活动、春晚抢红包活动。高并发会导致系统在这段时间内执行大量操作，比如对数据库的操作、对资源的请求。如果高并发处理的不好，可能会导致请求响应过慢，甚至系统崩溃。解决高并发的问题一般需要通过各个方面进行优化，包括增加服务器、限流、降级非核心功能、算法优化、数据库优化等方式。7、限频请求频率一般指的是同一个用户，在某段时间范围内请求同一个接口的次数。这里的时间范围要根据具体的业务来定。限频指的是限制用户在某段时间内对接口的请求次数。如果超过限频规则就给予用户提示请求频率过快，稍后再尝试。限频一般是为了防止用户恶意频繁请求接口来保证系统的稳定性或者限制系统流量来保证系统在高并发情况下系统的可用性。8、日志日志是开发为了跟踪用户行为和代码异常而打的记录。当一个请求到来时，后台一般会登记以下几种日志：1）AccessLog - 用户访问日志一般会记录请求URL、请求参数、用户ID、行为发生时间、接口返回值等几个关键指标。2）Exception-代码异常代码异常一般会记录报错信息、报错发生的代码是哪一行、报错发生时间等指标。代码异常日志是最重要也是经常要看的日志，根据报错可以快速定位到发生错误的原因，快速地修复问题。3）SqlLog-数据库查询日志一般会记录SQL查询语句、数据库名表名、查询耗时等指标。可能会用于排查SQL错误、优化SQL语句。4）第三方服务日志如果后台调用了第三方服务，比如接入了公司内的统一登录服务，当调用该登录服务时，就记录这些行为。有利于排查问题时区分本服务日志和第三方日志。9、内存泄漏服务器会分配一份内存给我们的应用程序运行。如果代码写的有问题或者执行耗内存的任务时，可能会导致程序占用的内存过多无法立即释放，当再继续消耗内存时会出现内存不足，程序崩溃的场景，这就是内存泄漏。

产品经理必懂技术术语：1、回调从接口调用的角度看，把一个A接口的URL像参数传递那样，传给B接口，A接口会在某个时刻被调用执行，这就叫做回调。举个常见的例子：X平台接入公司的统一登录平台：当登录态失效时，X平台调用统一登录平台界面接口，当用户输入手机号码和验证码，统一登录平台校验通过后，统一登录平台再调用X平台提供的登录回调接口，这时统一登录平台会把用户相关信息回传给X平台，X平台注入登录态，最后X平台跳转到首页2、透传“透传”从字面上看是：透明无感知地传输数据的含义。举个例子：发短信功能（利用第三方服务腾讯云的发短信接口）：当用户输入手机号码点击发送验证码时，先调用我们自己后台的发短信接口，然后我们后台调用腾讯云的发短信接口，把用户从前端传过来的手机号码再继续传给腾讯云接口。数据传递的链路是：前端->我们后台->腾讯云。后台没有对数据做任何修改就直接传给腾讯云的这个过程就是透传。3、回传“回传”指的是数据输入方把数据传给第三方后，第三方经过一定的规则转换，再返回数据给输入方的过程。举个例子：比如一个小程序把用户的订单数据、商品数据上报给一个第三方数据分析工具，数据分析工具对这些数据进行分析，比如用户喜好分析、圈层分析等，最后把这些分析结果数据再返回给小程序后台，就是回传。4、同步和异步后台对前端发来的接口请求按照响应机制可分为同步接口和异步接口。同步指的是后台必须处理完所有的任务后，前端才能收到返回处理结果。适用于对实时性要求较高的场景。异步指的是后台优先返回处理结果给前端，然后再自动执行其他任务。适用于实时性要求不高的场景。举个例子：同步的例子：给用户添加权限时，点击新增后，等待后台返回处理结果成功时，用户就实时拥有了被添加的权限。异步的例子：批量导入表格数据时，数据量比较大，后台处理比较耗时。当点击确定上传后，批量导入的数据还没有真正入库时，后台就优先返回处理结果，提示“请稍后查看数据”。当后台真正处理完所有数据后，将以站内信、短信等反馈形式通知用户。5、定时任务定时任务是：指定每到一个时间点，就执行一个固定任务，这个任务一般是一个计算脚本。比如指定每天晚上凌晨，把一个库的数据通过一定的计算规则，把数据转换后，再同步到另一个库。定时任务是后台用来批量处理数据的常用方式，并且是实时性要求不高的批量数据。

数据产品经理必备知识？数据采集层（SDK）2.1 何为SDK？1）定义SDK是指一种软件开发工具包，是数据采集的必备工具，英文为“Software Development Kit”。本质上它其实是一些接口API的文件集合，为某个应用程序提供服务。也可以理解为应用开发者通过接入这些文件，并调用里面的相关接口，即可采集相应数据。因为SDK的大小一定程度上会影响应用程序性能，所以尽量轻量处理，占内存大多在几百K和几兆之间。2）作用不同业务下，SDK的应用性质是不同的。常见的就有数据行为类SDK、功能服务类SDK以及广告营销类SDK等。其***能服务类就是指应用通过接入SDK增加一些特殊的产品功能服务，而广告营销类则指专门做消息推送、营销推广等业务的SDK。而本文仅介绍数据行为类SDK。2.2 SDK类型主要分为客户端SDK和服务端SDK，客户端SDK是指这类SDK接入在应用的前端，比如iOS、安卓等。而服务端SDK是指接入在后端，更多的在后台底层。1）客户端SDKiOS SDK：顾名思义，就是以iOS操作系统进行开发的SDK工具包；Android SDK：同样是以安卓操作系统进行开发的，可应用在所有安卓类软件中；H5 SDK：指以网页操作系统为生的SDK，可应用在web网站、H5网页、公众号（功能实质是H5开发）等；小程序 SDK：小程序是这两年新兴的产品应用，依赖于不同的软件平台。所以需要基于不同的平台进行开发，比如微信小程序、支付宝小程序、百度小程序等，同时还需要分iOS和Android两大系统进行开发。2）服务端SDK定义：服务端的sdk具体通过后端上报数据，即业务应用采集到数据后，通过自身的服务端传到大数据系统的服务端，即“业务服务端-数据服务端”，而非客户端SDK的“业务服务端-客户端SDK-数据服务端“。类型：由于每个业务的状况不同，开发语言都不是唯一的，所以针对服务端类型的SDK都会基于不同的语言提供相应的开发版本，包括Java SDK、Pyhon SDK、PHP SDK、C SDK等等。3）小结：不同的用户有不同的业务诉求，客户端和服务端各有优缺点，主要取决于业务诉求。整体而言，大多数产品应用使用客户端SDK居多。

在数据分析领域下，总会被提及诸如SQL、Hive，甚至Hadoop、Druid、Spark等这些技术上的词汇。那么作为一名数据领域的产品经理，听着这些不是很常见的产品知识，又应该具备怎样的技术知识呢？我们从“用户行为数据“角度介绍一整套的技术架构以及相关的技术要点。阅读指南1、受众人群：数据型产品经理、数据运营等初级岗位；2、阅读收获：初步了解用户行为分析数据类产品的大致架构；掌握4大环节的数据技术要点；01用户行为分析系统本文将从数据采集、数据接入、数据分析、数据展示等4个重要地方，分别介绍相关涉及的技术知识。这一节主要介绍整体概念。1.1 概念用户行为分析系统其实是指用户使用产品过程中，把产生的行为数据通过分析而成的报表工具。此类数据区别于业务数据，大多为公开、有权限获取的，比如一些设备信息、埋点信息等。目前行业较为人熟知的有百度统计、友盟、神策等，而使用此类产品的主要是数据分析师、数据运营和产品经理等。目的是为了统计埋点、基础指标分析（如PV、UV）等，从而对产品进行体验优化或运营推广。1.2 数据系统框架1）数据采集一般用户使用产品的时候，所填写的信息会经由业务系统加密储存。而行为数据是不会经由这些系统收集，而由专门的采集工具进行采集，这就是SDK。2） 数据接入因为SDK采集的数据是非结构化的，所以数据都是以原始数据的方式按批次定期或实时上传。服务端通过接口对这些数据进行解析、加工处理，初步形成结构化的日志数据，并在数据库按表进行存储。3）数据分析当数据解析并存储之后，即可通过离线和实时两大方式进行分析。部分指标计算量大且实时要求不高，则会采取T+1、T+2（即第二天、第三天出结果）等离线计算方式。有些指标时效性要求高，如关键指标、日常运营活动（如双十一）等，就需要较高的实时计算方式，以便监测表现。两大方式采用的系统框架会有所差别，后面详解。4）数据应用当使用结构化数据进行分析时，就需要可视化的图表进行展示，不管哪种方式，基本就是通过报表网站平台进行展示。比如折线图、表格、柱状图等，甚至还需要提供更多维的分析指标支持用户自主查询。

分析业务优先级产品开发的时间规划、资源规划依赖业务优先级的确认，因此我们在产品规划时对系统的业务优先级进行优先排序，即分析系统产品用例的优先级。那么该采用什么样的方法去分析呢？应该综合考量以下因素：战略规划方向分析业务是否贴合企业当前的战略规划方向。市场情况即考虑市场的竞争情况、市场规模，分析业务对于产品的竞争力、用户群等方面的影响。业务目标分析业务的完成与否、完成质量对业务目标完成的影响。业务带来的价值分析业务能给企业、用户带来多大的价值。对于产品的初始阶段，要注意开发的业务要形成业务闭环，能优先实现最小闭环的业务优先级高投入产出比对接业务的带来的成本和其开发成本进行比较业务的优先级受到多因素的综合影响，因此要衡量好每个因素的权重。划分项目里程碑里程碑一般是项目中完成阶段性工作的标志，标志着上一个阶段结束、下一个阶段开始，将一个过程性的任务用一个结论性的标志来描述，明确任务的起止点，一系列的起止点就构成了引导整个项目进展的里程碑[10]。划分项目里程碑就是对完成业务目标的时间进行规划。划分项目里程碑包括两个部分一个是目标分解、另一个是完成时间。目标分解应该按照业务实际进行，常见的目标分解有按照业务功能、按照任务进行的步骤、按照业务价值的量化指标等。对于产品规划而言项目里程碑的完成时间不需要很精确，一般按照季度、月度进行划分。业务的优先级影响里程碑完成的阶段任务内容，每一阶段的规划要优先实现高优先级的业务。

如何梳理业务目标？业务目标的梳理是一个明确业务方向的过程，需要考虑以下要素：客户群体即产品所服务的对象，所面向的目标用户群体。B端业务系统都有清晰的用户角色，通常以职责进行划分，如常见的人力、财务、销售等。C端产品的目标客群都以明显特征进行划分，通常包括年龄、地区、职业等。明确客户群体是为了挖掘用户的核心需求、痛点，衡量市场规模。解决方案即以什么样的形式提供什么样服务或产品满足用户需求，解决用户的痛点。解决方案概括为两个方面产品定位、产品形态，产品定位就是提供什么样的服务或产品，解决用户问题，满足用户需求。产品形态就是服务的载体、产品的外在形式，例如桌面客户端、桌面WEB端、移动APP、小程序等。价值产生产品服务用户，解决用户问题，满足用户需求，给用户产生了价值。常见的形容B端产品的价值有满足业务需要、提高效率、降低成本等，常见的形容C端产品的有满足用户的情感需要、节约用户等待时间、提高用户处理事务的便利性、降低信息获取不对称等。产品给用户带来了价值，那么用户价值如何转化为企业价值？对于商业化的产品而言是要特别考量的。产品独特性即产品区别于其它竞品的特征。企业通过分析自身的优势与劣势、市场的机遇与挑战、竞品的对比，挖掘出产品的独特卖点，形成竞争优势。触达用户即如何让产品接触到目标客群？如何让用户找到产品？对于B端产品而言，是以销售为导向的多渠道寻找线索获取客户。对于C端的产品而言，是以运营为导向多渠道拉新获客。客户维护即维护产品与客户的关系。客户关系的维系可以分为拉新、留存、转化。通过数据进行量化客户关系维系，其关键指标大致可以分为营收类（如订单量、收款金额、付费率、续费率等）、转化类（如点击率、转发率、K因子等）、流量类（如新增用户数、PV、UV、获客成本等）、忠诚类（如留存率、日/周/月活跃用户数、流失率等）。不同的产品所关注的关键指标不同，通过关键指标的变化能够分析出产品当前的客户维系情况。盈利模式即产品的收入来源。常见B端产品的盈利模式有一次性***付费、订阅付费、佣金抽成等。常见的C端产品的盈利模式有广告、增值服务、商品售卖等。盈利模式是产品将用户价值转化为商业价值途径，通常都是多种盈利模式组合使用。

以需求管理为例，产品经理如何打造自己的需求分析能力？2.2.5  二审（产品+需求方）二审是对具体的产品细节和流程细节逻辑进行评审，评审通过后就可以进入开发阶段了。这个过程中如果评审失败，产品经理只需要花很短的时间修改表层逻辑，不需要做框架层面的修改。2.2.6  终审 （产品，项目，设计，技术，测试）终审就具体的产品可行性进行评估，确定具体的项目排期计划。需求排期表最为一个基本的里程碑式的交付物，表示需求进入正式的开发阶段。2.3 需求研发需求研发阶段主要阶段有：1.设计&开发；2. 测试 ；3.验收；4.发布上线。这个过程中产品经理主要跟进需求的研发进度，以及保证整个过程中的信息对称，以及对一些突发的需求修改给出可行性方案。2.4 需求归档需求归档环节主要有两个过程，输出项目复盘报告& 输出迭代计划。项目复盘报告主要是对整个项目进行总结，取得的成绩以及存在的问题和不足。迭代计划，主要针对一些需要二次迭代的需求进行迭代计划输出。截止到需求归档，标志着一个需求从需求分析到价值校验以及需求逻辑产品化到最后的研发上线归档全生命周期的结束。

以需求管理为例，产品经理如何打造自己的需求分析能力？2.2.2  需求逻辑产品化与之前需求分析阶段的需求逻辑产品化建模不同，需求逻辑产品化建模更多是基于思考层面的，而需求逻辑产品化则是强调输出层面的，接到可行性需求后开始输出基本的产品方案，输出物包括但不限于产品蓝图（产品架构图），思维导图，原型图demo等。这个阶段更多的输出产品的大的可行的方案的框架，设计理念和产品逻辑闭环等，还没有具体到细节原型和流程图的输出。2.2.3  初审会（产品+需求方）需求逻辑产品化后需要开初级评审会，用需求逻辑产品化阶段的输出物向需求方介绍产品大方向的设想，如果评审通过则证明大方向上的可行性，不通过则继续修改复审。2.2.4  产品逻辑可视化初审通过后，接下来进行的是产品逻辑可视化。之所以会有初审的原因是，我们设计产品就像修建大楼一样，需求逻辑产品化就是确定大楼地基和蓝图的过程。如果这个过程没有问题，接下来的产品逻辑可视化就像装修添砖加瓦一样，不会有大的问题。反之，如果已经输出了细节的原型图和流程图再去评审，那么一旦评审失败返工将会花费大量的时间。产品逻辑可视化阶段就是在确保大楼的地基和框架没有问题后，添砖加瓦的过程。这个过程主要的输出物一般是原型图，流程图&PRD文档等。

以需求管理为例，产品经理如何打造自己的需求分析能力？2.1.2  需求（产品）价值判断在完成需求逻辑产品化建模后，脑海里大概有了一个可满足需求的产品基本模型。这个阶段已经确定了需求的真实有效性以及有了基本的产品模型，接下来就是对产品模型进行价值评估。一般的价值评估维度分为两个方面：用户层面的使用价值；商业层面的研发价值。用户层面的使用高价值主要的分析维度有：1.用户规模；2使用频次；3.必要性；4.其他维度。商业层面的研发价值主要的分析维度有：1.研发资源；2.研发成本；3.研发风险；4.稀缺性；5.其他维度。一个需求（产品化）的是否有价值，做与不做需要根据用户和商业两个层面的多种维度综合判断。2.2 需求立项在进行需求价值判断后，筛选出的需求需要进行需求立项。需求立项主要分为六个阶段：需求优先级分配；需求逻辑产品化；初审（产品+需求提出者）；需求逻辑可视化（产品+需求方）；二审（需求方）终审 （产品，项目，设计，技术，测试）。2.2.1 需求优先级分配需求立项的第一步，确定需求的优先级。一般判断需求优先级的维度有：按照紧急程度（紧急维度）；按照价值权重（价值维度）；资源配置最优（资源维度）；按照实现难易程度（难易维度）；按照上级指示（老板维度）；按照需求产生的时间顺序（时间维度）。一个需求的优先级判断通常是多种维度综合的判断结果。

以需求管理为例，产品经理如何打造自己的需求分析能力？很多时候用户提出的是他们认为的解决方案，而并不是真实的需求，产品经理进行需求分析的时候一定要多问几次为什么，询问的时候尽量的让用户陈述需求当前的事实，表达内心感受，说出自己的期望。《乔布斯传》中提到一个细节，如果亨利福特在发明汽车之前去做市场调查，他得到的答案一定是大家想要一辆更快的马车。这里我们不去讨论产品经理要不要去做用户调研，而是回到上个世纪初，模拟一下福特如果进行用户调研会是什么样的场景。场景一：福特：你们的需求是什么？用户：我们想要一辆更快的马车。（表达期望，并没没有陈述事实以及表达感受）福特：一辆更快的马车会满足你们的需求吗？用户：是的。福特：好的，我们会造出世界上最快的马车。场景二：福特：你们的需求是什么？用户：我们想要一辆更快的马车。（表达期望，并没没有陈述事实以及表达感受）福特：为什么你们希望要一辆更快的马车。（引导用户陈述事实）用户：因为我们能更快的出行和运输，现在的马车出行和运输都很慢。（表达感受）福特：所以你们是为了更快的出行和运输吗？（引导用户说出期望）用户：是的 （说出期望）福特：那我们可以创造出比世界上最快的马车还快的东西，你们愿意用吗？（需求逻辑产品化建模）用户：当然愿意。通过以上场景分析，我们在需求分析时，应该以why的形式引导用户说出内心的真实需求，用户的世界里面也许只有马车，但是你也许能为他造出更快的汽车。How层：需求逻辑产品化建模在why层我们已经明确的用户的真实需求，接下来需要在思考层面对需求逻辑进行产品化建模，为后续的需求价值判断做准备。

以需求管理为例，产品经理如何打造自己的需求分析能力？一、需求管理引擎的定义&框架定义：需求管理引擎是一个框架模型，规范了从需求分析到需求逻辑产品化过程中的所有思考路径和思考边界，有利于培养模型化思维。框架：如下图，需求分析引擎主要分为四个模块：需求分析；需求立项；需求（产品）研发；归档，下文会串讲这四个模块的主要内容。二、管理引擎框架串讲2.1 需求分析2.1.1  需求分析框架闭环需求分析框架闭环的意思是我们面对一个新的需求，思考的时候要形成逻辑闭环。这里引用了经典的思考模型——3W模型：what，why，how ，既这个需求是什么，为什么会产生这样的需求，如何将需求转化为产品进行后续的价值分析。what 层：需求来源&需求分类what 层主要让我们标记需求的来源和分类，需求的来源又分为两个维度：方式 & 对象。方式维度：用户访谈，竞品分析，数据分析等产品经理通过某种行为而获得的需求。对象维度：用户，产品经理，其他，对象维度指的是需求的提出对象。需求分类主要分三种：以前没有过的需求，归类为新增需求；以前有过的需求再次优化，归类为迭代优化；以前的需求存在缺陷进行修复，归类为缺陷处理。why 层：陈述事实，表达感受，说出期望

面试中经常被问到，如果客户经常变更需求，该如何处理？5、零星的变更需求一次性修改遇到需要变更的零星需求，可以先记录下来（也就是需求池），每一周或者每两周可以集中研究处理。不要让频繁变更的需求影响到整体项目的开发节奏。比如可以向用户提交一份各阶段需求变更的完成计划，注明需求提出人，提出时间，需求变更成本、是否收费、收费金额、是否确认变更，变更开发进度、预计完成时间等。6、变更记录及时上报双方领导对于变更的需求要及时告诉领导，这样领导可以知道项目延期的原因，不会责怪团队，在和对方领导沟通的时候心里也有个底。团队负责人可以以日报、周报、月报的方式向领导汇报。可以以邮件或者定期的项目汇报会的形式告知，这个可以根据领导的喜好和项目的节奏自行决定采用哪种形式。最后，项目变更要在一开始就要向客户宣导，打一针预防针，让客户理解变更控制的重要意义，而不是做到一半的时候，引起客户的投诉和纠纷。

面试中经常被问到，如果客户经常变更需求，该如何处理？3、 评估需求变更的性价比需要将需求变更产生的成本和收益告知双方领导，一般成本包含开发成本、时间成本、沟通成本等。最好能量化，明确告知用户那些需求变更需要收费，那些可以免费变更，防止用户无感知，随意变更。以前我做的一个项目，不收钱的时候，老板说变就变了，说变更收费的时候，就不怎么变了。4、确认客户是否接受需求变更的代价需求变更会导致项目延期、开发士气低落，甚至是额外的收费，这些都和客户提前说清楚，如果客户认为需求变更是必须的，就会接受这些代价。如果客户认为需求变更虽然有必要但是可以暂缓，双方签署备忘录，留待以后解决。如果客户认为需求变更可有可无，多数情况下会取消。这个协商的过程一定要有，最后的结论最好有邮件发出来，或者走上面的变更流程。但是这些变更的代价一定要跟客户提前说，这样防止后面扯皮，说你没有提前告知。这样既可防止用户频繁变更需求，也可以告诉用户不是所有的需求都需要立即修改。客户懂互联网产品还好，像一些传统行业老板，他们不懂产品开发的流程，觉得变更需求很简单，这样的一个过程也可以教育他们。一般来说，涉及核心业务的变更需求需要立即做，锦上添花的需求可以等功能完善后再做。

面试中经常被问到，如果客户经常变更需求，该如何处理？给B端客户做产品，由于市场环境以及企业客户自身的一些原因，需求难免会变更，如果无法有效处理这些需求，会导致士气低落、客户不满、项目延期等情况。那对于客户的变更需求我们是迁就好，还是拒绝好呢？当然一味迁就和一味拒绝都不好，凡事走极端都不好，世界是灰色的，不是非黑即白的。如果一味迁就，会导致项目延期、士气低落，严重者会导致项目失败。但如果一味拒绝，会导致最终做出来的东西不是客户想要的，导致客户验收不通过。所以对于客户提出的变更需求，我们需要有个分析的过程，那些该变，那些不该变。变更的成本和产生的收益是否合理？如果客户频繁变更需求，我们可以采取以下措施。1、合同约束与客户签订合同时，可以对变更需求的情况做约束。比如规定客户提出需求变更的时间、何种情况下的变更可接受、什么样的变更不可接受、如果非得变更需求，是否需要加价？还可以规定需求变更的管理流程。虽然这种外包需求很难一开始就确定的很细，单靠合同很难改变需求感更的情况，但也一定程度上增加客户变更需求的成本。2、建立需求变更流程需求明确需求变更的流程。比如需要哪些审批环节、审批人员、审批事项等。这样做有两个目的，一个是将客户下达变更流程规范化，杜绝张嘴就来的非紧急、非合理、非必要的“三非”需求。二是留下书面证据，为今后可能的成本变更和索赔准备好依据。凡未履行审批程序的“变更”，都当做无效变更处理。有效的需求变更包括评估变更价值，评估变更对项目影响、最好提交双方项目负责人进去评估，是否确认变更。对于因为业务变化引起的变更，最好书面提出申请，这样双方项目负责人可以对变更的内容做到心中有数，而且客户在递交书面材料的时候，比较慎重，书面材料也是逼迫人思考的一个过程，这样可以防止出现拍脑袋的变更。