平台功能需求调研

上两篇文章我们介绍了需求调研的背景分析和调研的方式方法，今天我们来聊一下需求调研的提问设定。在需求调研时，调研的问题是需要预设调研提纲的，只有提前做好准备，才能在调研过程中抓住主线。由于被调研的对象通常是业务人员，所以他们的思路是非常散的，可能会给你讲工作的具体流程和痛点，但是他们的思维宽度一般是一个点，很难有结构化的思维能给你构建清楚整体业务，此时调研提纲就能帮助你有序且不漏点的进行调研。一般需求调研都有一个框架，是宏观到微观的概念，也就是从宏观战略到经营策略再到业务执行的顺序来提问。1、宏观战略宏观战略指的是战略定位和战略目标，我们需要调研企业整体的战略规划。因为战略层决定了企业的业务方向，明确该项目的战略定位就可以帮助我们更好的梳理项目的应用框架。在进行产品的模块和功能设计时，不仅要满足当前需求，也需要基于项目的战略目标，考虑产品功能在后期的可扩展性。在做产业互联网平台的产品设计时，如果不了解公司的战略目标，那么基本就无法满足后期平台的迭代需求，未来项目重构的可能性就比较高。在我们的工作经历中也经历过类似的情况，项目搭建好了，经历一两个迭代，就面临整体重构的困境。我们在调研中经常提及的相关战略问题如下图：一般用户回答了这两个问题后，再顺着用户的思路，可针对整体战略的发展方向、可行性、盈利模式等进行深入讨论。2、经营策略接下来我们一般会进入到企业经营策略的探讨，产业互联网项目经营策略的一般平台模式、目标用户群体、商品来源、供应链策略、渠道策略、定价策略、营销策略等。我们经常在这个阶段提问的问题有：了解企业的经营策略有助于帮助我们明确当前阶段的企业的应用架构，以及未来一段时间内企业的整体应用架构，并且有助于我们更深入的了解业务细节，以便根据业务细节进行产品设计。3、业务执行最后是进行业务执行层的提问，通过前两方面的提问，我们已经可以明确该项目是否可行，业务模式和资源是否可配，以及项目的开展。等到业务调研完成时，就已确定好项目方案，定具体的执行策略了。一般的业务执行调研，是先从组织架构调研开始，我们需要明确项目涉及的企业组织架构，因为在产品使用过程中，以及业务流程中的审批流，产品设计中的权限角色等产品，都会是基于企业的组织架构来进行设计的。在产品开始功能设计之前，首先应该明确的就是，基于企业的组织架构的权限账号体系。所以在需求调研时，需针对企业架构做深入调研。最后进入到具体的产品设计调研，产品设计是基于企业实际业务场景进行的，所以需求调研的核心也是业务细节的调研。针对业务的调研可以从业务流程、合规风控两方面进行。通常需要梳理客户当前的业务流程是什么样的，业务流程中存在哪些痛点和爽点，现有的问题会造成哪些影响。通过分析用户的现有流程，重构线上业务流程，梳理出平台线上业务的服务模式。通过这个系列文章，我们梳理了需求调研的过程，一般先做需求的背景调研，了解行业现状和行业知识，接下来是设定调研方式，线上线下调研相结合，最后是针对性设置调研提纲和问题，有序的调研框架保证不漏点。需求调研是成体系并且科学的一项工作，尤其是产业互联网平台项目的搭建，是一个成本高、周期长的项目类型。需求调研做的草率，意味着项目运营时候会产生上线难、风险大等问题。近年来市场上产业互联网平台上线众多，但是大部分都经营困难，慢慢沦为鸡肋，给企业带来了极大的经营风险和压力，这都是前期需求调研不够造成的，所以之前系列文章中所介绍的案例中，说需求调研两天，就可以完成搭建产业互联网平台，这样不科学和没有方法论的领导思路是要不得的。声明：本文为原创，如需转载请联系作者

