“不见天日”的后台产品——组织效率的基础设施

“不见天日”的后台产品——组织效率的基础设施

编辑导语：企业都会有后台系统，后台管理系统是内容管理系统，后台系统记录着各种信息，功能强大，一个好的后台系统可以帮助我们提高工作效率；本文作者从组织效率的角度阐述后台系统的设计原则，我们一起来看一下。

社区里很多后台系统的文章，此篇文章从组织效率的角度阐述后台系统的设计原则，希望可以给你带来耳目一新的体验。

后台系统与组织效率的关系：

企业之所以存在，因为其产生了某种价值；且通过模式设计，平衡用户价值与企业价值并从中获利，企业中的所有人都是为了这个价值的传递而存在。（可参考《俯视职场迷宫-做好你的职场定位》）

因此在：产品价值、商业模式、组织生产力确定时，组织生产效率则是价值传递的最大变量，此时决定企业生产效率核心变量就是组织的生产关系。

与生产关系相关的因素：

• 个人因素——个人管理。
• 组织因素——组织管理。
• 组织协同工具——“后台系统”。

不管效率是来自科学分工，还是协同管理，其落实到实际操作层面都需要相应生产工具来支撑；因此“后台工具”是组织生产关系的载体，是组织效率的基础设施。

举个例子：村子里有最好吃的大米种子，且市场对此大米供不应求，村民都是种地能手；But！镰刀锤子收割机不好使，你说这事咋弄呢。

那么后台系统是如何影响组织生产关系的呢？

举几个例子：

例1：严重缺失的后台系统，让团队协作效率极低。

无财务系统，财务管理全靠EXCEL，从销售，到运营，到财务，到领导，全部靠人工传递，Execl记录；这样不仅会让各个环节的沟通协作效率低下，甚至会直接导致“财务误差”“财务造假”等有损组织利益的后果。

当然是否需要完善支撑系统，还得考虑组织发展的阶段，例如：在产品初期或者创业型公司或者比较边缘的部门，由于优先级和资源有限，只能靠人力线下协同。

比如我经常听到的一些话：“你的产品能不能活过今年都不知道呢，做什么财务系统，先人工搞吧”，“要不先随便整个小工具临时用着吧”。 当然不存在对与错，核心在“权衡”。

例2：繁杂的后台工具，让部门沟通成本陡增。

或许你有这种经历：做一件工作需跨越多个系统，使用多套账号，和多人沟通。——独立工作被系统切割成多个片段。

例3：没有经过高度抽象的后台系统，灵活度低，严重拖累业务发展效率。

年终规划，BOSS：明年的商品组合套餐A+B+C，销售策略X，Y，Z，奖金提成方案Z，为了支撑明年的年度规划，必须在年前完成后台系统的升级支撑。

产研团队加班加点，过年都差点没回家，终于完成了。

3个月之后，商品组合策略，销售策略，提成管理方案全变了；此时小则迭代功能，大则需要改版重构，严重拖累业务发展效率。

市场和管理的变化是无法避免的，而聪明的产品经理需要识别影响变化的最底层因素，然后层层抽象产品设计，为研发提供灵活的架构设计；可以做到随着业务的变化灵活配置，高效迭代。

例4：分散的后台工具，严重损伤用户体验。

• 客户：我要开通xx模块权限。
• 销售：好的，我们可以随时支持不同的模块配置。
• 销售：运营小姐姐你好，麻烦帮忙开通xx模块权限。
• 需求到了公司内部：内部继续传递（运营部门，产品组，中台，用户中心…）

每个部门都有自己重要紧急的工作，这项工作只是各自边缘支撑工作，响应效率必然低下；邮件，微信半天后才回复，甚至完全被遗漏。

于是半天过去，一天过去了…

• 客户：为什么要没有开通？我们要用啊！
• 销售：我TM就想开通一个模块权限，怎么这么难呢？不是你们说可以随时支持开通的吗？

因此从这个角度，“后台系统”绝不仅仅是为了“支撑业务”，而是整个组织效率的核心保障。

