业务|实战分享——我是如何设计复杂系统的( 二 )

大而全的版本设计周期、开发周期较长，公司的时间成本、金钱成本高；
大而全的版本对于用户来说学习成本、使用成本较高；
若后续需要改动，需要配合改动的子板块较多，改动起来非常麻烦；
市场机会稍纵即逝，太长的研发周期可能会错过一些机会。

我们需要聚焦在用户的主线业务、主要需求，以及公司希望在这个场景上希望做出的创新点、优势上，不要陷入什么需求都可以满足的陷阱中，在资源有限的情况下我们需要做出取舍。
在上图中我列出了司法鉴定的通用流程，我将其作为最小可行产品的业务流程。
司法鉴定过程中不同人需求不同。
比如主管部门能够实时了解管辖范围内鉴定机构鉴定情况、鉴定人希望能够通过系统减少重复操作、收案登记员希望能够更快更好地完成归档认为等等。
且整个司法鉴定流程中所涉及的操作、文书附件不计其数。
但部分操作和文书在实际业务过程中使用到的次数较小，所以在最开始梳理业务流程的时候，我选择性的忽略。
其次由于在这个行业已经有类似竞品，我通过使用分析后，了解到他们更多地将系统聚焦在日常的鉴定过程中。
而近年来随着司法行业大整顿，各大司法机构需要进行重新评审，评审的内容主要是对鉴定文书等资料进行检查、考核，对平日里对文书不重视的机构，面对这样严格的评审往往会出现应接不暇的情况，可能会被停业整顿，甚至吊销执照。
所以我们在解决通用业务流程的基础上，将系统进一步聚焦在“文书评查”板块，也作为我们产品的一大亮点。
【业务|实战分享——我是如何设计复杂系统的】最后如果在业务聚焦时团队内部举棋不定，可以选择最简单的方式，选择优先聚焦在“买单用户”的需求上进行设计实现。
类似钉钉的“买单用户”是老板，实际使用用户是员工，老板最大的需求就是能够实时监督员工、管理员工，以更高效的方式完成工作，所以也才有了钉钉最开始的版本。
三、主线流程和角色梳理在B端业务中，完成一项任务问题需要执行很多操作，但并非所有的操作都是主线业务流程和关键节点。
我认为主线业务流程是完成任务的最短路径，最短路径中的操作就是关键节点，操作是由人完成的，所以关键节点上的人就是关键角色。
比如司法鉴定的主线流程和节点包括：
前期技术服务（预检）——>受理审批——>鉴定实施——>文书出具——>鉴定收尾。
其中涉及到的角色包括收案登记员、鉴定助理、司法鉴定、技术负责人，不同的业务流程由不同的角色参与并完成任务。

文章插图
我们以上我们通过”人+事“的方式，梳理主线流程和关键角色是为了大致了解不同角色职责与执行任务顺序，进而抽象出业务规则和流程。但这样的结果还是非常粗旷，不足以作为我们产品涉及的依据，我们需要进一步梳理。
四、业务流程细化一条主线业务往往会有很多分支任务，这些任务也是完成主线业务的必要条件，所以我们还需要进一步细化主线业务；其次每一次操作必定伴随着信息的输入和输出，所以我们还需搞清楚完成操作的前提条件和产出数据；最后在主线业务流程外，还有很多异常流程也需要我们注意。

文章插图
比如上图是对审查受理阶段进行了细化，在流程上审查受理又需要分为”收案登记“、”初始审核“、”审批受理“、”办理手续“四个步骤，同时可以看到我在表格中添加了另外三列，包括输出文书、必要程度以及备注。上一个操作的输入作为下一个操作的输入，每个步骤的逻辑顺序是不可改变的；”必要“操作是主线业务的进一步细化，”可能“操作”是异常情况的标注。备注里是一些补充说明。