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

1 评论 4682 浏览 10 收藏 28 分钟

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

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

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

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

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

与生产关系相关的因素:

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

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

举个例子:村子里有最好吃的大米种子,且市场对此大米供不应求,村民都是种地能手;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个领域成为领域专家,这也是笔者当前正在突破的瓶颈。

5. 总结

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

试想一下:

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

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

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

三、业务抽象

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

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

简单举例说明:

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

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

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

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

更重要的是理清楚:

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

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

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

2. 业务抽象参与者

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

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

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

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

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

这里要规避的:

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

四、实体关系建模

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

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

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

举几个例子:

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

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

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

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

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

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

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

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

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

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

1. 总结

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

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

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

好了,终于可以进入产品设计(画原型)阶段了。

等等! 别高兴的太早。

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

五、原型设计

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

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

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

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

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

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

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

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

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

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

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

3. 没有做好设计的badcase

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

六、总结

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

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

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

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

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

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

 

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

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写得好棒!

    回复