员工|餐饮系统大拆解：用类图拆解员工结构与工作职责（1）车机系统|驾驶技术|吉利旗下

编辑导语：利用类图这一方式，产品经理可以更清晰地梳理设计思路，进而推动后续方案的迭代优化，同时结合类图梳理，团队内也能降低沟通成本。具体应该如何拆解？本篇文章里，作者结合餐饮系统，对类图拆解和梳理做了案例上的总结，一起来看一下。

文章插图
学了UML的知识后，还要多看案例。下面我们就来拆解餐饮系统，该系统是餐厅用的点餐、预定和外卖等业务的系统，我会分成几篇逐一拆解。
该系统大致可分为：

面向企业的：财务管理、物资管理、员工管理。
面向用户的：用户管理、交易管理（含点餐、预定、排队）、营销管理。
面向数据的，即通过数据帮助企业决策。

本次，我们梳理的是员工结构与工作职责。而你需要有《图解产品》一书的知识背景。
一、梳理人员结构与工作职责要设计餐厅系统，就要考虑清楚该餐厅的涉众（利益相关者）有谁，以及涉众中的参与人（使用系统的人）有谁，并梳理清楚参与人的工作职责。如何梳理？
这些内容在《图解产品》一书中都有。大致方法是你需要用三个角度找全涉众，再从其中明确参与者，这些参与者就是用系统的人，这之后再通过四个调研方法找全工作职责。
下图就是我用该书方法，梳理出来的内容：

文章插图
该图就是一个类图，表达了服务员、厨师、店经理人等之间的关系，以及他们的工作职责。如表达了服务员、厨师都是员工，并且都有姓名、地址等内容，但各自的工作又不一样，如厨师负责做菜，服务员负责送菜。
二、为什么这么梳理？1. 指导后台的原型后台要创建员工，那么每个员工既要有一些公用字段，更有一些特有字段。如每个员工都有年龄、性别等，但是厨师长还要有健康证、厨师等级等内容。通过该类图，就可明确后台新建员工时要填写的字段。
2. 明确要实现的业务产品经理只有知道了每个员工的工作职责后，才能再说如何设计业务。通过这个类图，就可知道各自工作，从而再将部分工作在线上完成。
3. 方便研发的实现类图是严谨的、无歧义的。研发也非常清楚什么是类，以及这些符号的意思，这样就便于研发构建数据库。其实这个图即使你不画，研发也会从你的原型图中抽象出来，但这样做就增加了沟通成本。
三、是否都要画？如何梳理？1. 是否都要画？画到多详细？这要基于目的、受众、阶段、业务复杂度等方面考虑。而本图是一个中型系统常见的内容。
该图和实战中不同的是，梳理的角色略少，没有老板、财务等角色；列出的员工信息也略少，没有列出每个员工的特殊字段。
2. 如何梳理？梳理清楚类（厨师、服务员等）是产品经理功底的表现，这些类大致等同于职位名称，但并不总是如此。更准确地说应梳理工作职能块，而不是职位名称。
这其实是领域建模的范畴，而设计复杂中台和SaaS的核心知识就是领域建模，但限于篇幅这里不做展开。
四、符号的含义是什么？在《图解产品》一书中用了30多页讲了类的知识（信息结构一章），你要看书才能理解为什么叫类，以及符号的含义和梳理类的方法。本文仅就书中未讲到之处做补充。
1. 继承关系继承关系是指一个类（服务员）会继承另一个类（员工）的属性和行为。表达方式如下图。
在该关系中，服务员也被称为子类，员工被称为父类（超类）。子类拥有父类的所有属性与行为，但子类却有父类没有的特殊内容。