平台需求调研

不管是公司安排的软件项目，还是合同项目。我们拿到一个新的软件项目，首先要做的事情就是根据现有的人力资源、技术能力、项目工期合理地制定项目管理计划。如果现有的人力资源或技术能力不能满足项目工期要求，则需要增加人员或提高人员的技术能力。项目管理计划内容可多可少，主要以自己能够管控项目开发为原则。一般说来，项目管理计划包括项目组织架构、工作分解结构、进度管理计划、需求调研计划、配置管理计划、质量管理计划。小规模的软件项目可以只有进度管理计划，进度管理计划将整个软件项目工作分解为不同的阶段，每个阶段的工作又分解为多个子工作，分解的子工作以1周以内完成为宜。进度管理计划的第一个工作任务一般是需求调研工作，需求调研工作的主要任务是调查系统需求、绘制需求模型、编写需求规格说明书。下面这张图给出了需求调研的基本过程和步骤。图 1需求调研的基本步骤需求调研的基本步骤是调查系统需求、编制事件列表、发现系统角色、编制用例模型、编制类图模型、编制界面模型、编制部署模型、最后形成需求规格说明书。需求调研的第一步是调查系统需求，调查系统需求的方法，在前面的课程我们已经讨论过了。在这里主要采用与用户的面谈方式，通过与用户的面谈，找出系统的相关事件，并写出事件列表。需求调研的第二步是依据前面给出的事件列表，归纳和抽象出系统相关角色，建立角色列表。归纳和抽象系统相关角色，要注意角色不是指具体的人和事务，而是表示人或事物在系统中所扮演的角色。需求调研的第三步是建立角色用例图，角色用例图是系统需求的功能模型，描述了角色的行为及角色间的关系。每个用例需要给出用例规约，用例规约描述了用例的用例名称、参与角色、与其它用例间的关系、前置条件、后置条件、操作流程、输入与输出数据项等内容。需求调研的第四步是根据角色和用例模型建立类图模型。一般说来，前面分析的系统角色就是系统中的对象，也称为类。类图模型描述了类的名称、属性及行为，以及类与类之间的关系。需求调研的第五步是依据角色用例和用例规约建立界面模型，需求阶段的界面模型只要给出原型就可以了，不需要考虑界面的美观性。需求界面模型可以使用PowerPoint、Axure RP等工具进行绘制。需求调研的第六步是确定系统的部署需求。部署需求主要由网络环境、硬件环境、软件环境组成的需求。网络一般采用网络拓扑图等模型，给出部署系统所需的网络环境需求；硬件环境给出部署系统所需的硬件环境需求；软件环境给出系统所需的软件支撑环境需求。最后形成完整的需求规格说明书，将前面的文字表格资料、绘制的模型、图片等内容放置到需求规格说明书中。需求调研的成果物除了需求规格说明书外，还有需求跟踪矩阵，编写需求跟踪矩阵主要目的是可以有效跟踪项目需求变更和需求实现，做到在需求和项目之间维护双向可跟踪性。跟踪需求是因为在系统研发期间，需求会由于各种各样的原因而发生变更，因此有效的管理这些需求和需求变更是很重要的，我们有必要去了解每个需求的来源以及对系统的影响。

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