产品路线千万条，要想产品不跑偏，需求明确头一条。计划写系列文章，从产品功能需求到实现。本文为第一篇，分为问题定义、问题分析和用户调查三部分。产品需求的提出是策划产品上线的第一步，万事开头难。在提产品需求的时候，需要考虑的东西是最多的，也是最重要的，后续的所有动作，都基于对产品需求的思考。所以在一开始的时候，一定要明确定义，产品需求背后的逻辑是什么，这样才能在后续的产品实现中产生指向性的作用，避免产品偏离本意，成为一个四不像的东西。一、定义问题有产品需求想法的时候，一定是因为在观察客群的时候发现了某种痛点或者诉求，想要解决，那么第一步要做的，就是明确定义这个痛点，完整地描述它，同时建立一个假设。假设的建立，一定要建立在观察的结果上。虽然大多数假说都不可避免带有建立者主观的思维，但是在描述和验证的过程中，尽量要保持客观的角度，跳出原有产品框架。比如，我观察到用户在求职的过程中更关注求职的安全性（即公司是否正规、薪资是否真实），所以我提出设想，能不能让更多的招聘者直接面对求职者？提出假设本身也需要很多技巧，其中最重要的，就是如何明确定义这个问题，“如果你可以清晰地描述这个问题，那么这个问题就已经解决了一大半”。而不是：我观察到用户在求职行为中，更关注求职的安全性（即：公司是否正规、薪资是否真实），查看了相关用户行为，发现他们在浏览的过程中，岗位信息完善的开聊率比岗位不完善的开聊率高。所以我想，能不能鼓励招聘者更好地完善岗位信息？这两者之间的差别在于：第一个假设从需求出发，提出本质的需求，探索解决途径；第二个假设从需求出发，立足于产品，探索优化空间——两者在产品不同阶段都有其价值意义。但第二个需求，在提出时就有其局限性。虽然第一个假设在实现过程中可能最终呈现为第二个假设，但在提出阶段，一定不要限制思维的发散，落地的事情，交给下一个环节。二、解决思路定义好假设后，就进入产品调研阶段。这个阶段主要目的：用什么样的方法去解决之前提出的假设。这一步也是最考验产品思维的地方，整个需求的逻辑都会在这个环节中得到呈现。同样从第一个假设举例，“能不能让招聘者直接面对求职者”，这个想法很大，但也不是不可拆解。“直接面对求职者”，七个字，三个词语。直接：真人比视频直接，视频比图片直接，图片比文字直接；那么最优真人见面，次优视频，再次图片，最次文字。面对：线下比线上直观，直播比电话直观，实时沟通比信息浏览直观；那么最优线下，次优直播，再次电话，最次信息浏览。求职者：受众是求职者，那么所有的优化落地，参考的是求职者的行为，产品最终的评判者是求职者。好了，全部拆解完以后，得出结论：直接面对求职者，最好的方法是直接面对面线下交流。完成到这一步的时候，就需要开始考虑实际情况和限制条件了。实际情况：作为App，提供的是信息展示服务，线上沟通好以后，线下再提供邀面是常规的做法。如果要提高效率，可以考虑线下招聘会（实际操作后发现到场率、转化率很高，也是一种模式的探索），不过不属于产品范畴，不做考虑。次一级的选项，就变成了视频、直播。这两个产品形态在目前产品中不存在，如果上线需要很大的产品和研发支持，那么就需要大量调研。业内有主打此类功能的App和小程序，但目前发展状态都不好，其中肯定有一些问题没有解决，需要观察下原因。至此，明确方向，探索视频和直播的方式，是否可被目标群体——求职者所接受；同时调研主打类似功能的平台和产品，研究产品形态以及相关信息。三、用户调研定义思路后，下一步就是用户调研和产品调研了，产品调研略去，此处重点讨论用户调研。用户调研前，需要先明确用户画像，对用户先进行归类，然后着重分析各类型人群对直播、视频的看法和行为习惯。同样从大而小，从行业看起，先研究下类似艾瑞数据等调研平台的研究报告，从研究报告中获取目标用户的基本特征和习惯倾向（如果没有设计问卷的经验，可以拆解艾瑞数据行业报告，看看他们从哪个角度提问，获取到什么信息，基本拆解两、三个报告，就会有问卷设计的思路了）。以下列几个数据平台：行业分析报告数据可做参考，不可全信。这一步的目的是获取基本情况，同时参考设计属于自己的问卷，并且在问卷中埋点钩子，为下一步面谈和电话回访做准备。问卷调查设计完毕后，下一步就是发放回收了，参考原有问卷回收比例，以回收2000份问卷为目标。推送问卷问卷设计和推送时，也要有一定技巧：1. 问卷设计方面根据用户画像，针对性设计问卷，不要在问卷中提供无效信息，如：身份为学生的用户，不可能会有上一份工作离职原因，一方面避免用户填写时产生困惑；另一方面也要避免无效信息污染回答。问题数量要简练，尽可能少，各选项可以完整覆盖问题答案，同时不存在交集。题目顺序也很重要，先从小问题问起，避免用户产生警惕心理，逐步引导用户完成。2. 推送方面推送时间的考虑，各目标人群的推送比例，问卷小范围测试推送，然后迭代的思路，都是考验问卷最终质量的关键因素。问卷回收以后，就要做问卷分析了，同样可参考艾瑞数据的分析报告（真的很不错，信息颗粒度很清晰，重点推荐），进行问卷分析，总结出几个重点问题，以便后续做用户访谈以及群聊调研时使用。因为本次做的是直播和视频这两个功能，在我们已有用户中是没接触或者很少接触到类似方式的，所以在调研他们反馈的时候，就不能单纯通过提问获得答案，需要提供相应的环境，观察他们的行为，再通过回访的方式，了解反馈。这种情况下，调查问卷的目标就变成调研他们的行为习惯，区分用户群体。本文由 @white jade 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议

一卡通系统项目业务需求调研对于很多项目所要承载的业务，我们不是简单的把线下的业务流程梳理清楚就OK，而是要通过当前线下业务流程的梳理，找到线下业务存在痛点，然后在形成一卡通系统的线上业务流程时候，如何来更好的优化和调整；一：项目业务调研大纲一卡通系统二：项目业务调研内容1.项目承载的主要业务是什么？2.业务的特征和性质是怎样的？3.当前业务是怎样的？4.项目上线后，对业务流程有哪些改变的要求？5.业务涉及的使用角色说明？6.客户存在的问题和痛点是什么？考勤管理业务1.考勤主要是处理员工出勤情况的考勤系统，需要了解目前客户的考勤情况2.参与考勤的人员类型有哪些？3.参与考勤人员的数量是多少？4.考勤管理的方式使用哪种？（刷卡、指纹、面部以及刷卡、指纹、面部的组合）5.考勤管理需要提供组织结构6.考勤管理需要提供人员的基本信息（工号、姓名、部门等）7.考勤管理需要提供详细的上班时间段8.考勤管理需要提供详细的班制信息9.所有的请假、加班等是否需要审批，是否通过平台？如果通过平台，请提供各种假类的审批流程10.是否存在特殊班志，需要特殊处理的？如果有，请提供名称和相应说明11.对于考勤数据的分析结果，都需要知道哪些内容12.考勤的管理方式及管理流程13.目前由哪个部门负责人员的考勤管理？14.都有哪些业务表单？通道闸业务一卡通系统1.通道闸的数量？2.通道闸安装的位置？3.通道闸通行的人流量？4.通道闸识别的方式？5.通道闸的通行宽度？6.通道闸通行的人员类型？7.人员通行的授权管理部门？8.人员通行的管理流程？停车场业务一卡通系统1.停车场管理系统的数量是多少？2.停车场管理系统安装的位置？3.每个位置的车流量是多少？4.车辆类型有哪些？（公司领导车辆、公司内部车辆、外部车辆、特种车辆、消防车、急救车等）5.车辆类型中一般会通行哪几个位置？6.车辆入场管理流程？7.车辆出厂管理流程？8.车辆管理部门？9.现有的车辆进出厂区的管理流程10.车辆的授权流程？11.车进出权限变更有哪个部门负责？12.需要查看什么报表?，报表应显示什么信息，关注那些数据13.管理要求上还有什么特使内容？消费业务1．明确采用何种卡作为消费媒介2．人员消费的权限从哪里下发？3．相应部门主要负责哪些工作内容？工作流程是什么？4．消费的模式有哪些？（定值、分段定值、金额）5．消费的人员类型有哪些？6．明确对于每类人员的发卡、退卡、挂失、换卡的管理部门？7．是否还存在其它功能，例如：补贴下发等8．消费报表的要求，是否存在财务标准报表？消费报表的内容？访客业务1．访客的管理流程是怎么样？2．哪个部门负责访客的管理？3．要明确管理部门，部门管理范畴、部门职能等

