社区里的后台系统设计原则，你知道吗？（上）
社区里很多后台系统的文章，此篇文章从组织效率的角度阐述后台系统的设计原则，希望可以给你带来耳目一新的体验。后台系统与组织效率的关系：
企业之所以存在，因为其产生了某种价值；且通过模式设计，平衡用户价值与企业价值并从中获利，企业中的所有人都是为了这个价值的传递而存在。（可参考《俯视职场迷宫-做好你的职场定位》）
因此在：产品价值、商业模式、组织生产力确定时，组织生产效率则是价值传递的最大变量，此时决定企业生产效率核心变量就是组织的生产关系。
与生产关系相关的因素：
不管效率是来自科学分工，还是协同管理，其落实到实际操作层面都需要相应生产工具来支撑；因此“后台工具”是组织生产关系的载体，是组织效率的基础设施。
举个例子：村子里有最好吃的大米种子，且市场对此大米供不应求，村民都是种地能手；But！镰刀锤子收割机不好使，你说这事咋弄呢。
那么后台系统是如何影响组织生产关系的呢？
举几个例子：
例1：严重缺失的后台系统，让团队协作效率极低。
无财务系统，财务管理全靠EXCEL，从销售，到运营，到财务，到领导，全部靠人工传递，Execl记录；这样不仅会让各个环节的沟通协作效率低下，甚至会直接导致“财务误差”“财务造假”等有损组织利益的后果。
当然是否需要完善支撑系统，还得考虑组织发展的阶段，例如：在产品初期或者创业型公司或者比较边缘的部门，由于优先级和资源有限，只能靠人力线下协同。
比如我经常听到的一些话：“你的产品能不能活过今年都不知道呢，做什么财务系统，先人工搞吧”，“要不先随便整个小工具临时用着吧”。 当然不存在对与错，核心在“权衡”。
例2：繁杂的后台工具，让部门沟通成本陡增。
或许你有这种经历：做一件工作需跨越多个系统，使用多套账号，和多人沟通。——独立工作被系统切割成多个片段。
例3：没有经过高度抽象的后台系统，灵活度低，严重拖累业务发展效率。
年终规划，BOSS：明年的商品组合套餐A+B+C，销售策略X，Y，Z，奖金提成方案Z，为了支撑明年的年度规划，必须在年前完成后台系统的升级支撑。
产研团队加班加点，过年都差点没回家，终于完成了。
3个月之后，商品组合策略，销售策略，提成管理方案全变了；此时小则迭代功能，大则需要改版重构，严重拖累业务发展效率。
市场和管理的变化是无法避免的，而聪明的产品经理需要识别影响变化的最底层因素，然后层层抽象产品设计，为研发提供灵活的架构设计；可以做到随着业务的变化灵活配置，高效迭代。
例4：分散的后台工具，严重损伤用户体验。
每个部门都有自己重要紧急的工作，这项工作只是各自边缘支撑工作，响应效率必然低下；邮件，微信半天后才回复，甚至完全被遗漏。
于是半天过去，一天过去了…
因此从这个角度，“后台系统”绝不仅仅是为了“支撑业务”，而是整个组织效率的核心保障。
精心设计的后台体系——让组织协同效率1+1>2，没有经过深度思考的后台体系——让组织效率1+1
如何规划建设后台体系，才能尽量避免上面的4个例子？下面为笔者的简单总结，如有不足，欢迎读者指教探讨。
一、全局观意识
产品经理岗位，从初级到高级的过程，某种意义上也是“产品视角”迭代的过程。
1）功能视角
产品实习生/助理：接到某个任务，完成某个功能点的设计。
2）单产品视角
某个产品模块，或者某个产品的负责人：整体规划产品的不同模块的迭代计划。
3）多业务视角
高阶产品经理：不仅仅关注产品本身，与产品相关的：运营，市场，销售要全局关注。站在“整个业务的视角看产品”
4）多产品多业务视角
产品主管/总监：负责多个产品多条业务，权衡企业战略，顾及多个部门。全局规划管理“企业产品矩阵”。
http://www.qianxianly.com/data/attachment/forum/20221124/1669240644524_0.jpg
虽然会随着经验，关注的层面不同。但是作为产品经理，哪怕你目前只对一个单点功能负责，如果可以，也一定站在全局的视角思考问题。
产品仅仅是解决某个现实问题而产生某种“价值”，但是实现这个价值需要：识别定义价值（产品）、实现价值（技术/生产部门）、传递价值（市场/运营部门）、交换价值（运营/销售部门）。
而这个从价值定义到完成价值交换的过程，是企业内部不同属性的生产力，通过不同方式的生产关系，使用不同的生产工具协同进行。
因此当产品经理在设计组织“生产工具”时，首先需要有“全局观”的认知高度；哪怕最终交付的成果是受限于优先级和资源瓶颈，而不得不做的取舍，那也是从“组织效率”全局考虑后的取舍。
二、业务调研1. 找谁调研？
所谓业务调研，就是彻底搞清楚你所做的系统涉及到公司所有相关部门/相关人/相关系统，以及他们的工作内容，工作目的。
比如，如果你做的是一个财务系统，涉及到的系统：商品管理系统、订单管理系统，甚至还有运营/ 销售人员的绩效管理系统、供应链、人力资源等等。
同时涉及到的部门可能有：财务部、商品订单管理部、运营部、HR部、销售部、BOSS团等。
2. 如何调研？——一定要透彻！
还拿财务系统举例：财务最核心的就是“营收”和“成本”，这里只从“营收”端举例。
你可能需要搞清楚几个问题：
不同的商业模式，决定不同的销售模式。这里我们用ToB的商业模式举例，因为要比toC的模式更复杂。
销售：拜访客户，介绍产品，拿下客户后应该会有下面几步：
【试用】——>【定金】——>【预付款】——>【部分回款】——>【回尾款】
再深入调研你会发现，很多不在主流程之内的操作，比如：【赊销】【垫付】【拖欠尾款】【代理商提成】【代理商压钱】【客户返利】【销售人员为了业绩故意分批回款】，甚至还有“避税”的操作。
回款后资金如何在各个系统和团队之间流动的？各团队的工作目标是什么？这里就不详细举例了。
做过电商后台和财务系统的人都知道，“钱”的事情，1毛钱对不上都可能是个大隐患；这些业务场景你不吃透，那迎接你的不仅仅是各种零散的需求迭代，还有可能是“算不清账的财务危机”
所以：理清楚你的后台工具所有相关方，一定要扎入到业务深处，搞清楚每个相关方的工作内容和目的，这样你的输出才是最“底层”的需求。
值得注意的是：即使你弄明白这些，你也不能从传统的“迎合用户需求”的角度来解决问题。因为你让“销售人员”爽了，其他人可能就“不爽”了。
3. 调研输出
最基础的应该是“泳道图”了。
比如上面举的例子输出的泳道图（例子是虚拟的，泳道图只是粗狂的示意，读者勿深究哈）。
各方同步结论： 由于涉及团队和人员较多，最终输出流程需和大家确定；若某些流程与相关方的利益冲突，需要从组织目标和效率去权衡。
4. 注意事项——业务调研肯定会遇到的问题，划重点
全局观思考各个组织的利益属性和组织的终极目标。
各方利益不一致，例如销售要方便，要灵活多变。管理者要规范，要统筹管理。
一个简单的例子：“不回款就不给发货”。这听起来是理所应当的管理手段。
但是深入销售场景后你会发现：
此时作为工具的设计者，可不能傻乎乎的去“满足需求”。 还得结合多方需求，用全局视角输出方案。当然聪明的产品经理有办法通过设计兼得“鱼与熊掌”。
所有业务相关者不是你的同事，而是你的用户。
我经常会后台系统产品经理和提需求的业务方争论争吵。甚至吵到领导那去决策。
个人理解，出现这样情况的根本原因：产品经理没有把同事视为“用户”。用户调研，我们都知道“不要听用户说什么，而是探究其背后的根本诉求”。
作为内部需求方，我们的同事也和所有用户一样：不会说出其根本诉求，直接给你他们理解的“解决方案”，说不清具体需求等等；于是你很无奈，让他去想起楚，他不理解，于是带来的就是争论而不是讨论。
试着把同事当成用户，他们本来就是你的用户，那你就需要用户调研的思维主动挖掘其背后的根本诉求；此时你需要去沟通，去理解，并且帮助他整理、归纳、总结、输出； 这样的结果应该是“哇，太棒了，你说的有道理，是这样的，我自己都没想到，这样也可以啊”。
别指望用户和你在一个频道上，而是主动理解别人的话语体系+思维模式。
这是多么痛的领悟，笔者曾需要和销售，运营，财务，教研，HR等多个团队沟通对接；最大的感触就是“每个人的思维模式都不同”“每个人/每个组织的话语体系都不同”，如果不站在别人的思维模式，不站在别人的话语体系去理解沟通；那沟通效率低都是小事，甚至最终得出的结论双方都觉得没问题，实际却南辕北辙。
http://www.qianxianly.com/data/attachment/forum/20221124/1669240644524_1.jpg
相信这样的领悟，你们也有很多。
调研要深入到具体的执行人，而不是组长/主观等部门领导。
这点非常重要，很多产品经理都喜欢找组长、主管，但是组长，主管可能是最不了解细节的人；他们只能说过大概过程，不知具体的操作细节；甚至为了体现他们的“专业”会凭直觉给你介绍操作细节。
一定要深入到具体的执行人，操作人，除非你是在给领导做工具。
你需要主动去学习相关的领域知识；比如上面举例财务系统的例子，最基础的财务知识你需要去了解，“企业三张表”“会计学基础知识”等。
如果是给HR或者管理层做工具，最基础的管理学知识你需要去了解，“OKR“KPI”等。
如果是给教研做工具，那教育教学的领域知识你需要去了解，“新高考评价体系”“新教材大纲”“学科学习路径”等。
产品经理——必须是π型人才；博学广知的基础上，深入1~2个领域成为领域专家，这也是笔者当前正在突破的瓶颈。
5. 总结
如果这一层调研没有做好做透，那你的系统给组织效率带来的收益要么就是0收益，要么就是负收益。
试想一下：
你理解的问题是A，设计的流程是B； 实际的问题是A+，流程是B+， 那上线后要么很难用，要么不能用；影响的不仅仅是产研测团队再次改版迭代，更是所有相关部门相关人的组织效率。
而你就是“罪恶的源头”。
深入业务调研，只是第一步，接下来需要把你调研来的“知识”进行分类抽象，指导落地实施。
三、业务抽象1. 业务流程模块化抽象。
把上面已经被你理解透彻的业务知识层层抽象。
简单举例说明：
例1：最常见的电商后台，模块化抽象后的结果。
如下图（百度下载的），看到这个完善的抽象结果，你应该意识到这是在整个电商业务所有相关组织相关人的工作流程、细节等都已经吃透之后的输出。
举例2：K12资源后台管理系统。
没有这层抽象，团队连精细化分工可能都很困难，当然这一层抽象也是是研发架构的基础。
更重要的是理清楚：
如果这一层没有抽象好，研发架构灵活性低，重抽成本高这些显性问题都是小代价；而给各个部门带来的隐形协同成本才是更严重的，比如，干一件简单的事情需要登陆多个系统，一件单点工作被拆在多个流程中完成，数据孤岛等。
更严重的是这些隐型成本是很难被组织注意到的，它们藏在组织最底层最隐蔽的角落，“被害者”往往是组织“最底层”执行者；他们从抱怨到习以为常，甚至觉得这是“打工人”理所应当承担的日常琐事。其实都是“产品经理”的问题。
2. 业务抽象参与者
这个环节参与者包含：产品经理、研发经理、业务代表。
业务抽象是业务和研发的桥梁，很多公司要么研发经理等着产品经理自己梳理好；要么产品经理梳理完上一个业务流程后就直接进入产品细节设计，把业务抽象建模的工作抛给了研发团队，这样的结果就是——架构建模脱离了业务领域知识，那设计出来的领域模型固然会和业务有代沟。
业务代表在这个环节参与可能性就更小了，因为：
如果产品经理有自信，此时自己的业务知识就完全能代表业务方了，那固然完美；如果不能还是把业务代表拉着一起比较好。
这里要规避的：
四、实体关系建模
经历过业务调研、业务建模、输出业务流程图、业务模型图。
下一步绝大多数产品经理都开始进入产品设计阶段了，而在这之前还有重要的一项工作：实体关系建模；当然这一层也需要根据情况而定，可能大多时候的“实体关系”都很明确，就无需产品经理再抽象了。
到底什么是“实体关系建模”，可以解决什么问题呢？ 相信学过软件工程的同学已经知道我要说什么了。
举几个例子：
http://www.qianxianly.com/data/attachment/forum/20221124/1669240644524_2.png
例1：承接上文还是拿电商系统举例，最简单的例子：商品（SPU）与最小库存单位（SKU）两个“实体对象”之间的关系：
例2：对象与对象之间还会存在关系，关系也会存在属性：
此为笔者遇到的一个真实案例：系统中一份高考试卷的总分和高考的真实总分不同，从而给用户带来不好的体验，如何解决呢？
这个问题如果从产品设计/分数计算规则的思考逻辑是很难解决的，如果有“面向对象”的设计思维，其实就很容易理解并解决。
原因是：高考试卷中有2道选做题，总分只算1题的；但由于系统设计时未考虑到试题和试卷的关系属性，丢了选做题这个关系属性，自然试卷的总分算了2题选做题的，考虑到这里问题也就迎刃而解了。
以上两个例子，不管你在做什么产品设计都比比皆是；例如权限管理，就是要理清楚：角色与权限的实体关系。
如果这一层关系没理清楚，那整个权限体系会极大的降低组织效率，例如：
此处对于权限体系的抽象设计不打开讲了，属于任何系统的基本配置，基本功了。
对于“实体关系抽象”的思维，不仅工作，生活和学习中都非常实用，它更是一中结构化思维的“工具”； 也是我在“数据结构”“C++”这些计算机基础课程中学习到最实用的“思维方式”。
1. 总结
如果没有做好这一层抽象，组织效率被拉低可能会体现在这几个方面：
这一层的参与角色毋庸置疑：产品经理+研发团队。且大多时候需要研发主导，只是在很多业务相关性很强的实体抽象上产品经理务必参与。
好了，终于可以进入产品设计（画原型）阶段了。
等等! 别高兴的太早。
严谨的设计还有一个很重要的环节“数据流”设计，但是由于本人比较懒，也比较粗（我说的粗是指性格的粗犷），所以这一层具体工作大多都移交给研发了；不过不做不代表不重要，重要的是你应该具备“数据意识”；你需要清晰的知道“你要哪些数据”、“未来可能需要哪些数据”、“哪些数据需要埋点，哪些需要日志或者业务库记录”，这样研发在做设计的时候才能有目的的设计数据流。
五、原型设计1. 这里主要说一个原则：效率第一
在说明这个原则之前，先用《设计心理学》书里的观念把设计分类三个层次：本能层、行为层、反思层。
这三层我从自己的角度给个比较肤浅的解释：好看、好用、好爽。
如果还不好理解，我再用男人女人来解释：一见钟情（好看-本能层面），相互协助（好用-行为层面），志同道合（好爽-精神层面）。
好了，你应该理解了；只是需要注意的是并不是一个产品要兼具所有层面，不同产品不同定位，切入点就完全不同。
比如很多“网红产品”核心就是本能层（颜值高），工具类产品核心定位就是行为层（好用第一）；还有一些产品需要从反思层切入，比如很多礼品、奢侈品，用户购买图的并不是好看好用，而是精神层面的需要。
从这个角度理解，后台系统的交互设计原则就很清晰明确了——行为层，好用！效率第一！ 这也是提高组织效率的最核心因素。
2. 那么好用的原则是什么呢？
交互设计就不班门弄斧了，或许还可从下面几个维度拆解：
可以尝试给自己下个指标：不需要系统说明文档，不需要培训，上线后各个部门小伙伴可以直接使用。
3. 没有做好设计的badcase六、总结
本文从组织效率的角度梳理了后台系统从0到1的搭建过程，这个过程都是基础的方法论，只是提供一个全局观和协同效率的意识；有了这个意识，工作中很多的难题甚至苦恼之处或许都能迎刃而解。
或许本质上：管理思想是管理软件的灵魂，管理软件是管理思想的呈现。
因此如果你是做公司的最后端，做着“不见天日”的后台工具；从这个角度，恭喜你，有机会接触不同岗位，思考跨组织的协同管理，企业效率等管理意识；后台系统需要学习的“领域知识”就是“管理知识”。
一个组织的后台系统有多乱就说明组织集体的“管理意识”“协同意识”有多低。
组织效率必然低，根本原因不是低在工具，而是组织的意识和认知。
以上仅为笔者个人观点，欢迎指教，探讨。
本文由 @乐乐（教育产品经理） 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
给作者打赏，鼓励TA抓紧创作！
赞赏
页:
[1]