很多零代码应用的开发者不是专业的IT人士，不知道该如何收集、整理和反馈需求。因此，本节将介绍如何明确业务需求，从需求出发，以终为始，一步步推进零代码应用的落地。

首先要理解什么是需求，找到在企业和组织内部收集需求的最佳方式，然后有条理地描述这些需求，最后实现需求。

一、什么是需求

简单地说，需求是指基于业务需要，零代码应用必须实现的功能。需求有三个要素：用户、时间和事件。

1. 用户

用户是应用的使用者，所有需求都不能脱离用户而存在。企业应用中的用户可以分为内部用户和外部用户。内部用户就是企业内的员工，亦可进一步分为一线员工和管理者。根据不同的业务场景，外部用户通常是客户、供应商、合作方、监管方等。

在分析场景的需求之前，要明确“用户是谁”。对于业务和管理类应用，往往涉及多个角色的用户，比如费用报销管理应用，就会有员工发起请求、领导审核、财务人员复核、财务人员打款等，涉及的用户也有好几位；又比如供应商管理涉及供应商和被供应企业，这一类应用同时有内部用户和外部用户，在做需求分析时要考虑周全。

2. 时间

所谓的“时间”指的是用户何时会产生需求，以及在什么场景下会产生需求。比如，外勤打卡这个功能，是业务员因出差无法到公司打卡时使用的，这里“出差”就是需求的“时间”要素。梳理需求时，要根据业务流程确定用户产生需求的时间。

3. 事件

事件是指用户在特定场景下的行为。比如，在上文提到的外勤打卡场景中，事件就是员工掏出手机，通过手机的定位功能打卡。

下面再以内部用户常见的一个场景来举例说明什么是需求。假设人事部门想要通过一个考勤应用了解所有员工每月的出勤情况，我们可以梳理出如表3-1所示的需求。

表3-1 考勤应用的需求

需求的三要素缺一不可。如果需求的用户不明确，开发者不知道该选择谁作为流程负责人，会造成权限管理的混乱；如果对产生需求的实际场景考虑不周，会导致应用的用户体验差，使用起来极不方便，甚至产生很多无用和错误的数据；如果事件描述得不清楚，最后开发出来的应用就可能无法解决实际问题。

二、收集需求的方式

在企业中，需求的收集者既可以是IT人员，也可以是业务人员。我们整理了客户企业的零代码开发实践，发现企业内部收集需求的渠道主要有两种：第一种是业务部门根据自身业务需要提出需求；第二种是IT部门根据公司管理制度整理出需求。下面分别举例说明。

收集需求时要了解详细的需求信息并整理出三要素。然而，需求方可能没有三要素的概念，甚至无法完整地表述自己的需求，这时收集者就应该根据需求的类型灵活选择收集方式。总的来说，需求可以分为四类，每一类需求都有相应的收集方式。

1、概念型需求

第一类是概念型需求，需求方只描述了目标应用的大致功能。例如，用户说：“我想要一个财务应用，可以记录资金的进出，按不同的收入分类汇总。”这句话看似提出了一个需求，但是它既没有提到实际的场景和业务，也没有描述“用户”、“时间”、“事件”三个要素。这样的需求还只是存在于用户脑子里的一个模糊概念，仅凭这个概念不可能开发出完善的应用。

对于概念型需求，需要从多个角度补充目标应用的业务内容。这里以上面所述的财务应用为例来介绍。

第一步，厘清业务流程。根据用户的描述，这个财务应用主要包括两个模块：入账和出账，但对于不同的公司而言，入账和出账所关联的业务是不同的，所涉及的流程也不一样。例如，房产经纪公司的入账主要为返佣（佣金回款），出账则包含报销、支付工资和办公楼租赁等；制造型企业的入账包含销售回款、收取售后服务费用等，出账包含原材料采购、支付工资、报销、厂房租赁等。如果不厘清各个业务的相关流程，就无法建立系统需求的基础框架。

再以房产经纪公司为例，其入账包含以下流程：

出账则包含报销、支付工资和办公楼租金三个场景。

接下来，可以绘制思维导图（如图3-1所示），清晰地展示业务流程，整个应用的基础框架也就建立起来了。

第二步，细化需求。如表3-2所示，在基础框架下，根据“用户”、“时间”、“事件”三大要素对需求进行细化。

从表中可以清晰地看到业务流程所涉及的各部门的具体工作，以及各项工作之间的关联和先后顺序。