精心设计的后台体系——让组织协同效率1+1>2，没有经过深度思考的后台体系——让组织效率1+1<2。

如何规划建设后台体系，才能尽量避免上面的4个例子？下面为笔者的简单总结，如有不足，欢迎读者指教探讨。

• 全局观意识——产品经理进阶必须要有的意识。
• 业务调研——扎入与业务相关的所有团队。
• 业务抽象——把组织复杂的工作关系高度抽象：流程化，模块化。
• 实体关系抽象——结构化，对象化架构建设：面向实施。
• 原型设计——效率第一，行为层体验>视觉层>情感层。

一、全局观意识

产品经理岗位，从初级到高级的过程，某种意义上也是“产品视角”迭代的过程。

1）功能视角

产品实习生/助理：接到某个任务，完成某个功能点的设计。

2）单产品视角

某个产品模块，或者某个产品的负责人：整体规划产品的不同模块的迭代计划。

3）多业务视角

高阶产品经理：不仅仅关注产品本身，与产品相关的：运营，市场，销售要全局关注。站在“整个业务的视角看产品”

4）多产品多业务视角

产品主管/总监：负责多个产品多条业务，权衡企业战略，顾及多个部门。全局规划管理“企业产品矩阵”。

虽然会随着经验，关注的层面不同。但是作为产品经理，哪怕你目前只对一个单点功能负责，如果可以，也一定站在全局的视角思考问题。

产品仅仅是解决某个现实问题而产生某种“价值”，但是实现这个价值需要：识别定义价值（产品）、实现价值（技术/生产部门）、传递价值（市场/运营部门）、交换价值（运营/销售部门）。

而这个从价值定义到完成价值交换的过程，是企业内部不同属性的生产力，通过不同方式的生产关系，使用不同的生产工具协同进行。

因此当产品经理在设计组织“生产工具”时，首先需要有“全局观”的认知高度；哪怕最终交付的成果是受限于优先级和资源瓶颈，而不得不做的取舍，那也是从“组织效率”全局考虑后的取舍。

二、业务调研

1. 找谁调研？

所谓业务调研，就是彻底搞清楚你所做的系统涉及到公司所有相关部门/相关人/相关系统，以及他们的工作内容，工作目的。

比如，如果你做的是一个财务系统，涉及到的系统：商品管理系统、订单管理系统，甚至还有运营/ 销售人员的绩效管理系统、供应链、人力资源等等。

同时涉及到的部门可能有：财务部、商品订单管理部、运营部、HR部、销售部、BOSS团等。

2. 如何调研？——一定要透彻！

还拿财务系统举例：财务最核心的就是“营收”和“成本”，这里只从“营收”端举例。

你可能需要搞清楚几个问题：

• 营收的钱来自哪里？——销售产品/服务，当然也有可能来自投资。
• 销售是如何售卖产品的？如何回款的？

不同的商业模式，决定不同的销售模式。这里我们用ToB的商业模式举例，因为要比toC的模式更复杂。

销售：拜访客户，介绍产品，拿下客户后应该会有下面几步：

【试用】——>【定金】——>【预付款】——>【部分回款】——>【回尾款】

再深入调研你会发现，很多不在主流程之内的操作，比如：【赊销】【垫付】【拖欠尾款】【代理商提成】【代理商压钱】【客户返利】【销售人员为了业绩故意分批回款】，甚至还有“避税”的操作。

回款后资金如何在各个系统和团队之间流动的？各团队的工作目标是什么？这里就不详细举例了。

做过电商后台和财务系统的人都知道，“钱”的事情，1毛钱对不上都可能是个大隐患；这些业务场景你不吃透，那迎接你的不仅仅是各种零散的需求迭代，还有可能是“算不清账的财务危机”

所以：理清楚你的后台工具所有相关方，一定要扎入到业务深处，搞清楚每个相关方的工作内容和目的，这样你的输出才是最“底层”的需求。