一、为什么做需求调研？软件项目往往从用户的一个或者多个需求开始，需求调研就是彻底搞清楚弄明白用户到底想要什么，帮助用户把心中的想法具象化，这些具象可以是流程、功能、性能、界面等等。用户在提交需求时，往往有以下两种情况：（1）用户只是想到了某一点或者几点的功能，想法不成熟也不成体系。这种情况，需要我们帮助用户完善需求，一步步的挖掘用户到底要做成一个什么样的东西，这是一个引导的过程。（2）用户负责或者参与某项具体工作，想要通过信息化的手段实现。这种情况，需要我们先充分调研用户工作流程后，深入与用户讨论交流，让用户多说，我们多听。一般来说，用户并不是软件研发的专业人士，用户的很多想法、设计、思路和具体的软件设计有着一定的差别，这就是专业人士发挥的空间。专业人士依托用户的想法，结合自己的经验知识和用户一起用更工程化更科学的方法建设软件项目。因此，需求调研的时候，不仅要弄清楚用户的需求，还应该用自己的经验帮用户归纳出更加合理的需求。二、如何开展需求调研？1、准备软件项目开始的时候，我们一定会拿到用户关于软件的一些描述。首先，我们就要基于这些描述弄清楚用户要做的是一个什么样的软件，这类软件通常有什么样的功能，这类软件的应用价值是什么？有了这些信息后，我们才能在需求调研的时候更好地引导用户，有的放矢。2、调研准备工作完成后，可以开始与用户进行调研沟通，这时需要关注三个方面，即项目背景、业务流程和项目角色。项目背景调研的对象是项目发起者，一般是领导。项目背景，是了解用户建设项目的根本动机，也就是初衷。在不同的建设动机下，用户的软件的要求会有很大的差别。充分的调研项目背景，可以很好地把握客户的期望值和建设目标，从而有效地屏蔽风险点。业务流程调研的对象一般是业务负责人。业务流程，是调研的关键与核心，是最需要花时间、下功夫的，这需要反复地与用户沟通，充分把握用户的想法、要求。另外，业务流程不能简单地把线下流程照搬到线上，要找到线下流程的痛点，然后，在线上流程中进行调优。项目角色调研对象一般是一线工作人员。项目角色调研和具体业务息息相关，项目角色就是项目最终的使用人员，核心点是关注每个角色在业务中的任务，做好权限的切割和业务的流转。3、总结需求调研结束后，要有内容输出，一般来说就是需求调研报告。在需求调研报告中，要阐明项目背景与目标、通过本项目要解决的核心问题、项目中关键业务流程（必要时可以绘制业务流程图）、项目中的角色分工等。

对产品经理来说，绝大多数工作时间都是围绕需求展开的——需求分析、需求调研、跟进实现需求等。那么关于需求调研这部分，一般都有几种调研方法呢？我们又该如何使用这些方法呢？需求调研是需求实现的前提。需求调研主要内容有：了解需求背景、明确需求目标、过滤不当需求、确定大致方案。需求的用户是谁？需求解决的核心问题是什么？使用场景有哪些？哪些是主要和次要场景？业务的流程是什么？除了主要业务还有哪些流程可能使用这个功能？除了本系统还有哪些系统会关联到这个功能……这就是需求调研的“十万个为什么“。本篇结合《后端产品经理宝典》书中的内容，单从需求调研案例出发，看几种常用的调研方法。一、过滤需求的方法做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。这不是一个贬义词，反而是体现后端产品价值判断的基础。过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。1. 用户场景模拟法后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。如果不能帮助用户，那么这个需求就可能是伪需求。以下面的案例说明：背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。因此，该需求是个伪需求，应该被过滤掉。2. 功能归属分析专门的系统做专职功能，有助于合理的产品体系建设。因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。如果不属于该系统范畴，那么直接说服需求方更换方案。以下面的案例说明：背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。二、拆分和聚合的方法1. 拆分需求法业务用户提出一个需求，很可能只是短短的一段话。但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。每个需求点再当做一个子需求进行调研，最后再聚合在一起。以下面的案例说明：背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。这里不一一展开。2. 聚合需求法拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。三、利用辅助功能调研需求调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。分析：需求是很明白的，也有它的意义，但有风险。因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。四、“拔萝卜带出泥”的方式调研需求调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。举例说明：背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。分析：第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。五、需求得分权重法该方法的思路就是将需求质量的维度进行权重，然后对需求进行打分，根据最终得分的多少排列顺序。如表所示，采用五个维度：先`先`重要、紧急、收益、成本、风险，其中成本和风险是给予负分，五个维度的分值权重分别为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，可以予以淘汰。以上的维度、分值和权重可以根据实际情况自行设计，但是要多考察和验证什么样的参数是较为合理的。并且也不能唯权重得分是从，而只是把它当做一个辅助工具。六、其他需求调研工具需求调研适合核心环节，该过程就会涉及到很多工具或分析方法，以确保需求调研高效、高质量。比如问卷调查、访谈、名义小组会议、头脑风暴法、观察法、亲和图、蒙特卡洛技术、鱼骨图、提示清单等。以上整理自《后端产品经理宝典》。#专栏作家#书籍《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交App。本文原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议