这篇草稿在我电脑里呆了快一个月了，趁着今天月底，死活也把它整理发出来，请大家指摘。需求文档的编写是策略开发工程师的核心工作，本文计划描述功能开发文档在软件开发中的角色以及如何编写。近期参加了几次面试，提了两次这个问题：“VCU策略开发你主要负责哪些功能模块，文档如何编写的？这些技术文档如何指导开发和测试阶段工作。”不知道您是否可以说的明白。理解需求开发从整车V字开发流程说起V字型开发流程包括以下步骤：a. 通过市场调研，产品定位，在整车功能开发角度，制定整车功能列表；b. 分解到系统级功能，开展系统需求分析，系统架构开发，整车Network设计；c. 将功能分解到零部件，并落实到特定控制单元ECU的软件功能需求，d. 开展软件架构设计、软件算法实现；e. 完成软件的单元测试、集成和测试；f. 模块集成，完成系统功能测试；g. 整车功能集成、标定、测试以及发布整车功能开发主线是总-分-总架构，如下图（1），功能定义→设计→分解实施→验证→集成验证→发布。对于软件开发流程，也可以参考ISO26262中关于软件层级产品开发的要求描述（26262 Part 6），软件开发阶段推荐流程模型如下图：a. 定义系统需求（software function requirement specification）：明确软件开发功能需求，这一步的输出物就是功能需求文档。b. 软件架构设计（software architectural design）：对软件架构功能模块进行设计，以实现功能需求。c. 软件单元设计及算法实现（software unit design and implementation）：对功能单元模块进行详细设计以及算法建模d. 软件单元验证确认（software unit verification）：完成模块MIL测试，确认符合软件子模块需求。e. 软件集成及验证确认（software integration and verification）：对各子功能进行集成，确认符合软件需求。f. 软件运行测试（testing of the embedded software）：开展软件代码的HIL及实车测试，确认符合功能需求。系统功能需求文档编写结构范式通过V流程基本可以理解功能需求开发在软件开发中所处的地位。对于VCU、BMS、HCU等控制器项目开发，首先要求策略开发人员编写系统/零部件的功能需求文档（或称《xx系统功能需求文档》、《xx Function Design Specification》、《xx System Requirement Specification》）,通过项目评审并最终确认控制器功能List项及个项功能的功能需求。如果是系统级需求，还需进一步分解到各零部件。如整车上下电功能实现需要分解到FDC、VCU、BMS、MCU、OBC等控制器零部件。宽泛含义上的软件开发行业，该功能需求文档通常又叫做《xx功能需求规格说明书 Software/system requirements specification》a）软件功能清单以三电系统开发为例，系统功能的制定依据车型特点开发。除了常规基础配置功能（例：能量管理、热管理、驾驶模式切换、档位切换、高压上下电 etc.），也会根据车型市场定位增删部分功能（电子驻车、ADAS相关功能、坡道辅助等）。其中复杂度较高的功能模块，又可进一步分解到子功能需求。以某项目VCU功能清单为例，如下表：2）功能需求文档主要内容功能开发的文档的任务是把需求描述清楚，需要给软件开发人员提供必要的技术资料输入，包括功能的应用车型平台、功能描述、系统网络拓扑图、功能输入输出接口、应用场景描述等。以下为参考的文档层级格式：1. 目录2. 变更记录History track说明：追溯记录文档版本管理3. 介绍3.1 文档范围Scope of this document 说明：描述该文档的应用范围，通常此文档仅用于xx功能的概要设计阶段3.2 应用范围 Apply to development platform 说明：说明应用的车型平台3.3 参考标准 Referenced standards 说明：列举需要遵守的国家行业标准3.4 相关内部文件 Related internal documents 说明：列举与本功能开发设计需要知道的技术文件，例如整车EE电子电气架构3.5 术语及缩略语的定义描述 Terms and definition 说明：为阅读的准确性，需列举文中用到的简称，并做解释；4. 功能定义 Function Definition4.1 功能名称 Function name说明：功能命名，如滑行能量回收Regeneration Coasting4.2 功能目的 function purpose 说明：简述功能所要达到的目的，如：在驾驶员期望进行车辆进行滑行时，该功能自动激活。通过将电机设置为发电模式，将车辆动能回收转换为电池电能。4.3 网络架构拓扑图 EE Network topology 绘制CAN/lin网络拓扑图说明：将整车功能实现所依赖的整车电气网络架构状态进行说明4.4 总体功能图Function overall diagram 说明：详细说明该功能实现相关控制器节点及通讯方式。4.5 功能接口 function interfaces 说明：详细说明系统间交互的信号并绘制信号表（信号名 From To）4.6 功能设计描述function design description说明：对功能设计进行描述，说明功能实现形式以及功能要求。还以滑行回收为例：站在系统的角度，VCU内部设置与实施根据车速相关联的车辆目标减速度。中控面板提供驾驶员设置回收力度的接口。如果是分配到VCU零部件的功能需求文档，则可以详细描述设置的车速-目标减速度曲线。最大回收扭矩限制、不同回收等级下的车速-扭矩曲线、车速区间、档位要求等。（可以逐条罗列要求，条款化）4.6.1 功能进入退出条件Function enter/exit condition4.6.2 功能状态及状态转移 function work states/state transition 说明：状态转移条件，绘制状态机4.7 工作场景function scenario 说明：该部分内容类似于软件的用例规约，描述可能出现的应用场景下动作4.7.1 场景1绘制流程图及文字说明说明：用流程图可以较为清晰的展示功能实现的过程，如整车上下电、PRND档位切换逻辑等。4.7.2 场景2 绘制流程图及文字说明说明：场景应尽可能全面，充分的覆盖用户的使用范围，可以极大的避免可能出现的系统漏洞和安全风险。4.8 功能失效分析 function failure analysis说明：描述功能失效的类型 故障等级 以及整车该如何动作。例：VCU和MCU通讯失效 故障等级5级 紧急停车。其他未尽事项，不一而足。记住，功能开发文档的目的是把功能描述清楚，清晰的指导软件开发人员进行软件设计，并作为整车测试人员的功能验收依据。所以文档应尽可能的严谨，语气词要强硬。使用应当、需要、当xx条件满足时执行xx动作。不要使用可以，最好等词汇。关于软件需求文档，未完待续。。。