值得注意的是：即使你弄明白这些，你也不能从传统的“迎合用户需求”的角度来解决问题。因为你让“销售人员”爽了，其他人可能就“不爽”了。

3. 调研输出

最基础的应该是“泳道图”了。

比如上面举的例子输出的泳道图（例子是虚拟的，泳道图只是粗狂的示意，读者勿深究哈）。

各方同步结论： 由于涉及团队和人员较多，最终输出流程需和大家确定；若某些流程与相关方的利益冲突，需要从组织目标和效率去权衡。

4. 注意事项——业务调研肯定会遇到的问题，划重点

全局观思考各个组织的利益属性和组织的终极目标。

各方利益不一致，例如销售要方便，要灵活多变。管理者要规范，要统筹管理。

一个简单的例子：“不回款就不给发货”。这听起来是理所应当的管理手段。

但是深入销售场景后你会发现：

• “客户要求必须先发货后打款，你发不发？”，
• “代理商压着钱，但是客户已经付了钱，你发不发货？”，
• “客户下礼拜100%回款，但是这礼拜不得不用你们的产品，你发不发？”等等。

此时作为工具的设计者，可不能傻乎乎的去“满足需求”。 还得结合多方需求，用全局视角输出方案。当然聪明的产品经理有办法通过设计兼得“鱼与熊掌”。

所有业务相关者不是你的同事，而是你的用户。

我经常会后台系统产品经理和提需求的业务方争论争吵。甚至吵到领导那去决策。

个人理解，出现这样情况的根本原因：产品经理没有把同事视为“用户”。用户调研，我们都知道“不要听用户说什么，而是探究其背后的根本诉求”。

作为内部需求方，我们的同事也和所有用户一样：不会说出其根本诉求，直接给你他们理解的“解决方案”，说不清具体需求等等；于是你很无奈，让他去想起楚，他不理解，于是带来的就是争论而不是讨论。

试着把同事当成用户，他们本来就是你的用户，那你就需要用户调研的思维主动挖掘其背后的根本诉求；此时你需要去沟通，去理解，并且帮助他整理、归纳、总结、输出； 这样的结果应该是“哇，太棒了，你说的有道理，是这样的，我自己都没想到，这样也可以啊”。

别指望用户和你在一个频道上，而是主动理解别人的话语体系+思维模式。

这是多么痛的领悟，笔者曾需要和销售，运营，财务，教研，HR等多个团队沟通对接；最大的感触就是“每个人的思维模式都不同”“每个人/每个组织的话语体系都不同”，如果不站在别人的思维模式，不站在别人的话语体系去理解沟通；那沟通效率低都是小事，甚至最终得出的结论双方都觉得没问题，实际却南辕北辙。

相信这样的领悟，你们也有很多。

调研要深入到具体的执行人，而不是组长/主观等部门领导。

这点非常重要，很多产品经理都喜欢找组长、主管，但是组长，主管可能是最不了解细节的人；他们只能说过大概过程，不知具体的操作细节；甚至为了体现他们的“专业”会凭直觉给你介绍操作细节。

一定要深入到具体的执行人，操作人，除非你是在给领导做工具。

你需要主动去学习相关的领域知识；比如上面举例财务系统的例子，最基础的财务知识你需要去了解，“企业三张表”“会计学基础知识”等。

如果是给HR或者管理层做工具，最基础的管理学知识你需要去了解，“OKR“KPI”等。

如果是给教研做工具，那教育教学的领域知识你需要去了解，“新高考评价体系”“新教材大纲”“学科学习路径”等。

产品经理——必须是π型人才；博学广知的基础上，深入1~2个领域成为领域专家，这也是笔者当前正在突破的瓶颈。

如果这一层调研没有做好做透，那你的系统给组织效率带来的收益要么就是0收益，要么就是负收益。

试想一下：

你理解的问题是A，设计的流程是B； 实际的问题是A+，流程是B+， 那上线后要么很难用，要么不能用；影响的不仅仅是产研测团队再次改版迭代，更是所有相关部门相关人的组织效率。