一个新项目往往只有几个月的交付周期，往往给予到需求调研的时间非常少，尤其是尤其是to G类，需求调研的机会是非常难得。那么在做需求调研之前，我们可以多做些准备工作，提升需求调研的成功率，获取客户更多的信任。一、情景再现早上刚到公司，Boss发来消息——“公司现在有个新项目，客户需要做一个涉案财物管理系统，项目的资料信息发到你的邮箱，你赶紧把需求搞清楚，尽快提供一版原型去和客户确认。”这个场景是不是很熟悉，很多时候，领导就这样几句话就分配一个项目，然后催着赶紧开工。领导分配任务之后，那么我们就赶紧进入邮箱，把项目的资料下载下来，细细研究。即使提供了一些资料，我们就可以开工画原型了吗？肯定不行，在接到一个新项目之后，我们需要先做项目背景调研。切莫着急开工做原型。二、为什么要做项目背景调研在做To C端产品，首先需要做商业需求分析BRD，然后是市场分析MRD，才会进入到产品分析PRD。那么在B端产品和G端产品，业务需求复杂，如同茂密的森林，一不小心就会迷失在业务细节中，难以看到业务的全貌。导致这种情况的根本原因在于：一个行业花费了几年甚至几十年时间建立起来的业务流程与规范，我们很难用一两个星期完全消化。面对这样一个错综复杂的场景，产品经理最好的做法是循序渐进，从最粗略的项目背景，业务目标开始，然后分析业务流程，再到界面展示。所以我们首页需要对产品所服务的业务领域有一个概括性的了解。我们可以从行业背景、业务目标、问题痛点等方面进行调研。现实中，对于项目背景的调研，往往是我们产品人员容易忽略的，忽略的一个最大的风险是：我们不能很清晰准确的把握客户的期望值和建设目标，从而给项目交付带来风险。比如我之前参加的一个项目，客户的旧系统由于系统臃肿，业务配置不灵活等原型，准备淘汰他们的旧系统，并且明确指定了一个他很欣赏的新系统，这套新系统，无论是在页面风格、业务灵活性、用户体验确实都非常好，希望能够尽量复用这个新系统，在上面进行功能调整，以适配他们的业务。那当时我以为的客户期望和建设目标就是复用这套新系统已替换旧系统。当时我撸起袖子深入研究了客户推荐的系统，进入分析之后，立马就开始画原型。但是等我们提供了改造的原型设计之后，客户改变了策略，他们既没有淘汰旧系统，也没有使用指定的新系统，而是在他们的旧系统上面进行改造升级。此时我才明白，客户的公司由于业务运转目前都是通过旧系统完成的，若使用新系统，一方面短期会影响现在业务的正常运行，一方面还涉及到业务上下游的调整，所以客户真正的期望和目标是参考这个新系统，来优化他们的旧系统，而不是真的把业务切到新系统中。由于没有清晰准确的把握客户的期望值和建设目标，前期过早的做了很多无用功。所以，在开展工作之前，进入项目背景调研是非常重要的环节。项目背景，是了解用户建设该项目的动机和背后存在的痛点的关键环节，基于不同的动机，客户对系统的要求也是很大差别的。三、怎么做项目背景调研针对项目背景的调研，我们梳理的提纲如下：1. 这个项目是做什么系统首先我们需要弄清楚这个项目涉案财物管理系统是做什么，这个问题我们可以先自己在网上搜索资料，或者通过现有的资料，搞清楚这个“涉案财物管理系统”是个啥东西，有啥用。很多时候我们以为我们理解的东西就是正确的，这个时候还需要与调研对象进行一个信息的确认，以便及早的纠正方向。2. 这个项目是为谁做的什么样的目标客户会产生这种需求？每个产品都有特定的用户群体，B端产品也不例外。首先我们要搞清楚，产品到底是卖给谁？在B端和G端，花钱购买系统的人称为客户，而真正使用系统的人是最终用户，客户和最终用户可能是同一个人也可能不是同一个人。客户和用户对系统的要求是由很大差别的。一般都什么样的企业会去建设这种系统，这个该怎么了解了。如果是to B 产品，可以通过搜集的产品的竞品企业，去看这个竞品的成功案例，往往就能发现他的产品应用到了哪些企业，以及应用的大致情况如何；通过这种侧面的了解，就能让你知道，大致那些客户群存在类似的需求。如果是to G产品，那么这个信息可以通过寻找项目接口人直接明确项目的服务机构。比如这个“涉案财物管理系统”是什么样的机构会使用，经过了解，目前这个项目主要是政法委投资建设的，但是公安、检察院、法院都会使用。像to G的项目，我们还需要了解客户的组织结构。比如涉案财物管理系统，是公检法在刑事案件过程中会对涉案财物进行维护管理，而政法委是一个监管公检法的机构，由政法委投资建设这个系统，督促公检法按照工作要求进行涉案财物管理工作。3. 客户为什么要建设这个项目做C端产品时，我们习惯用“用户故事”帮助我们定义用户类型，做B端产品，同样我们可以用一个“企业/机构故事”帮助我们理清目标群体的需要。“目标客群是一家____公司，没有我们产品之前，他们是这样工作的：____，当前的工作方式出现了____的问题，因此想要借助我们的产品解决____需要，期望达到____的效果。”那么涉案财物管理系统的机构故事可以这样写：产品的目标客户是公安机关，在没有我们的产品之前，他们主要是靠人工进行登记、管理，工作繁琐、业务量大，导致容易出现管理漏洞，涉案财物被截留、挪用、调换、遗失等问题的发生，不利于管理。因此想借助我们的产品解决涉案财物管理中存在的各种问题，规范流程，提高工作效率，确保执法规范化建设工作顺利进行。通过这个企业/机构故事，我们可以定位到产品针对什么行业、什么规模的企业，然后明确这类公司的核心诉求，将来在做功能与设计的时候可以围绕着这个核心诉求展开，也是产品不断更新迭代的方向。针对to G类项目启动的背景，还需要特别考虑法律、法规的要求，以及政策的指导方针。4. 业务目标分析业务的痛点。希望通过这个系统达成的目标。短短一个企业故事，为我们后续的需求分析有很大的帮助。接下来我们还要做一道选择题帮助我们理解产品的定位。我们的产品对客户的重要性如何？生存需要：这个产品关系到公司的生存问题；核心发展需要：这个产品有利于公司提高核心生产力与竞争力；次要发展需要：这个产品对公司的生产或发展不产生重大影响，但有利于公司解决一些具体的问题，帮助公司改善非核心领域的工作，或改善核心领域的工作；锦上添花需要：有这个产品更好，没有也没太大关系，可以有其他替代解决方案；5. 项目的建设内容通过现有资料：投标书，竞品分析，得出：这个项目有哪些功能。然后，我们还在看在网上搜索，看看是否已经有别人做好的现成的“涉案财物管理系统”，很幸运，很多时候你也能搜到一大堆类似的软件，虽然只是简单的介绍，但至少让你知道了这么一个访客系统的大致包含了什么功能；——你可以理解为这是一个简单的竞品分析的过程；通过建设内容，我们大致可以锁定项目的边界范围。以便下一步围绕这些功能展示调研。6. 公司内部商业价值分析同时我们还需要明白公司为什么要承接这个项目，比如：项目是和公司最近某个战略相关吗，需要把这个项目当做标杆拓展公司业务吗？公司做这个项目的优势有哪些，是有核心技术能力，或者是这个项目是之前建设过的后期项目。新项目的建设周期要求，项目往往都是时间紧迫的，了解项目建设周期，便于提前识别风险，对项目整体把控。四、项目背景调研结果项目背景的调研，首先要找准对象，一定要想办法和对方项目发起人，主管领导进行短暂的沟通，即使只是半个小时的沟通都行，了解清楚项目建设的动机、对项目的期望值，要达成的目标，非常的关键和重要。即使是一个全新项目，当我们完成了上面这些调研之后，我们能够：在概念层面有一个认识了解，并且科普了行业的专业名词解释，不再是个业务小白。了解我们的目标客户和用户了解客户的期望和诉求了解业务的痛点，客户希望能成的目标项目的范围边界我们的优势，能够调用的资源信息本文由 @瓜子 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自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．要明确管理部门，部门管理范畴、部门职能等

