💡 当面临一个业务需求、想要用一个应用来实现时，该如何把业务需求转化为应用功能呢？本文将主要面向没有产研经验的业务同学，来回答这个问题。
步骤总括
250px|700px|reset
- 所有应用都来自用户需求，所以规划应用的第一步是梳理业务需求。本文推荐用讲「用户故事」的方式来梳理需求，能保证把需求描述完整。
- 明确现实世界中的需求后，第二步要考虑在计算机世界中、用什么元素来表征需求。这一步，是把现实世界中的「人、物、事」转化为应用里的「角色、对象、流程」。
- 第三步，给用户呈现一个应用界面，让用户完成业务需求。这个界面可以是桌面端页面，也可以是移动端页面，看业务需要。
Step 1 ：梳理业务需求
再复杂的业务需求都可以看成是小需求的集合。用户是分析需求的出发点。用下面写用户故事的句式，写出你想要满足哪些用户的哪些需求：
🚩 用户故事：作为一个<用户角色>，我想要<完成活动>，以便于<实现价值>
比如，在项目管理场景中：
- Story 1：作为一个<项目负责人>，我想要<创建[项目]，并拆解出多个[任务]，分配给不同的成员>，以便于<项目能快速推进并完成>
- Story 2：作为一个<项目成员>，我想要<反馈任务完成状态>，以便于<合理安排工作时间>
随着业务复杂度的增加，每类用户要实现的诉求会越多，整体涉及的角色也会越多。但基础组成范式是一样的：谁、要做什么、实现什么价值。
关于<实现价值>这部分，在实践时可以省略不写。但一定要记得，每一个用户故事都应该是有价值的，如果说不出价值，那也许可以不实现这个需求。
Step 2：将业务需求转化为应用要素 <人、物、事>
阶段性梳理完业务需求后，我们要把业务需求转化为应用要素。应用的本质是<人> 对 <物> 进行的<事>。<人> <物> <事>就是应用的三大要素。
🚩 应用的三大要素：人、事、物
- 人，也就是「角色」，即用户故事中的 <用户角色>
- 物，即人要操作的事物，也就是「对象」，从用户故事中的[名词]里找这个要素
- 事，即人能做的事情，也就是「流程」，从用户故事中的动词里找这个要素
比如，在项目管理场景中：
- Story 中涉及的用户角色有：项目负责人、项目成员——这些就是该应用的「角色」要素
- Story 中涉及的名词有：项目、任务——这些就是该应用的「对象」要素
- Story 中涉及的动词有：创建项目、拆解任务、分配任务、反馈任务状态——这些就是该应用的「流程」要素
定义「对象」要素——物
🚩 对象需要定义属性，即描述这个「物」需要哪些信息。建议用 excel 表梳理所需属性。
「项目」这个对象的属性包括「 ID、名称、负责人、状态、截止时间、备注」 ，如下表：
250px|700px|reset
「任务」这个对象的属性包括「ID、名称、所属项目、负责人、状态、截止时间」 ，如下表：
250px|700px|reset
上面表格中 A-F 列，就是事物的结构化信息；表格中的 1-4 行，就是事物一条条具体的记录。
这里进阶提一下，<负责人>对系统来说，也是一个对象——「用户」对象，用户的属性如下表。在飞书低代码平台上，这些用户信息已经跟飞书通讯录打通，无需开发者对接和维护。
250px|700px|reset
最后说一下，事物不是孤立存在的，事物之间是有关联。在本例中，多个任务会归属于同一个项目，多个项目和任务的负责人可以是同一个用户。在飞书低代码平台中，对象的关系会如下图直观展示给开发者：
250px|700px|reset
定义「流程」要素——事
🚩 流程的本质，就是对一条或多条记录进行增改删的操作。这些操作可以由人来发起，也可以让系统按规则自动发起。
定义流程，就是定义流程是如何发起的，要经过哪些步骤，最后怎么结束。
上述项目管理场景中，涉及的流程有：创建项目、拆解任务、分配任务、反馈任务状态。
在实际的工作中，创建项目、拆解任务、分配任务这三件事情，有时能一次性完成，有时任务是项目创建后一段时间内陆续追加的。在设计流程时，得把常见的情况都考虑到，设置不同的流程来实现。
250px|700px|reset
针对业务流程，作为开发者，我们要考虑如下三种情况：
情况一：项目负责人<创建项目、拆解任务、指派任务负责人> --> 系统通知任务负责人
情况二：项目负责人<增加任务、指派任务负责人> --> 系统通知任务负责人
情况三：项目负责人<修改任务负责人> --> 系统通知任务负责人
比较优雅的流程设计是，尽量将公共的步骤抽取出来、统一维护。比如上面三种情况的最后一步，可以做成一个独立的流程——只要任务负责人发生改变（增删改都算改变），就给任务负责人发通知。这样就不用在三种情况下，都配置这个步骤了。
250px|700px|reset
定义「角色」要素——人
🚩角色，在现实世界中是一种身份，在软件中则规定了拥有该角色的人 (1) 能做和不能做的事情（2）能看和不能看的数据。
比如「项目负责人」这个角色：
- 能做的事情，也就是功能权限是：管理项目（包括增删改查项目）、管理任务（包括增删改查任务）
- 能看的事物，也就是数据权限是：Ta 作为项目负责人所负责的项目的全部信息，别人负责的项目 Ta 看不了
「项目成员」这个角色：
- 能做的事情，也就是功能权限是：查看项目、查看任务、反馈任务状态
- 能看的事物，也就是数据权限是：Ta 作为项目成员参与的项目、Ta 作为负责人负责的任务
一个用户，可以同时具有项目负责人和项目成员这两种角色。我作为一个项目的项目负责人，可以删除任务；作为另一个项目的项目成员，就不能删除任务。这就是角色的意义所在。
250px|700px|reset
Step 3：用「页面」串起应用要素，给用户操作界面
页面一般有如下三种类型，用来承载「对象」(物) 和「流程」(事)：
🚩 三种页面类型：列表页、详情页、门户页
- 列表页：用来呈现多条数据。excel 表就是最常见的列表页形态。
- 详情页：用来呈现单条数据的详情。员工 Profile 页就是展示单个员工信息的详情页。
- 门户页：用来聚合各种页面的入口页。飞书工作台就是典型的门户页形态。
比如，在项目管理场景中：
针对「项目」这个对象：
- 需要一个「项目列表页」展示多个项目（如下图左）
- 在列表页上，一般有「新建项目」的按钮，点击后触发新建项目的流程
- 在每一条项目上，一般有「编辑项目」和「删除项目」的按钮，点击后触发编辑和修改项目的流程
- 需要一个「项目详情页」展示单个项目的情况（如下图右）
- 在详情页上，同样会有针对该项目的编辑和删除按钮
- 同时，也会有「新建任务」的按钮，点击后触发新建任务的流程
250px|700px|reset
最后，可以给用户提供一个门户类型的页面（如下图），方便用户快速聚焦自己负责的项目和任务。
250px|700px|reset
给你一个应用成品
模板中心中提供了项目管理场景下的应用，欢迎在模板中心内安装并体验：
250px|700px|reset
给你一份步骤模板
到目前为止，本文以一个简单的项目管理场景为例，介绍了将业务需求转化为应用设计的三个步骤：
- 用「用户故事」的句式梳理业务需求
- 用「人、事、物」的方式将业务需求转化为应用三要素「角色」「对象」「流程」
- 用「页面」串起应用要素，给用户一个操作界面
写在最后的话
本文为了可读性，只能以非常简单的场景为例。
看完本文，您可能会说，「就这？！真是听君一席话，如听一席话啊！」
这种反应很正常。将业务需求转化为应用设计，这个过程的方法论本身不难。
难的地方在于，面对一个复杂业务时，对业务场景的理解、对业务数据的梳理、对业务流程的把握，最终更难的是，对业务发展的预判。
而正是这些难点，是作为业务专家的您，能比产研成为更好的开发者的原因。