9月1日，威海市委书记张海波到环翠区、高区调研科技创新平台建设工作，强调要认真贯彻落实习近平总书记“围绕产业链部署创新链、围绕创新链布局产业链”的重要指示精神，坚持问题导向、目标导向、结果导向，做实做强做活“1+4+N”创新平台体系，提高专业运营水平，创新产业服务模式，加快创新成果转化，推动产业转型升级、高质量发展。市委常委、秘书长侯世超，副市长张伟参加调研。为深入实施创新驱动发展战略，威海市依托高校和科研院所，全力打造“1+4+N”创新平台体系，以威海市产业技术研究院暨郭永怀高等技术研究院为龙头，加速集聚优质创新资源和创新要素，推动高新技术产业突破发展。目前，围绕产业需求已建设高端研发中心31个，孵化企业42家，实施研发项目100多项，攻关卡脖子技术7个，形成知识产权20多个，为企业提供技术服务200余次。在威海市产业技术研究院暨郭永怀高等技术研究院，张海波认真听取平台建设、项目培育、人才引进、成果转化等情况，询问存在问题和解决措施，充分肯定研究院前期工作，强调要坚持问题导向、目标导向、结果导向，把怎么做实、怎么做强、怎么做活研究透，进一步完善服务机制，加强资源整合和协同联动，提升团队专业化水平，推出一批实实在在的创新成果。在青岛大学威海创新研究院，张海波查看了研发中心和实验室，了解研究院在新材料、人工智能、环境工程、海洋科技、医工融合智能装备、生物医药与医疗器械等领域开展的应用研究，希望研究院充分依托青岛大学科研、人才和优秀校友资源，立足威海重点产业和企业需求，加快研发成果产业化，为威海产业发展提供强劲科技支撑。张海波强调，科技创新平台建设是提升区域科技创新水平的重要载体，是实现产业链供应链创新链协同发展的坚实保障。威海市“1+4+N”的创新大框架已经立起来了，关键要发挥作用、协同高效，早出成果、快出成果、出大成果。要按照“围绕产业链部署创新链、围绕创新链布局产业链”的要求，进一步细化“做实1、做强4、做活N”的措施，明确各创新平台的功能定位和运行机制，聚焦产业需求谋划运营路径和重点措施，提高整体创新引领力。要加强团队建设，提升人才队伍专业能力、创新能力和思想活力，为区域创新突破发展提供优质人才保障。要创新合作模式，加强区市协同、平台协同、企业协同，形成上下联动、双向互动的工作推进机制，以高效务实的专业化服务，增强企业获得感和认同感。（Hi威海客户端记者 孙世超/文 朱春晓/图）

报表平台的建设分几个阶段，分别是需求阶段、实施阶段、测试阶段和上线阶段。需求阶段是第一个阶段，工作量占整个项目工期的40%左右，是项目中最重要的阶段。那么，需求阶段有什么流程？每个环节该做什么工作？在本文中，小麦根据Smartbi多年的报表平台实施经验和大家分享。l 需求整体概述需求的目的就是将项目目标从抽象转化为明细，建立双方对项目的共识。在项目阶段前期，获取到的业务需求会包含业务场景和业务对象，也即需要解决什么事情和给谁解决的，这些需求往往比较抽象。在获取到业务需求之后，我们会规划出报表平台的整体架构，包含业务架构（如财务、销售、库存）、应用架构（如报表、大屏、移动端）、数据架构和技术架构等。有了架构以后，需要进一步分析整理，进行具象化，形成最终的业务需求，包括功能需求和非功能需求。功能需求包括要需要展现的内容（如指标和维度、UI风格）、数据是怎么来的、是否需要做一些定制化的功能。非功能需求包括性能、安全和环境方面的要求。这个时候整理出的需求已经很细化了，甚至包含了字体、字号、边距等信息。但是还不能开始下一阶段的实施工作，因为最终需求的确认会受到项目制约因素的影响，包括时间、范围、成本。例如评估的需求实现需要5个人月，但项目的要求是1个人月，这样就产生冲突了。所以我们要基于项目制约因素的影响和客户进行谈判，达成最终的共识：哪些是项目内的，也即本期项目要实现的内容；哪些是项目外的，也即放在后续规划里做的内容。l 需求问题应对报表平台的建设在需求阶段是循序渐进的，流程很多，做的事情也比较多。在做需求之前，要明确需求的流程和工作方式，这样才能井然有序地往下进行。比如你不能在一进场的时候就跟客户说我们确认一下需求，你调研都还没开始，能确认什么内容？还有就是不清楚报表平台的实现内容，不知道需求应该如何落地。我们可以根据以往的项目经验规划一个报表平台的标准化体系，输出一系列文档来帮助项目的落地。报表平台涉及的行业比较多，在与客户沟通的时候可能会因为很多专业术语而不理解客户描述的业务需求，所以在做需求调研之前要先通过网上资料或者案例的学习来提升业务理解。还有一种比较棘手的情况，就是客户不知道自己想要什么，这就比较考验需求人员的个人能力了，需要掌握一些方法去引导客户，或者帮助客户去规划项目目标。l 需求整体流程 前期准备在前期准备阶段，需要通过合同或标书了解一下项目背景，知道客户是谁，客户想做什么。还需要了解一些行业背景，使我们和客户的沟通更加顺畅。了解完背景，就可以制定需求调研计划。计划必须目标明确，和谁调研，调研什么内容一定要提前明确。另外还需要清晰合理，调研的时间、时长、地点都要提前明确，不过这往往取决于客户业务人员的时间安排。需求调研计划确定后就发送给客户对接人去落实，比如约业务人员，订会议室之类的工作。 需求调研有了需求调研计划之后，就可以开始下一阶段的需求调研工作。需求调研是挖掘和记录客户业务需求的一个过程。首先是进行客户访谈，可以通过专人或者录音来记录访谈内容，并确保不要记漏客户的需求和偏离主题。有时候客户是想到什么说什么，要及时提醒客户按照主题来说。访谈结束后需要根据草稿或者录音进行整理概括，形成访谈记录，及时发送给项目相关人员。 需求分析需求分析是将用户的业务需求转化为功能需求的一个过程，包括需求整理和需求评估。需求整理按展现、数据和定制进行分类，然后进行优先级划分，再输出需求分析报告。根据分析报告再评估哪些是可以实现的，哪些是不可以实现的。在评估的时候要加上工作量，对于不可实现的需求要准备相关的备选方案，最后把评估结论更新到需求分析报告里面，作为项目经理和客户谈判的依据。 需求确认需求确认是通过谈判最终与客户达成共识的一个过程，包括需求谈判和确认。其中一个是方案谈判，就是对实现不了的需求和客户进行谈判。在这里要和客户沟通确认，但不能直接说实现不了，可以说有一个更好的解决方案，可以覆盖客户的需求点，实现的成本也更低，学会扬长避短。还有一个是项目谈判，因为可实现的需求也会受到项目制约因素的影响，对于超出工期或者超出成本的需求，我们就要考虑删减需求，或者放在未来的规划里面。在谈判完成后要输出一份需求规格说明书，跟客户进行最终的确认。在这里要注意所有的需求点都要清晰明了，不会在客户、项目经理和开发人员的理解上引起歧义。还要有正式的确认途径，一般是签字确认和邮件确认。需求规格说明书是与客户达成共识的依据，要完整记录项目所描述的整体需求，包括展现、数据、性能、安全等等；要清晰描述每个需求点的详细功能，比如参数、字体、字号；要保证内容有统一的解释，也不能相互矛盾。 需求管理在需求确认以后就进入实施阶段，根据需求规格说明书制定需求跟踪矩阵对项目的需求进行跟踪和监控，针对可能出现的需求变更，需要客户提交需求变更申请表。通过以上的分享我们可以看到，做好需求工作有助于避免早期的错误，少走弯路，提高项目实施效率，是报表平台建设成败的关键。作为国内专业领先的BI厂商，Smartbi定位于一站式大数据服务平台，对接各种业务数据库、数据仓库和大数据平台，进行加工处理、分析挖掘与可视化展现；满足各种数据分析应用需求，如企业报表平台、自助探索分析、地图可视化、移动管理驾驶舱、指挥大屏幕、数据挖掘等。Smartbi产品功能设计全面，覆盖数据提取、数据管理、数据分析、数据分享四大环节，帮助客户从数据角度描述业务现状、分析业务原因、预测业务趋势、驱动业务变革，广泛应用于金融、政府、电信、企事业单位等领域。