第三步，明确管理目标。不论是业务管理还是企业管理，不论管理所涉及的业务流程是复杂还是简单，都会有一个核心的管理目标，前面两步做的所有工作都是为这个管理目标而服务的。仍以这个财务应用为例，其管理目标如表所示。

通过以上步骤，我们就把一个模糊的概念型需求转换为业务流程清晰、管理目标明确的具体需求，可以着手开发应用了。

2、问题型需求

第二类是问题型需求，描述了实际业务中存在的问题。例如，某餐饮公司提出：“我们门店原材料的采购和消耗数量经常对不上。之前门店策划了一场大型促销活动，最终因为成本太高，实际盈利并没有增加，但又想不出是什么环节出了问题。能通过开发应用来解决原材料管理的问题吗？”这家公司希望通过开发应用来解决问题，但是他们自己也“想不出是什么环节出了问题”。

对此类需求，要从企业的管理制度和业务流程出发，找出问题的根源，先制定解决方案，然后开发应用，也即先建立制度，再搭建系统，解决需求同时也完善管理体系。这是通过数字化工具解决业务问题的一般路径。

这里继续使用上面的餐饮公司的例子来说明。为了找出促销活动没有带来盈利提升的原因，公司盘点了原材料的数据，发现原材料实际利用率与预计的值差异较大。预计原材料利用率为80%，实际利用率却只有50%出头。原材料转换为成品的过程涉及多个环节：供应商供货——物流送货——仓储——厨房加工——出菜。但是，因为没有记录过程数据，最终也不知道是哪个环节出了问题。

其实，梳理问题型需求，就是思考如何改进管理业务的方式，然后据此找出真实的需求。

首先要定位问题，也就是找出是哪个环节出了问题，找准原因才能实现业务流程的标准化，后续才能搭建应用解决问题。下表列出了这家餐饮公司将原材料转换为成品过程中的问题、原因及对应的改进措施。

根据上表列出的改进措施，进一步补充各业务模块的需求细节，如下表所示

梳理完需求之后，还要验证需求能否有效解决实际问题，这样才能形成闭环。此时，零代码开发具备的灵活敏捷的优势就能得到充分体现——快速上线应用进行测试，然后收集用户的反馈，快速迭代。

3、借鉴型需求

第三类是借鉴型需求，是指需求方希望借鉴他人的系统解决自己的问题，例如，“其他公司的项目管理系统是怎么做的，可以参考吗？”用户提出这类需求，通常是因为其公司本身的管理制度不太规范，或者现有的管理模式存在一些问题，所以希望参考优秀同行的经验。

在工作上，寻找优秀的对标物是一种好方法，很多人认为直接照搬别人的系统设计方案是一条捷径，但是生搬硬套常常会导致事倍功半，因为“好用”的系统都是根据企业自身业务逻辑设计并与之高度契合的。而不同的企业，即便所处的行业与业务模式相同，内部的组织结构与运转模式也不见得一样，业务流程总是会有差异，而这些因素密切影响其系统的架构。因此，要借鉴别家公司的系统设计，首先要看看双方的业务逻辑是否相近，如果是，或许可以参考其设计思路。

其实还有一种更简单的方法：成熟的零代码开发平台上有丰富的模板，涵盖了很多典型业务场景，可以基于这些模板进行二次开发，这也算是在借鉴别人的设计思路。这里以简道云官方推出的设备巡检模板为例来说明。

设备巡检模板是简道云提供一套完善的、体系化的场景模板，适用于制造业的生产设备巡检、建筑业的工程设备巡检、物业管理的基础设施巡检等多个行业的不同场景。想要借鉴该模板搭建巡检管理应用的企业，可以参考以下流程收集需求。

第一步，厘清设备巡检模板的业务逻辑，业务逻辑相符是能顺利复用模板的关键因素，如果不管业务逻辑是否相近而胡乱套用模板，最终开发出来系统可能会很难用。可以从基础模块、操作模块和数据模块三个维度对业务逻辑进行分析。基于这三大模块，对设备巡检模板的业务逻辑进行梳理，结果如表所示。

第二步，对比设备巡检模板与待开发系统的业务逻辑，看二者是否相符：

第三步，借鉴思路，根据“三要素”整理出符合自身业务逻辑且能解决当前实际问题的需求。

借鉴模板设计自身系统的前提是熟悉模板的业务逻辑，并且对自身实际业务流程有清晰的理解，两者缺一不可。如果盲目照搬模板中的模块，可能会得出许多无用的需求，却忽视了实际业务中存在的痛点。借鉴别人的系统，主要目的是参考其设计思路而并非照搬模块，需要时刻注意以自身业务和管理目标为重。