而你就是“罪恶的源头”。

深入业务调研，只是第一步，接下来需要把你调研来的“知识”进行分类抽象，指导落地实施。

三、业务抽象

1. 业务流程模块化抽象。

把上面已经被你理解透彻的业务知识层层抽象。

简单举例说明：

例1：最常见的电商后台，模块化抽象后的结果。

如下图（百度下载的），看到这个完善的抽象结果，你应该意识到这是在整个电商业务所有相关组织相关人的工作流程、细节等都已经吃透之后的输出。

举例2：K12资源后台管理系统。

没有这层抽象，团队连精细化分工可能都很困难，当然这一层抽象也是是研发架构的基础。

更重要的是理清楚：

• 每个模块的用户（负责人）是谁？
• 该用户上下游协同者是谁？
• 模块之间的边界清晰吗？对应的职责清晰吗？
• 如何为他们的工作目标提供高效的协同工具？

如果这一层没有抽象好，研发架构灵活性低，重抽成本高这些显性问题都是小代价；而给各个部门带来的隐形协同成本才是更严重的，比如，干一件简单的事情需要登陆多个系统，一件单点工作被拆在多个流程中完成，数据孤岛等。

更严重的是这些隐型成本是很难被组织注意到的，它们藏在组织最底层最隐蔽的角落，“被害者”往往是组织“最底层”执行者；他们从抱怨到习以为常，甚至觉得这是“打工人”理所应当承担的日常琐事。其实都是“产品经理”的问题。

2. 业务抽象参与者

这个环节参与者包含：产品经理、研发经理、业务代表。

业务抽象是业务和研发的桥梁，很多公司要么研发经理等着产品经理自己梳理好；要么产品经理梳理完上一个业务流程后就直接进入产品细节设计，把业务抽象建模的工作抛给了研发团队，这样的结果就是——架构建模脱离了业务领域知识，那设计出来的领域模型固然会和业务有代沟。

业务代表在这个环节参与可能性就更小了，因为：

• 业务人员觉得这不是他的工作，他没理由参与。
• 各方都很忙，能不参与就不参与。
• 产品经理觉得业务调研已经搞定，无需业务过多的参与。

如果产品经理有自信，此时自己的业务知识就完全能代表业务方了，那固然完美；如果不能还是把业务代表拉着一起比较好。

这里要规避的：

• 话语体系一致性，比如模块的命名，保障所有人都是一个理解频道。
• 模块对应的工作职责是否界定明确。
• 管理上的多变性带来的可能影响等等

四、实体关系建模

经历过业务调研、业务建模、输出业务流程图、业务模型图。

下一步绝大多数产品经理都开始进入产品设计阶段了，而在这之前还有重要的一项工作：实体关系建模；当然这一层也需要根据情况而定，可能大多时候的“实体关系”都很明确，就无需产品经理再抽象了。

到底什么是“实体关系建模”，可以解决什么问题呢？ 相信学过软件工程的同学已经知道我要说什么了。

举几个例子：

例1：承接上文还是拿电商系统举例，最简单的例子：商品（SPU）与最小库存单位（SKU）两个“实体对象”之间的关系：

例2：对象与对象之间还会存在关系，关系也会存在属性：

此为笔者遇到的一个真实案例：系统中一份高考试卷的总分和高考的真实总分不同，从而给用户带来不好的体验，如何解决呢？

这个问题如果从产品设计/分数计算规则的思考逻辑是很难解决的，如果有“面向对象”的设计思维，其实就很容易理解并解决。

原因是：高考试卷中有2道选做题，总分只算1题的；但由于系统设计时未考虑到试题和试卷的关系属性，丢了选做题这个关系属性，自然试卷的总分算了2题选做题的，考虑到这里问题也就迎刃而解了。

以上两个例子，不管你在做什么产品设计都比比皆是；例如权限管理，就是要理清楚：角色与权限的实体关系。

如果这一层关系没理清楚，那整个权限体系会极大的降低组织效率，例如：