一、后端需求调研二、需求调研的落地方法三、后端需求类型与策略前后端分离的实现方式，使得每一个完整的产品体系都包含了前端和后端部分。相对而言,B端产品更依赖于后端部分的支撑。一些公司也习惯于将这些后端提供支撑的部分，称为“后端产品”。后端产品甚至不具有视觉化，而仅仅是一些中间件等。后端产品如冰山之下，却承担相当重要的幕后工作：支撑、运算、监控、调度、分配、统计分析、决策……由于后端产品部分的复杂性，因此负责这部分的产品经理，需要做更多、更深入的需求调研工作，才能完成方案设计。 一、后端需求调研需求调研，是需求分析的前题。需求分析，是产品方案决策的前题。从需求调研到产品决策，占据了产品经理80%的工作精力。由于调研和分析往往一起完成，所以在本文中我门统一将二者以“需求调研”代替。按通用的模型表达方式，我们可以简单画下：如上图：需求调研是一个过程，其产物是解决方案。后端需求研调，与前端需求调研很大的区别。比如用户的角色化、业务的全还原、场景的穷举、新旧逻辑兼容等。我们简单说下期中的用户、业务和兼容性的话题：1、用户后端产品的用户非最终的价值用户，而是服务人员（如客服、运营）。因此这些用户具有业务垂直性，是格式化的“人”，具有戒色性和行业属性。不同职位不同权重，关心的价值目标、决策权、使用人数不同。不同用户的具体使用场景不同。可以较容易的获取前端产品用户画像，因为我们自身或者所熟悉的人都在扮演着 前 端的角色，也就意味着设计过程中也很容易进行角色代入。而后端用户画像的获取往往艰难得多，最快捷的方式就是和公司的业务层交流，业务部门是最直接与客户打交道的，他们熟知大量的典型客户案例，可以帮助我们快速高效的描绘出用户画像。由于我们自身与后端用户的相剥离性，用户画像的作用显得尤为关键，可以时刻提醒我们是在为谁做设计，每一个关键诉求都在产品设计中有对应的抓手。2、业务业务目标——>诉求——>用户需求。业务手段——>途径——>产品功能。了解业务最好的方法，是轮岗参与业务环节中去。此外，更加便捷快速的方法，是调研访谈。调研之前，最好对业务能有大体的认知，安排好访谈的对象，提前准备好问题，让访谈更加高效。调研方式：访谈、数据分析、问卷调查、头脑风暴、德尔菲、观察，完成用户需求的收集；通过亲和图、提示清单等，整合需求信息。调研目标： 了解业务模式和业务特点 了解业务目标和业务规划 了解当前业务运转方式 挖掘当前问题与痛点对于后端产品，场景往往是很多的，需求的逻辑性大于故事性，需要由远及近规划处业务场景地图，才能勾画出业务架构，最终聚合出产品生态。在这个过程中，可以借助用户故事地图等等手段。通过整个业务的架构，厘清整个平台的用户对象、业务关系，也就确定了整个产品的业务边界范围，确定了整个团队内的业务语言。3、新旧逻辑兼容掌握后端产品逻辑真相的密码通常在开发手里，但是开发常常也需要临时查代码。在这种情况下，所有对旧功能的迭代都充满着风险。于此同时，无论是集成的大系统，还是拆开的烟囱林立服务，各个体系之间总是有逻辑调用。比如接口、公共数据等。后端产品大约60%的bug都是来自于这种牵一发而动全身的逻辑耦合。唯一能确保系统安全的办法就是做深入的可能影响的调研。为了避免空谈，我们结合《后端产品经理宝典》一书，介绍需求调研落地的常用方法，和需求的类型。 二、需求调研的落地方法1、过滤需求的方法做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。这不是一个贬义词，反而是体现后端产品价值判断的基础。过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。（1）用户场景模拟法后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。如果不能帮助用户，那么这个需求就可能是伪需求。以下面的案例说明：背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。因此，该需求是个伪需求，应该被过滤掉。（2）功能归属分析专门的系统做专职功能，有助于合理的产品体系建设。因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。如果不属于该系统范畴，那么直接说服需求方更换方案。以下面的案例说明：背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。2、拆分和聚合的方法（1） 拆分需求法收到的需求，很可能只是短短的一段话。但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。每个需求点再当做一个子需求进行调研，最后再聚合在一起。以下面的案例说明：背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。分析：该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。这里不一一展开。（2）聚合需求法拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。3、利用辅助功能调研需求调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。分析：需求是很明白的，也有它的意义，但有风险。因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。4、“拔萝卜带出泥”的方式调研需求调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。举例说明：背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。分析：第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。5、需求得分权重法该方法的思路就是将需求质量的维度进行权重，然后对需求进行打分，根据最终得分的多少排列顺序。可以采用五个维度：重要、紧急、收益、成本、风险，其中成本和风险是给予负分，五个维度的分值权重分别为30%、30%、20%、10%、10%。那么一旦对需求打了分，就可以用分数*权重，得到最终得分。注意：负分的要减。并且为了方便计算，分值最好设置0.5-5.0之间，或者0-10之间。这样避免打分的跨度过大出现较大偏差。如表所示，需求1的得分=6*30%+6*30%+8*20%-3*10%-7*10%=4.6。而需求2得分3.5，需求3的得分为-0.1。由此可以判断需求的价值顺序为：需求1>需求2>需求3。对于需求3，可以予以淘汰。以上的维度、分值和权重可以根据实际情况自行设计，但是要多考察和验证什么样的参数是较为合理的。并且也不能唯权重得分是从，而只是把它当做一个辅助工具。6、其他需求调研工具需求调研适合核心环节，该过程就会涉及到很多工具或分析方法，以确保需求调研高效、高质量。比如问卷调查、访谈、名义小组会议、头脑风暴法、观察法、亲和图、蒙特卡洛技术、鱼骨图、提示清单等。 三、需求的类型和态度笔者对B端或泛后台产品需求的一个定性划分：粗浅需求、噱头需求、踢球需求、过剩需求、建设性需求。1、被动的粗浅需求这类需求，属于想当然的需求，不考虑系统的兼容性和业务兼容性的。比如：电商场景中，要求：若库存为0，则果断给予下架；库存变为非0，果断自动上架。这种强制自然是存在极大风险的。并且库存为0也有曝光的价值；非零也有下架的场景。二者不等同。这种情况下实际是“概念偷换”的错谬，无库存=下架。对这类需求，产品可以持保留态度，持续观望，收集更多用户的深层次数据反馈。但不能轻举妄动。2、战略的噱头需求这种很好理解，很多公司其实都是这么玩没的。比如：看到竞争对手有的功能，我们要有；对手无的，我们也要有。这样可以显得产品更强大。或者是强行“组合创新”：一个做医药电商的，你让他做直播带货，且不说是否合规，你能想象药师在店里当着店长的面做网红吗？这种情况下实际是“感觉谬误”。理论上，产品经理需要拿数据论证的。所以产品经理能做的就是慢点做，保留资源。找机会慢慢把意见渗透到高层，试图止损。3、隔壁的踢球需求在多组织的团队中，这种踢来踢去丢需求的情况相当普遍。比如，对医药商品，配置一段免责声明，展示在商城。那么让商品后台在商品维度加字段并传给前端，看似从后端到前端，且商品维度的，似乎没错。但是没必要的。因为，这是共性字段，商品维度几乎不需要重复维护，也没有操作差异性。这类需求，产品经理需要从分工、系统职能、收益考虑，将事情客观表述出来，完成博弈。4、客服的过剩需求这类需求，往往是客服传达来自用户的需求。通常目的很明确，但是对功能设计进行了干涉，可能影响产品的分析。比如，客服传达某O2O用户的需求：要在商品的实际销售价旁边，展示线下零售价格。产品：然后呢？客服：若对比到差异，则修改线上价？产品：怎么修改？ 客服：在线下零售价的基础上按公式计算，比如上涨1%，得出线上零售价，然后逐个编辑。产品：是否可以理解为，目的是让线上价格，按自己期望的卖，不取线下零售价？ 客服：是 产品：那么为什么不在根源处理呢：创建一组用于线上销售的价格，直接引用不就可以了吗？这类问题，一定是要挖掘到用户的场景的，从用户的场景下寻求同理心，不受制于现有功能的设定。只有这样才能不受局限，找到用户的初心。以解决问题为标准。5、产品经理的建设需求所谓建设性需求，可能是每个产品经理心中都有的夙愿。前提是，产品经理的决策正确。比如：自主优化产品模型，拆分微服务，界面统一等，统筹规划和重构的类的内容。若前四类需求过多，将会挤压产品的建设性需求。产品经理能够腾出手来做一些真正正确的事情，往往能对全局带来增益。都看到这里了，点个关注吧！END

