应用开发第一步：如何做好需求管理？
1. 简介
很多简道云应用的开发者不是专业的 IT 人士，不知道该如何收集、整理和反馈需求。因此，本文将介绍如何明确业务需求，主要涵盖了业务需求的三要素，以及四类需求的收集方式：概念型、问题型、借鉴型和潜在型。强调需求的预处理和持续完善，借助简道云零代码开发的灵活性，实现更好的用户体验！
2. 什么是需求
简单地说，需求是指基于业务需要，简道云应用必须实现的功能。需求有三个要素：用户、时间和事件。
1）用户
用户是应用的使用者，所有需求都不能脱离用户而存在。企业应用中的用户可以分为内部用户和外部用户。内部用户就是企业内的员工，亦可进一步分为一线员工和管理者。根据不同的业务场景，外部用户通常是客户、供应商、合作方、监管方等。
在分析场景的需求之前，要明确“用户是谁”。对于业务和管理类应用，往往涉及多个角色的用户，比如费用报销管理应用，就会有员工发起请求、领导审核、财务人员复核、财务人员打款等，涉及的用户也有好几位；又比如供应商管理涉及供应商和被供应企业，这一类应用同时有内部用户和外部用户，在做需求分析时要考虑周全。
2）时间
所谓的“时间”指的是用户何时会产生需求，以及在什么场景下会产生需求。比如，外勤打卡这个功能，是业务员因出差无法到公司打卡时使用的，这里“出差”就是需求的“时间”要素。梳理需求时，要根据业务流程确定用户产生需求的时间。
3）事件
事件是指用户在特定场景下的行为。比如，在上文提到的外勤打卡场景中，事件就是员工掏出手机，通过手机的定位功能打卡。
4）示例说明
下面再以内部用户常见的一个场景来举例说明什么是需求。假设人事部门想要通过一个考勤应用了解所有员工每月的出勤情况，我们可以梳理出如下表所示的需求。
业务需要 | 应用提供的功能 |
所有员工可以查询自己的考勤记录 | 查看个人考勤的数据看板 |
所有员工按时上报考勤数据 | 在规定的时间提醒员工提交数据 |
所有员工每天不能重复上报考勤数据 | 限制每人每天只能提交一条数据 |
所有员工每天自主上报考勤数据 | 统一、固定、便捷的数据提交入口 |
部门主管可以查询本部门员工的出勤情况 | 供主管查看部门员工考勤情况的数据看板 |
…… | …… |
需求的三要素缺一不可。如果需求的用户不明确，开发者不知道该选择谁作为流程负责人，会造成权限管理的混乱；如果对产生需求的实际场景考虑不周，会导致应用的用户体验差，使用起来极不方便，甚至产生很多无用和错误的数据；如果事件描述得不清楚，最后开发出来的应用就可能无法解决实际问题。
3. 收集需求的方式
在企业中，需求的收集者既可以是 IT人员，也可以是业务人员。我们整理了客户企业的简道云开发实践，发现企业内部收集需求的渠道主要有两种并分别举例说明。
收集渠道 | 示例说明 |
业务部门根据自身业务需要提出需求 | 某铁路公安局下辖数十个下级单位，这些下级单位的管理区域、工作内容和人员组成都不一样，因此需求千差万别，难以依靠 IT 部门逐一调研和评估。 因此他们的数字化系统，除最初的核心应用，其他需求均由各下级单位主动提交，然后再由 IT 部门统一开发简道云应用来解决。 |
IT 部门根据公司管理制度整理出需求 | 某建筑企业计划开展数字化转型，优化管理模式。此前，该企业是以线下纸质单据的方式实现业务流程的，各个部门仅参与流程的某一个环节，无法提出涵盖整个流程的完整需求。 则该企业建设数字化系统时，由 IT 部门收集流程各环节的需求，再开发简道云应用。 |
收集需求时要了解详细的需求信息并整理出三要素。然而，需求方可能没有三要素的概念，甚至无法完整地表述自己的需求，这时收集者就应该根据需求的类型灵活选择收集方式。总的来说，需求可以分为四类，每一类需求都有相应的收集方式。
3.1 概念型需求
第一类是概念型需求，需求方只描述了目标应用的大致功能。例如：
- 用户说：“我想要一个财务应用，可以记录资金的进出，按不同的收入分类汇总。”
这句话看似提出了一个需求，但是它既没有提到实际的场景和业务，也没有描述“用户”、“时间”、“事件”三个要素。这样的需求还只是存在于用户脑子里的一个模糊概念，仅凭这个概念不可能开发出完善的应用。
对于概念型需求，需要从多个角度补充目标应用的业务内容。这里以上面所述的财务应用为例来讲解。
3.1.1 厘清业务流程
第一步，厘清业务流程。根据用户描述，这个财务应用主要包括两个模块：入账和出账，但对于不同的公司而言，入账和出账所关联的业务是不同的，所涉及的流程也不一样。例如：
- 房产经纪公司的入账主要为返佣（佣金回款），出账则包含报销、支付工资和办公楼租赁等；
- 制造型企业的入账包含销售回款、收取售后服务费用等，出账包含原材料采购、支付工资、报销、厂房租赁等。
若不厘清各个业务的相关流程，就无法建立系统需求的基础框架。再以房产经纪公司为例，其业务流程如下：
业务模块 | 涉及流程及场景 |
入账 |
|
出账 |
|
接下来，可以绘制如下思维导图，清晰地展示业务流程，整个应用的基础框架也就建立起来了。
3.1.2 细化需求
第二步，细化需求。如下表所示，在基础框架下，根据“用户”、“时间”、“事件”三大要素对需求进行细化，便可清晰地看到业务流程所涉及的各部门的具体工作，以及各项工作之间的关联和先后顺序。
需求名称 | 涉及的业务流程 | 用 户 | 时 间 | 事 件 |
财务应用 | 返佣（入账） | 业务部 | 与开发商签订合约时 | 确定返佣规则、所有项目对应的返佣方式和返佣系数 |
业务部 | 与客户顺利签约时 | 根据签约金额和约定返佣方式计算返佣金额 | ||
财务部 | 佣金到账时 | 根据签约信息核实到账金额，记录入账凭证 | ||
报销（出账） | 业务部 | 因公费用发生后 | 提交报销申请，录入报销凭证 | |
财务部 | 收到报销申请时 | 审核报销信息无误，根据申请内容汇款，记录出账凭证 | ||
支付工资（出账） | 业务部 | 每个工作日 | 打卡，提交出勤记录 | |
业务部 | 有签约客户时 | 记录业绩数据 | ||
人事部 | 每月 | 根据员工出勤记录和业绩情况计算工资 | ||
财务部 | 每月 | 根据人事部计算的金额发放工资，记录出账凭证 | ||
支付办公楼租金（出账） | 财务部 | 每半年 | 根据办公楼租赁合同支付租金，记录出账凭证 |
3.1.3 明确管理目标
第三步，明确管理目标。不论是业务管理还是企业管理，不论管理所涉及的业务流程是复杂还是简单，都会有一个核心管理目标，前面两步做的所有工作都是为这个管理目标而服务的。仍以财务应用为例，其管理目标如下所示：
需求名称 | 管理目标 |
财务应用 | 方便业务人员上报和查询业绩，数据公开透明，激发员工积极性 |
方便财务人员记录数据、查询账目，提高工作效率 | |
形成财务台账，直观地看到每月资金流水和各账目收入/支出明细 | |
以财务数据直观反映企业盈利情况，给企业管理和业务决策提供数据支撑 |
通过以上步骤，我们就把一个模糊的概念型需求转换为业务流程清晰、管理目标明确的具体需求，可以着手开发应用了。
3.2 问题型需求
第二类是问题型需求，描述了实际业务中存在的问题。例如：
- 某餐饮公司提出：“我们门店原材料的采购和消耗数量经常对不上。之前门店策划了一场大型促销活动，最终因为成本太高，实际盈利并没有增加，但又想不出是什么环节出了问题。能通过开发应用来解决原材料管理的问题吗？”
这家公司希望通过开发应用来解决问题，但是他们自己也“想不出是什么环节出了问题”。
对此类需求，要从企业的管理制度和业务流程出发，找出问题的根源，先制定解决方案，然后开发应用，即先建立制度，再搭建系统，解决需求同时也完善管理体系。这是通过数字化工具解决业务问题的一般路径。
3.2.1 定位问题
这里继续使用餐饮公司的例子来说明。为了找出促销活动没有带来盈利提升的原因，公司盘点了原材料的数据，发现原材料实际利用率与预计的值差异较大。预计原材料利用率为80%，实际利用率却只有50%出头。
而原材料转换为成品的过程涉及多个环节：供应商供货——物流送货——仓储——厨房加工——出菜。但是，因为没有记录过程数据，最终也不知道是哪个环节出了问题。
因此首先要定位问题，也就是找出是哪个环节出了问题，找准原因才能实现业务流程的标准化，后续才能搭建应用解决问题。下表列出了这家餐饮公司将原材料转换为成品过程中的问题、原因及对应的改进措施。
问 题 | 原 因 | 改进措施 |
采购的原材料质量时好时坏，价格时高时低 | 没有建立供应商管理体系，无数据支撑对供应商的评估，无法监控商品质量，查询价格走势 | 记录供应商信息，形成供应商档案； 记录每一次采购信息，以便对供应商进行评估； 记录每次采购商品的价格，制作价格走势图 |
采购的商品到货时常缺斤少两，不知道是发货时就斤两不足还是运输中产生了损耗 | 不能实时查看采购数据和到货数据，无法及时对比 | 及时记录采购信息和到货信息，并对数据进行对比，监控每次到货的情况 |
各门店仓库中的商品进出毫无秩序，既没有做到先进先出，也搞不清楚每月实际的消耗量 | 没有仓库管理体系，无专人负责清理库存，随用随拿，商品的进出明细不详 | 及时记录每次采购到货信息，安排专人每月盘点库存，形成库存台账，核算每月商品的实际消耗量 |
各门店仓库既有自主采购的时令蔬菜和鲜肉等，也有从总库调拨的器材、冻货等，管理混乱，账目不清 | 门店仓库和总库没有形成独立的库存体系，调拨往来均无详细记录 | 总库和门店仓库同步整理库存数据，建立独立的出/入库体系，及时记录双边出/入库商品数量，搭建实时库存查询平台 |
3.2.2 细化需求
根据上表列出的改进措施，进一步补充各业务模块的需求细节，如下表所示
需求名称 | 业务模块 | 用 户 | 时 间 | 事 件 |
门店经营 | 产品管理 | 厨师长 | 不定期 | 根据店内主营菜系，列出原材料清单（品名、种类、品牌、规格、型号等） |
供应商管理 | 采购员 | 不定期 | 根据原材料清单寻找供应商，记录供应商信息（联系人、联系方式、地址等） | |
采购员 | 不定期 | 从供货质量、报价等多个维度评估供应商 | ||
采购管理 | 门店厨师长 | 每周 | 根据当周业务情况提出原材料采购需求 | |
门店采购员 | 每周 | 1.根据采购需求和供应商评估结果确认采购信息，并将采购明细发给供应商联系人。 2.如果可从总库调取物料，则直接把采购明细转交总库进行发货 | ||
总库采购员 | 每月 | 根据经营情况集中采购可长期储存的原材料，入库到总库 | ||
仓库管理 | 门店仓库员 | 每周 | 根据每周采购需求核对到货信息，并将商品入库 | |
总库仓库员 | 每周 | 根据各门店需求调拨发货 | ||
门店及总库仓库员 | 每月 | 对所管理的仓库进行盘点，清点所有物料库存数量，确保数据与实际库存匹配 |
梳理完需求之后，还要验证需求能否有效解决实际问题，这样才能形成闭环。此时，简道云零代码开发具备的灵活敏捷的优势就能得到充分体现——快速上线应用进行测试，然后收集用户的反馈，快速迭代。
3.3 借鉴型需求
第三类是借鉴型需求，是指需求方希望借鉴他人的系统解决自己的问题，例如：“其他公司的项目管理系统是怎么做的，可以参考吗？”用户提出这类需求，通常是因为其公司本身的管理制度不太规范，或者现有的管理模式存在一些问题，所以希望参考优秀同行的经验。此时，往往有两种借鉴方式：
1）方式一：借鉴优秀同行经验
在工作上，寻找优秀的对标物是一种好方法，很多人认为直接照搬别人的系统设计方案是一条捷径，但是生搬硬套常常会导致事倍功半，因为“好用”的系统都是根据企业自身业务逻辑设计并与之高度契合的。
而不同的企业，即便所处的行业与业务模式相同，内部的组织结构与运转模式也不见得一样，业务流程总是会有差异，而这些因素密切影响其系统的架构。因此，要借鉴别家公司的系统设计，首先要看看双方的业务逻辑是否相近，如果是，或许可以参考其设计思路。
2）方式二：基于成熟模板进行开发
这种情况下，还有一种更简单的方法：简道云平台上有丰富的模板，涵盖了很多典型业务场景，可以基于这些模板进行二次开发，这也算是在借鉴别人的设计思路。这里以简道云推出的 设备巡检模板 为例来说明。
设备巡检是简道云提供一套完善的、体系化的场景模板，适用于制造业的生产设备巡检、建筑业的工程设备巡检、物业管理的基础设施巡检等多行业场景。想要借鉴该模板搭建巡检管理应用的企业，可参考以下流程收集需求。
3.4.1 厘清业务逻辑
第一步，厘清设备巡检模板的业务逻辑，业务逻辑相符是能顺利复用模板的关键因素，如果不管业务逻辑是否相近而胡乱套用模板，最终开发出来系统可能会很难用。
可以从基础模块、操作模块和数据模块三个维度对业务逻辑进行分析。基于这三大模块，对设备巡检模板的业务逻辑进行梳理，结果如下表所示：
分析维度 | 分析结果 |
基础模块 | 业务涉及的基础信息，相对固定。 例如，设备巡检时需要记录的厂区名称、设备分类规则等 |
操作模块 | 业务相关的具体操作和流程规范。 例如，填写设备维修单的人员、需要填写的内容、设备维修的提报规则和检验规则等 |
数据模块 | 展示、整理和分析业务数据，帮助发现问题和制定策略。 例如，从维修统计看板，可以看出设备维修的效率；从设备动态看板，可实时查看全厂设备的运行情况，以便对人员安排和生产排期等做出决策 |
3.4.2 对比业务逻辑
第二步，对比设备巡检模板与待开发系统的业务逻辑，看二者是否相符：
对比维度 | 对比结果 |
基础模块 | 对比设备巡检模板和待开发系统的业务逻辑：
|
操作模块 | 对比作业规范和业务流程：
|
数据模块 | 对比数据展示内容和管理目标：
|
3.4.3 借鉴思路
第三步，借鉴思路，根据“三要素”整理出符合自身业务逻辑且能解决当前实际问题的需求。借鉴模板设计自身系统的前提是熟悉模板的业务逻辑，并且对自身实际业务流程有清晰的理解，两者缺一不可。
如果盲目照搬模板中的模块，可能会得出许多无用的需求，却忽视了实际业务中存在的痛点。借鉴别人的系统，主要目的是参考其设计思路而并非照搬模块，需要时刻注意以自身业务和管理目标为重。
3.4 潜在型需求
第四类是潜在型需求，即还没有明确的需求，例如：
- 用户说：“我暂时也想不起来有什么需求，好像没什么可以在系统上做的。”
企业所处的数字化转型阶段不同，对于数字化的认知也有所不同。所以，没有需求往往不是真的没有需求，很可能是还没有建立数字化思维，无法识别需求。对于这类用户，就需要如第 2 节所述，先帮助他们培养数字化思维。
根据简道云对企业用户的调研，有超过 90% 的企业，在使用零代码开发平台进行数字化升级之前，是使用纸质流转单、Excel 文档、邮件等方式传递信息和沟通的。
他们数字化转型的第一步就是“无纸化，去 Excel”，相当于通过开发应用，把业务流程搬到线上。当员工和领导慢慢习惯使用这些应用处理工作，感受到效率提升之后，思维方式也会发生变化，遇到效率低下的工作方式时就会思考，能否通过数字化工具（开发应用）来提高效率。这时，潜在的需求便会浮出水面。
3.4.1 整理需求
通常情况下，需求的收集者会与各个部门员工沟通。因为一个业务场景往往涉及不同的岗位人员，每个人需要执行的操作也不同，所以，刚收集来的需求是比较杂乱的，必须进行整理。
那么如何整理、汇总这些需求，才能让开发人员快速理解呢？对简单的需求，可以利用类似下方的表格进行整理。
业务部门 | 需求类型 | 流程明细 | 岗位人员 |
人事管理 | 招聘需求 | 需求申请 | 各部门经理 |
需求核对 | HR经理 | ||
需求审批 | 总监 | ||
招聘流程 | 简历收集 | 应聘者 | |
简历筛选 | HR专员 | ||
面试邀约 | HR专员 | ||
HR面试 | HR专员/HR经理 | ||
部门经理面试 | 岗位对应的部门经理 | ||
招聘结果确认 | HR经理 | ||
入职流程 | 入职报到 | HR专员 | |
办公物品领用 | 对应部门文员 | ||
办公账户激活 | IT部门 | ||
到岗确认 | 对应部门经理 |
3.4.2 梳理需求
如果业务流程相对复杂，涉及的协作部门较多，可以借助流程图或泳道图进行梳理（如下图所示），便于详细地展示业务流程的节点和协作部门间的配合关系，对于后期设计系统时划分业务模块、分配人员权限都很有参考价值。
推荐使用 XMind、ProcessOn 等专业绘图软件或网站，组件式的绘图方式可以为制图过程节省大量时间。且整理需求时无须拘泥于某一固定的表格样式，也不必追求形式上的完美，需求的真实性才是最重要的，采用不同形式只是为了更好地说明需求的内容。
4. 需求的预处理
就像做菜之前要对食材进行预处理一样，在开发简道云应用之前，也要对需求进行预处理。
通常，需求收集者和应用开发者并不是同一组人，开发者需要先评估需求的可行性，然后制作模板（原型），和需求方确认需要实现的效果，再根据可行性及需求方的反馈进一步细化需求。需求预处理是重要的承上启下过程。
4.1 评估需求的可行性
收到需求之后，第一步就是评估需求的可行性。初步评估时不需要太细致，不需要考虑某个功能具体怎么实现，否则会增加评估的时间，影响与需求方的沟通体验。本来对需求的完善就是很难一步到位的，初步评估做得太精细可能会增加不必要的时间成本。
应该从整体上评估需求的可行性，主要关注两点：
- 一是核心需求能否按照预期实现。
核心需求就是业务主线，其他的需求都是从业务主线衍生出来的。例如，企业想要搭建一套进销存应用，那么自动根据商品出/入库情况计算库存就是核心需求，并由此衍生出库存预警、供应商对账等其他需求。核心需求能够按预期实现，应用的开发基本上就成功了一半。
- 二是关键功能能否顺利实现。
例如在 生产管理 中，订单引入、计划排产、生产报工是业务主线，而将计划排产和生产报工数据联动，实现生产监控就是关键功能。就算能够业务主线的流程，但如果最终这个关键功能无法实现，整个系统也就失去了意义。
4.2 制作模板展示效果
若需求可行，则可以根据需求框架做出简易模板。基于模板进行沟通，需求方能看到系统最终呈现的效果，如果需求方认为解决方案仍需调整，开发者也可以灵活地修改模板。
制作模板时，无须注重数据的全面性和流程细节，但是要尽量凸显系统的操作方式和数据的展现形式，因为前者关乎用户的使用体验，后者关乎用户的管理诉求。
4.3 持续完善需求
对需求的完善很难做到一步到位。根据简道云的调研，几乎所有用户的系统都是经过反复迭代才达到一个相对稳定的状态的。
本书第 2 节介绍过，相比自行开发和购买标准化软件，简道云开发的优势之一就是敏捷迭代，应用可以即时调整、即时上线，一些简单的功能迭代不到半天就可以完成。所以，应该鼓励持续完善需求，追求更好的用户体验。
5. 下一步
在了解如何处理需求后，下一步将进入实战环节，可参考下述内容，从 0 到 1 搭建一个简单业务场景应用。
在完成了简单应用搭建后，可以根据自身需求进行应用的开发。在开发过程中，您可通过下述专题文档来获取部分高级功能的使用技巧、实现方案、流程设置方案等等，进一步提升搭建的效率和应用的使用体验。
序号 | 专题 |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 |
400-111-0890
在线咨询