编辑导语：对于B端产品来说，需求调研是经常做而且很重要的一件事，只有对需求足够了解，才能设计出大众所喜欢的、市场所需要的好的产品。那么，应该如何开始你的需求调研呢？需求调研的执行过程又是怎样的？如何对结果进行汇总和反馈？带着这些问题，我们一起来看本文作者的分析吧。一、什么是需求需求=预期-现状。二、需求调研的意义C端产品和B端产品在调研方式上，存在差异。C端产品往往并不是通过用户需求调研获取产品需求，而是基于对用户群体的深度认知分析、并通过一系列策略方案设计等得出产品改进方向。B端产品需要解决很多实际应用场景问题，往往需要对行业非常了解，深入行业，了解行业现状和诉求，才能设计出更为符合市场需要的产品。1. 了解实际情况通过调研了解客户目前实际的工作情况，管理情况，制度流程等。2. 找出系统偏差了解实际情况同产品之间的差异：哪些是可以系统化的、哪些线上管理会更复杂、哪些在线上能够得到优化。3. 分析问题并确定核心问题对收集到的需求内容进行分析，归类整理，确定与目前产品有偏离的需求点，提炼共性核心问题。4. 用户更愿意使用产品针对共性要点问题，结合当前产品现状，进行迭代优化，让产品更适应客户的实际管理工作，切实提高产品效率，让客户更愿意使用并依赖系统。三、需求调研的过程需求调研，包括目标制定——确定调研计划——选择调研对象——确定调研方式——设计调研问题——规划行程安排——调研过程执行——调研结果汇总分析——调研反馈等几个阶段。接下来我们对几个重要过程进行详细分析：四、如何开始你的需求调研（调研计划）1. 确定调研目标要做需求调研，首先需要明确调研的目的，要达到一个什么样的效果。大方向确定了，才能进行后续规划。2. 选择调研对象目标确定后，接下来对目标进行拆解，确定调研对象，调研对象是调研分析过程中最重要干系人之一，需要仔细做好管理。确定调研对象的范围、职位、数量、访谈时长、地点、沟通方式等。3. 确定调研方式调研方式一般包括行业研究（典型客户研究、竞品分析等）、深度访谈、调研会议（客户反馈会议等）等几种方式，本文后续主要针对深度访谈进行分析。4. 设计调研问题1）如何设计调研问题合理设计调研问题，能够起到很好的引导和提示作用，通过5W2H等方法，对调研问题进行相对完整的梳理分析。Who：由谁来完成Where：在哪完成What：完成什么事情When：什么时间完成Why：为什么要完成How：怎么完成How much：涉及哪些费用2）分层设计调研问题我们在确定需求调研目标时，可能会涉及多个不同的岗位，而调研对象也往往具备不同的职位。我们在调研时，要考虑调研对象所处的层次，针对不同层次的人群，设计不同层次的问题。调研问题可简单分为战略层、战术层、执行层问题。战略层问题：一般需要被调研者具备较高的视野或者职位，能够对总体目标有比较清晰的认知和规划，清楚最终需要达到的方向。我们了解战略目标后，方向基本更加明确，可以指导调研人员少走弯路。战术层问题：一般集中在各类策略制定上，比如管理流程、营销策略、定价策略等等。一般是对公司总目标的分解，被调研对象集中在中高层管理人员，处理管理类工作较多。管理类需求的实现很可能是决定客户是否采购的重要评判依据。执行层问题：一般集中在具体执行层面，此类调研一般是在总体目标基本明确，流程基本清晰的情况下进行，大多集中在人员安排、工作细节等类工作上。对于具体的工作任务分配及工作效率的提升，有较强烈的需求，执行层问题可以多关注具体业务细节，找出需要进行增效提速的痛点需求。3）设计调研问题注意事项适当删减：适当针对某项工作，设计调研问题时，可以进行裁剪，有些背景情况已经比较明确的，没有必要多次强调，减少沟通成本。设计开放性问题：需求调研问题，可以设计一些开放性问题。我们并不能考虑所有的情况，设置开放性问题，有时会收获意想不到的惊喜。尽量不做假定性设定：设置问题，以了解客户的实际操作为主，尽量不设置假定性问题（方案设计环节可以使用）等。不设计引导性问题：比如您觉得我们XXX功能是不是很好用等等，让客户说出自己想说的答案，不要引导，不要误导，这样容易得不到客观的答案。调研问题设计可参考下表（内容可自行设计）：5. 规划行程安排调研启动前，先沟通好行程，让配合调研的客户或伙伴有相应的准备。能够抽出时间及精力，配合我们的调研。提前建立联系，有助于拉进跟调研对象之间的距离。五、需求调研的执行过程1. 切入需求调研方式确定后，根据行程安排，见面后简单介绍来意、目的；可根据环境聊一些简单的问题，夸赞对方好的地方（注意诚心，不要浮夸），拉进跟被调研对象之间的距离。2. 观察观察力是产品经理必须要具备的能力，我们在观察时，要注意人、场、事、流。其中，人、场、事是比较容易观察的，流程想通过观察获得，有时会有一些困难。可以结合提问来了解情况。1）人观察人的年龄、性别、穿着、情绪、说话风格等，迅速了解这个人的一些基本特点，以调整应对方式。比如：这个人比较专业，就尽量少问一些基础问题；如果这个人比较严肃，就尽量少用一些玩笑的口气；如果比较乐意沟通，就尽量多问。2）场多观察办公场景，场景是线上和线下结合的重要参考因素。有时候，你看了他们的办公环境，就知道有些功能他们一定不会用。观察整体办公环境，可能会发现一些协同的地方，如共同区域、管理流程等；观察个人办公环境，可以分岗位去查看，每个不同岗位，桌面上或桌面下以及办公桌周边，配置的物品会有所不同。可根据不同物品的摆放，找到一些不便捷地方或者很好的地方（考虑线上化实现）。3）事观察被访谈者的办公状态，主要工作处理时的情况，在沟通时，可让被访谈者模拟办公场景。关注其他人的办公状态，我们访谈时，往往会把注意力被访谈对象身上，而那些没有参与访谈的，他的工作状态往往更加真实，可以多留心观察。4）流对于一些工作流要额外关心，工作流往往属于比较复杂的协同工作，这些工作流对于线上化的需求，可能会更加强烈，线上系统对流程协同容易找到更好的解决办法，提升协同和沟通效率。3. 提问熟悉环境时，我们就可以开始提问，提问题不一定要非常正式的一对一谈话，可以边聊天边进行，在访谈对象的办公桌前也是一个比较好的选择，可以边聊边观察访谈对象的日常工作。提问题时把握好时机，并不需要根据访谈列表一一提问，访谈列表可以事后整理。提问过程中，如果有些回答没有说清楚，或者有些问题之前没有考虑到，及时进一步提问，以便弄清楚事实。整个访谈过程，可以进行录音，以便事后整理。4. 倾听在访谈过程中，一定要注意倾听，时不时予以肯定，交谈过程中，不要出现否定客户的行为或者语音。鼓励访谈对象多说，我们多听。需求调研的过程，并不是解决客户问题的过程，我们对于客户在访谈中提出的一些问题，可以适当解答，但尽量不偏离调研主题。对于用户的一些操作或者系统使用方法，我们看起来不合理的，不一定要纠正，要及时弄清楚，客户这么使用的原因是什么，这也是产品改进的重要参考因素。5. 感受（同理心）感受实际是在沟通过程中的一种心理过程，我们应该要具有同理心，尽可能同客户站在同一个的角度看待问题，每个人所处的环境不同、认知不同、层次不同，客户的回答也许没有价值，但这本身就是一种价值，他代表了一类客户的认知或者问题。这类人也是我们的客户，如果我们能很好的解决并满足这类人的需求，对产品的发展同样大有益处，同理心是一个人能够持续成长的很重要的特征。6. 记录访谈过程中，有时候很多问题来不及记录。如果条件具备，可以记录一些提纲性内容，事后再来整理，最好是可以准备一个录音笔或者使用手机录音，事后进行整理。7. 合理帮助（可说可不说时，则不说）针对一些客户明显有违常识或者知识内容错误的，可适当提醒，如果把握不好尺度，可以不用提出，避免沟通氛围出现问题（有些人性格外向，乐于学习，比较容易接受，有些本身有一定的身份，为人严肃，现场直接指出错误，可能会出现其他问题）。访谈最后，确认是否有其他问题，感谢别人的帮助。六、需求调研的结果汇总1. 调研样本归类需求调研完成后，对调研内容进行归类整理，对不同客户的特性，也进行归类整理，了解客户群体，问题类型等。2. 问题汇总对问题进行汇总，同样的问题，同样的回答、不同的回答，各占比多少，如有不确定内容（如一人一个回答），可以增加调研的样本量，或者记录后分析原因。3. 统计个性与共性问题问题汇总后，统计个性问题及共性问题。对于共性问题，一般是我们需要进行重点处理的内容，对于部分个性问题，保持敏感性，特别是用户在回答问题涉及到一些本能（比如涉及到贪、懒等）需求，这类问题可能具备价值点。4. 合理推理对于一些调研结果，需要进行一些合理的推理，以便弄清楚调研结果出现的原因；对一些调研结果进行推理，得出更为合适的结论。有些用户所答问题，并不是实际情况，很可能是用户自己也不清楚想要什么，或者为什么。这时，合理的推理能够解决一些问题。七、需求调研的反馈1. 感谢对参与访谈的人表达感谢，无论是调研结束，还是下一次沟通的起始，感谢别人的配合和帮助。2. 反馈调研结果调研结束后，部分客户或者协调人会期望得到反馈，我们对内容收集整理后，可跟客户保持沟通，及时反馈调研结果（比如后续会进行排期等等）。3. 补充收集内容对于一些问题没有一次性沟通清楚的，可以事后再次联系该被访谈人，了解情况，注意不要时不时问一个问题，可以将问题汇总后，集中沟通，效果会更好（看客户情况，如果双方建立了不错的关系，方式自便）。4. 产品上线反馈（需根据调研沟通情况反馈）对于一些客户在访谈过程中所提问题，已纳入排期计划并上线，可以跟客户保持沟通，并跟进用户使用情况，以便后续的产品优化调整。在总结这篇文章的过程中，结合自身工作中的一些实践，也参考了一些行业前辈的工作经验，比如本站“周伯通”老师的一些文章，对于我学习掌握需求调研方法论很有益处。感谢行业前辈的分享和指导。期望能跟大家一起多多交流，企业服务不是一件容易的事情，希望中国的企业服务能够和国外一样蓬勃发展。本文由 @原始森林 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议