编辑导语：一个产品的开始阶段就是产品调研，因此产品调研质量的好坏对产品来说至关重要。对产品经理来说，B端产品和C端产品的需求调研是很不同的，那么B端产品的需求调研该怎么去做呢？本文作者就结合工作经验，总结出了B端产品需求调研应该注重哪四个方面。需求调研对于一个应用产品来说，是一个产品的开始阶段。它的输出“产品需求分析报告”是设计阶段的输入，需求调研的质量对于一个产品来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个产品的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。作为PM，我们都知道C端产品和B端产品的需求调研方式是有很大的不同，但是想把产品做好，需求调研却是每个产品经理不得不去学习和了解的。那么，如何才能高效有用的去做好B端产品的需求调研呢？本文将从以下四个层次来分析：业务架构、业务流程、工作细节、信息结构图。这里需要注意的是，需求调研的四个层次，在前一个层次没有搞清楚前一般不会开始第二个层次的了解。一、业务架构业务架构的核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境以及梳理高阶需求和非功能性需求。关键词：组织管理结构图1. 业务背景产品痛点诞生的背景：明确产品的业务场景是什么？明确产品的目标客户是谁？明确目标用户为什么要使用这个产品？2. 业务目标业务目标是指针对企业特定的战略项目和其目标的文件，并在规定的时间必须完成或达到。业务目标应基于公司宗旨制定战略，对战略进行目标分析并制定具体措施的部门中长期规划。3. 业务目标人员投资人、老板、总经理等，囊括了业务参与人员。4. 业务参与参与人员使用产品的人。5. 组织架构例：电商组织架构二、业务流程业务流程为达到特定的价值目标而由不同的人分别共同完成的一系列活动，活动之间不仅有严格的先后顺序限定，而且活动的内容、方式、责任等也都必须有明确的安排和界定，以使不同活动在不同岗位角色之间进行转手交接成为可能。关键词：绘制业务流程图那么，在进行需求调研时，该怎样去梳理业务流程呢？梳理业务流程是一个挺复杂的过程，这个过程主要是以实际的业务场景为基础获取业务信息，然后抽象出一个以参与对象为节点的业务流程。我们以电商为例：此流程应当包括5W2H内容：Who、What、Why、Where、When、How to、How much，最终可以通过泳道图等工具一目了然的展现方式展现出来。1. Who——用户整个业务流程中所有涉及到的所有相关人员。需要注意的是针对B端产品，用户不但包括客户、商家，可能还会涉及到多个角色以及平台侧的服务人员，如：客服、财务、商品管理员等。2. What——目标即用户需要完成哪些事儿。针对B端类产品，比如：发布需求、对接需求、签署合同、支付货款、履约交付等。这些都是用户在业务进行到一定的阶段需要完成的一些相对大一点的阶段性的目标。这些目标在后续需要进行进一步的细分处理拆解子目标，作为后期切分页面的依据。3. Why——原因了解用户为什么需要完成目标。这涉及到设计的流程及页面是否可以进行优化和调整，是否可以从流程上进行节点删除。梳理业务流程不是简单的照搬，需要分析现有实际场景中各节点的必要性，现有流程是否可以进行优化或者调整，知道原因能够有效的帮你判断。例如：订单生成后的调整价格，其源头在于用户与商家间的议价行为。4. Where——地点主要说明用户会在什么地点完成目标，地点会影响到你提供给用户完成目标的入口。如：订单处理人员的办公地点多在办公室内，工作环境多数对着PC端，如果仅提供移动端页面就是不符合场景的。5. When——时间主要说明用户会在什么时间完成目标，时间影响到你提供给用户完成目标的交互设计内容等。如：工作时间，用户完成目标可能由于本职工作，需要信息尽可能的详细，甚至对于信息的真实性来源等都有所考虑。但如果是业余时间，则用户可能没有意愿完成细致工作，简单的移交或者搁置、审批等则是更好的选择。另外在视觉设计环节，夜晚使用的页面设计和白天使用的页面设计是不同的，例如微博的夜间模式。6. How——如何完成目标这个过程真正体现了当前场景下用户是如何操作、处理的，这个环节需要特别在意用户习惯，需要深刻挖掘用户习惯。7. How much——完成其目标所需要花费的成本代价这点是可以打动用户的一个很重要的方面，如果可以把收费升级为免费，把货真价实变成物超所值，或者在等价值的基础上给用户更多的体验，这将是产品的杀手锏。当根据5W2H梳理完B端产品的业务流程之后，就可以输出产品的业务流程泳道图。三、工作细节工作细节次针对每一个参与上述业务流程的参与者展开，描述他的工作细节，做什么、怎么做、有哪些规则（权限）、结果是什么。关键字：用例模型1. 获取用例渠道岗位手册——对企业管理人员和各业务部门工作人员所在岗位的工作职责、管理权限以及企业各项业务工A作提出的具体规则与要求。业务流程指南——描述管理系统内各单位、人员之间的业务关系，作业顺序和管理信息流向的图表。它用一些规定的符号及连线表示某个具体业务的处理过程,帮助分析人员找出业务流程中的不合理流向。职务说明——通过职位描述的工作把直接的实践经验归纳总结上升为理论形式，使之成为指导性的管理文件。2. 业务主角访问引导方法您对系统有什么期望？您打算在这个系统里做些什么事情？您做这件事的目的是很么？您做完这件事希望有一个什么样的结果注释：通过以上的4个问题可以引导业务主角代表说出他们的业务需求。3. 用户主动提出需求的时候可以，多问几个什么为什么要提这个需求？目前有什么困难？现在是怎么样做的？如果涉及到业务数量的，还可以问下量大不大？当搞清楚工作细节字后，就可以输出用例图。以电商为例：四、绘制信息结构图绘制信息结构图就是脱离产品的实际页面，将产品的数据抽象出来，组合分类的图表。关键字：信息结构图作用：当根据步骤完成信息结构图之后，B端产品的需求调研就结束了，整理好所有内容后，就可以进行需求分析，调整细节后，下一步就可以进入到设计阶段。本文由 @星河 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于CC0协议