• 想开个系统权限不知道找谁，咨询了半天耽误了重要工作。
• n个部门，n²个人需要开各种权限都找产品或者运营，严重分散工作精力。
• 申请个简单的权限需要层层审批。
• 换部门，离职后权限管控不及时甚至混乱。

此处对于权限体系的抽象设计不打开讲了，属于任何系统的基本配置，基本功了。

对于“实体关系抽象”的思维，不仅工作，生活和学习中都非常实用，它更是一中结构化思维的“工具”； 也是我在“数据结构”“C++”这些计算机基础课程中学习到最实用的“思维方式”。

如果没有做好这一层抽象，组织效率被拉低可能会体现在这几个方面：

• 很多看似很简单的问题，解决成本却异常的高。比如我上图说的试题与试卷的关系抽象。
• 面对内部流程，管理，人员的多变性你的后台系统支撑效率严重滞后。
• 产品与研发不在一个频道上沟通。

这一层的参与角色毋庸置疑：产品经理+研发团队。且大多时候需要研发主导，只是在很多业务相关性很强的实体抽象上产品经理务必参与。

好了，终于可以进入产品设计（画原型）阶段了。

等等! 别高兴的太早。

严谨的设计还有一个很重要的环节“数据流”设计，但是由于本人比较懒，也比较粗（我说的粗是指性格的粗犷），所以这一层具体工作大多都移交给研发了；不过不做不代表不重要，重要的是你应该具备“数据意识”；你需要清晰的知道“你要哪些数据”、“未来可能需要哪些数据”、“哪些数据需要埋点，哪些需要日志或者业务库记录”，这样研发在做设计的时候才能有目的的设计数据流。

五、原型设计

1. 这里主要说一个原则：效率第一

在说明这个原则之前，先用《设计心理学》书里的观念把设计分类三个层次：本能层、行为层、反思层。

这三层我从自己的角度给个比较肤浅的解释：好看、好用、好爽。

如果还不好理解，我再用男人女人来解释：一见钟情（好看-本能层面），相互协助（好用-行为层面），志同道合（好爽-精神层面）。

好了，你应该理解了；只是需要注意的是并不是一个产品要兼具所有层面，不同产品不同定位，切入点就完全不同。

比如很多“网红产品”核心就是本能层（颜值高），工具类产品核心定位就是行为层（好用第一）；还有一些产品需要从反思层切入，比如很多礼品、奢侈品，用户购买图的并不是好看好用，而是精神层面的需要。

从这个角度理解，后台系统的交互设计原则就很清晰明确了——行为层，好用！效率第一！ 这也是提高组织效率的最核心因素。

2. 那么好用的原则是什么呢？

交互设计就不班门弄斧了，或许还可从下面几个维度拆解：

• 逻辑清晰。
• 反馈明确。
• 异常监控。

可以尝试给自己下个指标：不需要系统说明文档，不需要培训，上线后各个部门小伙伴可以直接使用。

3. 没有做好设计的badcase

• 内部沟通成本高：培训、咨询等等
• 内部干活效率低。
• 人员变动后没人知道怎么用了。

本文从组织效率的角度梳理了后台系统从0到1的搭建过程，这个过程都是基础的方法论，只是提供一个全局观和协同效率的意识；有了这个意识，工作中很多的难题甚至苦恼之处或许都能迎刃而解。

或许本质上：管理思想是管理软件的灵魂，管理软件是管理思想的呈现。

因此如果你是做公司的最后端，做着“不见天日”的后台工具；从这个角度，恭喜你，有机会接触不同岗位，思考跨组织的协同管理，企业效率等管理意识；后台系统需要学习的“领域知识”就是“管理知识”。

一个组织的后台系统有多乱就说明组织集体的“管理意识”“协同意识”有多低。

组织效率必然低，根本原因不是低在工具，而是组织的意识和认知。

以上仅为笔者个人观点，欢迎指教，探讨。

本文由 @乐乐（教育产品经理） 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议