编辑导语：一个产品的开始阶段就是产品调研，因此产品调研质量的好坏对产品来说至关重要。对产品经理来说，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协议

人脉系统V1.0由牛工负责开发。在调查系统需求阶段，他要做的第一件事是阅读人脉系统V1.0需求范围说明书，了解人脉系统V1.0要实现的功能，确定要调查的工作。虽然人脉系统V1.0功能相对简单，无需调查系统相关者。牛工仍然决定要进行系统相关者的调查工作，他把系统相关者分为两类。一类是客户，也就是决定投资开发该系统的人或机构，他需要从客户方了解新系统的背景（为什么要开发这个系统？）、客户对新系统的期望（系统要做成什么样？）、客户对新系统的支持力度等内容；一类是用户，也就是使用系统的人或机构，他需要从用户方了解用户如何使用系统，用户对新系统的期望等内容。调查系统客户牛工首先与客户进行了面谈，投资该项目的客户是人脉科技，人脉科技的贾总与牛工进行了面谈。牛工向贾总提出了三个问题：第一个问题是为什么要开发这个系统？第二个问题是系统要做成什么样？第三个问题是公司对系统的支持力度如何？贾总针对第一个问题的回答：“当前人与人之间的交流更多的是通过互联网进行，通过互联网认识的朋友也逐渐多起来，时间长了，很多朋友就记不清谁是谁了，有必要开发一个系统把朋友的资料给管理起来。另外就是当需要展示自己给陌生朋友时，可以把最好的一面展示给朋友”。贾总针对第二个问题的回答：“人脉系统把与自己相关的朋友、同学、同事、商业伙伴的信息和资料，通过人脉管理起来，并利用互联网技术积极拓展和维护个人的人脉资源”。贾总针对第三个问题的回答：“人脉系统是公司的重点项目，公司的想法是先实现简单的功能，让系统尽快上线。然后再根据用户的反馈分阶段完善系统，根据系统的运营情况，公司会逐渐加大支持力度”。贾总对第一个问题的回答，让牛工明白了人脉科技要研发人脉系统的必要性，人脉系统的核心功能就是基于互联网的社交功能；贾总对第二个问题的回答，让牛工明确了新系统要采用的技术体系，新系统采用BS技术体系，系统部署到服务器端，用户通过浏览器访问和使用系统；贾总对第三个问题的回答，让牛工确定了新系统的开发方式，新系统采用迭代增量的开发方式，在前一个迭代阶段的基础上增加和完善系统功能。和贾总面谈结束后，牛工确定了人脉系统的以下内容：人脉系统的核心功能是基于互联网的社交功能人脉系统采用BS技术体系人脉系统采用迭代增量的开发方式牛工和贾总的面谈确定了人脉系统的技术体系、开发方式和系统研发方向。牛工和贾总的面谈是非常重要的，面谈让系统研发团队和系统拥有者对新系统的研发方向、技术体系和开发方式都有了统一的认识。防止出现系统研发完成后，系统功能和客户对系统期望不一致的问题。小提示：在开发一个软件项目之前，一定要和软件项目的拥有者达成一致。例如，假设公司领导让开发一个软件项目，他只是简单的把项目要求说了一下。你需要先做的事情是把项目的背景、项目的研发方向弄清楚，然后再和领导面谈，核实你对项目的理解和领导对项目的期望是否一致。调查系统用户有社交需求的人都是人脉系统的用户。牛工与人脉科技负责商务的张女士进行了面谈。牛工向张女士提出了三个问题：第一个问题是平时如何管理自己的通讯录；第二个问题是：收集的名片如何放置？第三个问题是：当需要获取朋友的联系资料时，你是如何做的？第四个问题是：如果有一个系统帮忙管理通讯录、名片资料时，你希望这个系统有什么功能？张女士对第一个问题的回答：“我主要负责公司的商务活动，需要联系的人比较多，我一般用EXECL来管理自己的通讯录，当需要打电话或发邮件给联系人时，我会通过EXECL来查找联系人”。张女士对第二个问题的回答：“我从商务活动中收集的名片，一般把名片的通讯资料录入到EXECL文档中，名片也会放置到一个抽屉里，但时间长了就容易丢失”。张女士对第三个问题的回答：“这个问题在第一个问题已经回答了，因为通讯录是EXECL文档，我会从EXECL文档中查找朋友的联系资料”。张女士对第四个问题的回答：“我进入系统应该只能看到自己的联系人信息，名片信息应该能自动识别录入、也可以手动录入，在手机、电脑上随时可以查询通讯录，可以发送个人的数字名片给朋友，朋友间可以互相交换数字名片”。和张女士面谈结束后，结合人脉系统V1.0需求范围，牛工确定了人脉系统V1.0的系统事件，系统在发生如下事件时能进行一些处理：用户登录用户注册用户添加名片用户查询名片用户查看名片信息牛工和用户的需求面谈主要是确定与系统相关的事件。实际上，所有的系统开发方法都是以事件概念开始建模的，调查系统需求阶段主要的工作就是确定与系统相关的事件，并编制事件列表。下节课我们会讨论什么是事件？