4、潜在型需求

第四类是潜在型需求，即还没有明确的需求，例如用户说：“我暂时也想不起来有什么需求，好像没什么可以在系统上做的。”企业所处的数字化转型阶段不同，对于数字化的认知也有所不同。所以，没有需求往往不是真的没有需求，很可能是还没有建立数字化思维，无法识别需求。对于这一类用户，就需要如第2章所述，先帮助他们培养数字化思维。

根据简道云对企业用户的调研，有超过90%的企业，在使用零代码开发平台进行数字化升级之前，是使用纸质流转单、Excel文档、邮件等方式传递信息和沟通的。他们数字化转型的第一步就是“无纸化，去Excel”，相当于通过开发应用，把业务流程搬到线上。

当员工和领导慢慢习惯使用这些应用处理工作，感受到其带来的效率提升之后，思维方式也会发生变化，遇到效率低下的工作方式时就会思考，能否通过数字化工具（开发应用）来提高效率。这时，潜在的需求便会浮出水面。

通常情况下，需求的收集者会与各个部门员工沟通，因为一个业务场景往往涉及不同的岗位人员，每个人需要执行的操作也不同，所以，刚收集来的需求是比较杂乱的，必须进行整理。那么应当如何整理、汇总这些需求，才能让开发人员快速理解呢？

对简单的需求，可以利用类似下方的表格进行整理。

如果业务流程相对复杂，涉及的协作部门较多，可以借助流程图或泳道图进行梳理。图3-2就是一个业务流程图示例，这种方式能够详细地展示业务流程的节点和协作部门间的配合关系，对于后期设计系统时划分业务模块、分配人员权限都很有参考价值。推荐使用XMind、ProcessOn等专业绘图软件或网站，组件式的绘图方式可以为制图过程节省大量时间。

业务流程图示例

整理需求时无须拘泥于某一固定的表格样式，也不必追求形式上的完美，需求的真实性才是最重要的，采用不同形式只是为了更好地说明需求的内容。

四、需求的预处理

就像做菜之前要对食材进行预处理一样，在开发零代码应用之前，也要对需求进行预处理。很多时候，需求的收集者和应用的开发者并不是同一组人，开发者需要先评估需求的可行性，然后制作模板（原型），和需求方确认需要实现的效果，再根据可行性及需求方的反馈进一步细化需求。需求的预处理是重要的承上启下过程。

1、评估需求的可行性

收到需求之后，第一步就是评估需求的可行性。初步评估时不需要太细致，不需要考虑某个功能具体怎么实现，否则会增加评估的时间，影响与需求方的沟通体验。本来对需求的完善就是很难一步到位的，初步评估做得太精细可能会增加不必要的时间成本。

应该从整体上评估需求的可行性，主要关注两点：一是核心需求能否按照预期实现。核心需求就是业务主线，其他的需求都是从业务主线衍生出来的。例如，企业想要搭建一套进销存应用，那么自动根据商品出/入库情况计算库存就是核心需求，并由此衍生出库存预警、供应商对账等其他需求。核心需求能够按预期实现，应用的开发基本上就成功了一半。

二是关键功能能否顺利实现。举个简单的例子，在生产管理中，订单引入、计划排产、生产报工是业务主线，而将计划排产和生产报工数据联动，实现生产监控就是关键功能。就算业务主线的流程都能实现，但如果最终这个关键功能无法实现，整个系统也就失去了意义。

所以，在对需求可行性的评估过程中，需要重点关注核心需求和关键功能。

2、制作模板展示效果

若需求可行，则可以根据需求框架做出简易模板。基于模板进行沟通，需求方能看到系统最终呈现的效果，如果需求方认为解决方案仍需调整，开发者也可以灵活地修改模板。制作模板时，无须注重数据的全面性和流程细节，但是要尽量凸显系统的操作方式和数据的展现形式，因为前者关乎用户的使用体验，后者关乎用户的管理诉求。

3、持续完善需求

对需求的完善很难做到一步到位。根据简道云的调研，几乎所有用户的系统都是经过反复迭代才达到一个相对稳定的状态的。本书第2章介绍过，相比自行开发和购买标准化软件，零代码开发的优势之一就是敏捷迭代，应用可以即时调整、即时上线，一些简单的功能迭代不到半天就可以完成。所以，应该鼓励持续完善需求，追求更好的用户体验。