在上一篇中，我们明确了如何确定项目目标以及如何确定干系人，在本篇文章中，我们将梳理一下如何确定调研方式以及如何确定调研问题。首先我们再梳理一下B端产品需求调研的基本流程，如下图所示： 01 确定调研方式在实施需求调研之前，我们需要确定需求调研的方式，以便实施后续的需求调研。B端产品的需求调研方式主要有三种，分别为【行业研究】、【深度访谈】、【调研会议】，那么我们应该在怎样的情况下选择哪种具体的调研方式呢？以及每种调研方式应该注意哪些问题呢？下面我将梳理一下这三种调研方式的适用场景和注意事项。1. 行业研究B端项目通常包括企业内部自研项目和企业外部定制化项目，对于企业内部项目，产品经理对该行业已经具备一定的熟悉度，但是对于外部定制化项目，产品经理对客户所在行业的了解度相对较少，所以我们需要对行业做深度研究，并且对核心竞品的相关功能做深度体验；通过研究行业和体验竞品，快速了解行业并且梳理出调研过程中需要对受访者提出的问题。如果不进行行业研究，我们对行业的了解度不够，可能会导致在调研过程中大部分时间需要受访者给我们普及行业基础知识，导致需求调研时间长效率低；所以无论是内部自研项目还是外部定制化项目，行业研究都是产品经理必须要做的需求调研工作。行业研究的方法有以下两种：1.1 针对业务研究经典管理案例线上业务通常都是线下业务场景的映射，所以无论是自研还是定制化项目，我们通常都可以在市场上找到同类型的业务案例进行研究。比如某大型制造行业企业要研发供应链金融平台，由于目前商业信用仍然是货币信用的主力军，所以我们可以在网上找到很多相关的企业之间是如何根据贸易往来产生借贷关系的案例进行研究，以帮忙我们更深入的了解供应链金融的业务形式。1.2 体验市面上同类产品B端产品通常是企业内部管理软件，使用门槛较高，但是市场上仍然存在一些可以免费试用一段时间的B端产品。比如如果我们要体验企业项目管理协同办公软件，可以试用worktile；如果要调研商家管理后台，可以试用淘宝商家端；如果要调研CRM系统，可以试用sales force；另外也可以通过相关产品的专业服务提供商的官网了解其针对特定行业的解决方案。2. 深度访谈深度访谈是针对干系人逐一进行用户访谈的需求调研方式，也是可以最高效的了解需求的调研方式。深度访谈通常适用于受访人较少且受访人时间和空间条件都允许的情况，比如在企业外部定制化项目中，由于空间限制，我们可能无法对干系人进行面对面的深度访谈。在深度访谈准备阶段，我们需要注意以下事项：2.1 了解访谈对象的背景在确定干系人阶段，我们对干系人已经做了职位职级和岗位职责的初步了解，在此基础上还应该尽量对其做更深入的了解，尤其是了解其和其他业务相关方是否存在利益冲突，以避免在产品设计中出现业务各方存在利益纠纷的情况；比如CRM系统中，对KA客户定位不明确，可能导致出现KA销售和中小销售抢客户的情况。2.2 确定访谈对象的访谈顺序在进行深度访谈前，我们还需要明确访谈对象的受访顺序，通常需要按照职位由高到低的顺序进行访谈。因为对需求的了解需要从宏观到微观，从企业战略层到具体的业务形态，而战略层的需求调研对象通常为企业管理层，所以按照职位由高到低进行干系人的访谈，可以帮助我们从战略层到业务层逐层梳理和理解需求。如果不按照特定顺序进行用户访谈，则可能出现需求调研过程中不同调研对象的需求表述出现互斥情况，导致需要对其中一些调研对象反复进行深度访谈。2.3 制定访谈大纲在进行深度访谈之前，我们还需求针对每一位访谈对象制定一个访谈大纲，制定访谈大纲的目的是为了控制访谈节奏，使得我们清晰的明确应该先做什么，再做什么，防止在访谈的过程中出现跑偏导致最终没有达到访谈目标的情况。以下为深度访谈访谈大纲的模板，大家可以进行参考：3. 调研会议调研会议是对干系人集中进行需求调研的调研方式；调研会议较常用于外部定制化项目中，因为在外部定制化项目中，技术服务提供商通常和需求方不在同一地点办公，所以产品经理无法逐一对干系人进行深度访谈。但是为了高效的了解需求，通常会和需求方约定一个合适时间开展需求调研会议。在内部自研项目中，当项目干系人较多且干系人允许的调研时间不符合按照职位由高到低调研的需求时，我们也可以采用调研会议的形式，统一对干系人进行需求调研。在开展调研会议前，需求注意的事项有以下几点：3.1 明确会议目标在开展需求调研会议前需要明确本次会议的目标，明确的目标可以帮助产品经理在需求调研会议中把握会议的节奏和方向，因为需求调研会议可能出现业务方针对某个业务问题深入谈论的情况，会打乱会议节奏延长会议时间，此时产品经理应该以会议目标为原则判断是应该在会上继续讨论该问题还是应该会下另行组织讨论该问题，以保证高效的完成需求调研会议。3.2 制定会议流程调研会议本质上是将所有关键干系人集中起来进行统一调研，在开始调研会议前应该明确好会议流程，确定会议议题分别有哪些以及会议议题的先后顺序，按照层级关系罗列出我们需要问的问题，保证需求调研会议的高效性。02 确定调研问题确定调研方式之后，我们还需要确定调研问题，提前准备好调研问题可以帮助我们在会议过程中井然有序的进行提问，防止在调研过程中出现问题遗漏的情况。首先我们需要明确需求调研的框架，B端产品的需求调研是从【战略层】、【战术层】、【执行层】三个层面进行的；调研问题也应该围绕这三个方面进行准备。1. 战略层战略层是指该项目的战略定位和战略目标，我们需要确定该项目对企业整体战略部署的意义，因为战略层决定了企业的业务方向，明确该项目的战略定位可以帮助我们梳理项目的应用框架，在进行产品的模块和功能设计时，不仅要满足当前需求，也需要基于项目的战略目标考虑产品功能在后期的可扩展性。如果在产品设计前不了解项目的战略目标，那么产品的功能虽然满足本期要求，但是可能在后期会进行较大的功能调整。比如某国家级艺术品交易平台决定在故宫600周年之际联合故宫邀请国家级大师定制一批故宫藏品的高端仿制品，并通过线上渠道进行销售。我们了解到该企业当前的交易模式是通过线下竞拍的方式进行艺术品交易，企业想通过本次故宫600周年之际的艺术品售卖正式打通线上艺术品交易渠道，在产品设计前我们并未了解到该项目的长期战略目标是以国家级艺术品交易平台进行信用背书，打造自营+入驻的垂直线上高端艺术品交易平台，所以产品的整体架构均是以自营平台为前提进行设计的，导致后期引入商家入驻模式时候后端技术对订单、商品、供应商、分销商表都进行了调整。下面我梳理了针对项目的战略目标需要提出的问题供大家参考：2. 战术层了解项目的战术层也就是了解其经营策略，经营策略是指企业的业务模式，比如电商类项目中，项目的经营策略包括其平台模式、目标用户群体、商品来源、供应链策略、渠道策略、定价策略、营销策略等。了解企业的经营策略有助于帮助我们明确当前阶段的企业的应用架构，以及未来一段时间内企业的整体应用架构，并且有助于我们更深入的了解业务细节，以便根据业务细节进行产品设计。如果在产品设计前不了解企业的经营策略会导致产品功能无法满足当前的业务需求，比如在上述的艺术品交易平台案例中，由于没有明确其平台模式，我们的产品设计完全是按照自营模式进行的，后续又按照自营+入驻的销售模式进行了平台化改造。那么针对项目的战术层应该怎样进行需求调研呢，以案例中艺术品交易平台为例，我总结了如下问题：3. 执行层通过战略战术层的调研，我们对项目整体的战略战术布局已经有了较为清晰的认知，接下来要对业务细节进行调研。执行层的调研分为组织架构和业务细节调研。B端产品的实际使用人是企业中的员工，我们需要明确项目涉及的企业组织架构，因为在产品使用过程中，业务流程中的审批流，产品设计中的权限角色等产品都会是基于企业的组织架构进行设计的，而且在产品开始功能设计之前，首先应该明确的就是基于企业的组织架构的权限账号体系，所以在需求调研时，需针对企业架构做深入调研。产品设计是基于企业实际业务场景进行的，所以需求调研的核心也是业务细节的调研。针对业务的调研可以从业务流程、合规风控两方面进行。那么针对项目的执行层应该怎样进行需求调研呢，以案例中艺术品交易平台为例，我总结了如下问题：写在最后明确了调研方式和调研问题后，接下来要做的就是实施需求调研啦，在下一篇中我将以高端艺术品交易平台为例展示需求调研的输出文件，梳理如何输出一篇高价值的《需求调研总结报告》。感谢阅读，期待再见~本文由 @周伯通 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议。2年b端产品初级需求调研给作者打赏，鼓励TA抓紧创作！