B端:少谈产品方法论,多看企业效率本质

0 评论 9766 浏览 28 收藏 20 分钟

近些年,随着组织对敏捷的追求,许多银行IT部门开始尝试产品化,希望利用产品研发的方式,提升内部效率,结果是:玩不转!因而本文将剖析其中的问题,供内部决策者参考。

敏捷产品化一到银行及各种金融机构,各种问题就粗来了:

  • 有PMO小伙伴问:加兴老师,你觉得敏捷真的适合银行吗?
  • 有开发组长在培训课堂上问:我们的系统就只有一两个业务人员用,它也适合做用户画像和产品化吗?
  • 有资深一点的部门经理开始质疑:我们银行的产品在业务,比如说XX贷,说白了,银行的产品就是钱,我们开发部门的产品,就那么几个,网银算一个,App也算一个,我们的系统都是为这些产品服务的。

这话说得很对!

一、手段不是目的,没效率就解决效率

首先来看一下咨询公司敏捷产品化方法论的来源:互联网产品的迭代式开发模式。

这意味着,首先,它得是一个产品,其次,才谈得上用什么方法论来优化开发效率。

于是又有了一些不甘就如此的思想者,苦苦思索,在IT内部寻找“产品”,解决“是一个产品”的问题,拿了手段,忘了目的。然后完全忘了要提升效率这档子事。

在这里我要大喊一声:手段不是目的!没效率就要解决没效率的问题!手段用错,更没效率!

有一些小伙伴就很清醒,我们问:DevOps的行业标准,你们怎么看,达到了几级?

对方回答说:那个标准的高级别,其实是参考互联网公司,不适合我们。

基础级别,可以作为一些通用方法、技术趋势,借鉴一下。越到高级别,由于行业不同、经营运作的本质都不一样,可借鉴和可操作性就越差。

回到前面的一系列问题,产品研发的本质,就是前期高投入,后期规模化销售获得边际收益。

首先,这个系统在商业模式上就是scale得通的,有海量用户在使用它,而不是我们拿人家产品的研发方式,去解决我们只有一两个人用的系统怎么去scale的问题。

产品研发的过程,是高度集成的,过程紧凑、资源集中、决策延迟、减少质量损失。因为这些部分处理不好,就会给上市时间、上市产品质量、客户满意度带来巨大损失。报废一件实验室试验品/生产线上几百个零件 vs. 召回几千几万件已销售产品,哪个损失大?

所以,丰田可以在生产线上出现未解决问题时,任何一个人可以拉动警示铃,让全员停下来解决。而这些到了客户的真实现场,客户只问一句:谁敢在项目有障碍时停下来?一屋子人,没一个人敢说“停下来”。

因为非产品场景下,不停下来,没有几千几万个成品损失,停下来,延误的是几十个关联项目的工期!这种链锁效应谁能承担?

单个缺陷往后渗透,确实会影响波及数个项目的质量,但具体问题具体解决,缺陷是如何引起的?业务缺陷?设计缺陷?编码缺陷?

软件开发内部,接近3/4的效率问题,都是技术、业务性问题,而不是方法论问题。

我随便讲个真实的故事:

  • Think big:你欠缺业务知识,依赖业务人员。你的“产品化”业务接口人也不那么懂业务,他要问他的业务领导。业务领导太忙了,没空管你这档子事,然后,你的产品Backlog都梳理不完整。怎么Think BIG?
  • Start small:你没有分析能力,找不到重点,挖掘不到问题背后的原因。然后,到处都是“高优先级”,拖延了人家业务部门正常的项目流程,态度恭敬地回复你:你的方法好复杂哦。怎么Start SMALL?
  • Move fast:写不出高质量代码……重编码轻测试的软件架构……搞不来自动化测试……缺乏测试有效性……一群人累死了都……还在这里干“快速研发模式”……

因而,不能简单地通过方法论来解决效率问题。你的手段,不能偏离你的目的。

二、强化业务技术能力,你才有效率

我们在组织展开一线调研,大量的团队反馈的关键词就是:业务不熟。

  • 有的说,我们这里新人太多了,业务不熟,所以开发进展很慢。
  • 有的说,一个问题,我们需要业务人员给我们解释、澄清,我们才能确定技术上有没有问题,所以解决问题的过程特别长。
  • 有的说,我们这里人员流动率太高了,不懂我们的业务,所以做得很慢。有的说,一直忙着做项目,业务知识没有沉淀,新人来了不知道该问谁,没有文档,看代码,代码太多,简单的工作也帮不上忙,一个系统谁做的就一直做下去,其它人也做不了,最后这个人走了,其它人遇到新的功能就只能再做一遍,代码看不懂,维护不了。
  • 还有的说,我们这里测试换了一拔又一拔,每次交接版本,都要开发人员给测试讲一遍业务,因为业务理解不深,测试经常啥问题也测不出来。
  • 还有的公司的开发,由于不懂客户的业务又不敢问,经常自我沉思到半夜,四处求助。

业务型系统关键的效率影响因素是什么呢?就是业务知识。换句话说,这个领域的“熟练工”,就是最有效率的。

“因为你是这方面的专家所以可以做这个产品”,竟然成了一种稀缺。可见这个世界有多荒唐。不专业,也能做产品,这才该是大家懂得起的道理。

业务型开发,需要懂技术,但技术能力作为影响因素之一,与互联网的开发技术面对的应用层次是不一样的,业务型开发更重视的是根据业务搭建合适的模块架构,而不是模块内部的构造和0.01%的性能优化。能够做出合适的业务技术架构的,还是要基于深刻的业务理解和高度的抽象概括能力。

前者靠领域积累,后者其实是一种数学思维能力,我见过许多把架构、模块设计得特别精巧的,都有很强的数学背景。

所以,程序员,可能编码的时候数学不重要,要设计架构,数学很重要!

每个业务领域,或企业级领域,需要有这么一个能够统筹业务架构的技术管理者,他对整个企业级架构的开发效率,负责任。

这样的人才,很少,很稀缺,所以组建所谓的平台团队、架构团队,就是一群高级程序员,做出来的东西到底有多少经营效率上的作用,是很难度量的。

连国内技术最强的研发公司,平台组/工具组做出来的东西都得不到产品线认可的,因为离业务越远,离真正的前沿实践就越远,做效率工具,背后的知识是典型的实践知识,是靠实践去积累的,离开实践,你做出来的工具就是废品。

组织要大规模地提升基层、执行层的业务技术能力,才能够大规模的提效,而不是把优化工作压在一两支平台工具型团队上。

三、为什么越来越低效

接下来我们谈谈,道理浅显易懂,熟练了,就有效率。Learning by doing,诺贝尔经济学奖得主阿罗揭示了这个规模收益递增的原理,也是近几年我向客户组织推荐的最重要的方法。把人用起来,让基层干起来!

但企业如何把这种“效率”给丢掉了?

亚当·斯密在《国富论》中写过,分工的结果,改良了劳动生产力。这里面“改良”劳动生产力的1/3部分,就是劳动技能的熟练度。

很多人都说,亚当·斯密的分工理论有缺陷,正是因为这个分工理论,导致了现在分工太细,太细了,结果效率反而不高了,知识型企业,都在致力于解决这个错误的指导制造业的理论。

这其实是很多非经济学专业领域的人士,甚至一些国内“经济学”专业人士一种根本的误解。经济学里讲分工,主体不是我们通常语境下的“分工”的个体。微观经济学的最小单位生产者消费者的抽象概念,不是具体的“自然人”,奥派研究的人的行为,也是人的经济选择行为,不是具体劳动行为。

之前在知乎上看到有人提问:量子力学中,如果是一头猪或一只蚂蚁去观察,还会对观察对象产生干扰吗?

当场疯掉。量子力学中讲的“观察”是用光去照,通过光波散射来确定粒子位置,跟猪、蚂蚁不相关!所以非专业人士把领域术语,拿大众的理解去讲,最后双方都逻辑自洽了,实际上,理解错到离谱。

亚当·斯密的分工,讲的是经营主体的分工,最小单位也是个体经营者,比如农户、手工业个体户(木匠)、加工业个体户(屠户)等等。

不是工人!

我们翻回《国富论》第二页,即使在“分工”模式下,铁针工厂内每个工人都是承担二三门工作的。

所以,企业内部要怎么提升员工技能,是专人专岗,还是一人多岗,还是一专多能,那是内部管理的事,与经济学里的分工,两个词语没关系。事实上,不同的企业都有不同的用人模式。

当前某些企业的内部管理的“分工”阻碍了个人效率,是怎么出现的呢?就在于它并不是以效率优化为目的的分工,而是让管理更方便——为资源分配服务——把组织内的各种资源,分配给各个岗位人员操作。

国内第一代信息化系统,OA,是干嘛的?就是管理各种审批流程。

90年代、2000年代的IT人员,学的 hello world 系统,就是请假审批。企业信息化1.0甚至2.0,都不是为经营效率服务的。

这个大背景就是国企管理,计划经济,按计划配供给,讲究的平均;公平公正都做不到的,哪有什么效率?效率是完全不存在于计划经济情境下的,因为市场经济,才是使用市场作为手段去优化资源配置,提升效率。

资源配置优化效率,是市场才特有的概念。

亚当·斯密的(企业化)分工,还建立在一个基础上,就是企业A生产产品P,相对于企业B生产产品P,更有效率,企业B生产产品Q,相对于企业A生产产品Q,更有效率,于是A只生产产品P,B只生产产品Q,得到了更高的总体劳动生产力,然后两家交换一部分PQ,都享受到了这个生产力提高的结果。

其实这才是亚当·斯密分工理论的真正缺陷。

这个缺陷早在300多年前,就被李嘉图发现了,然后又被他自己给解决了。

这个缺陷就是,如果A生产P和Q,都比B更有效率,那么A是自己生产两种产品更有效率呢,还是只专注于生产P,让B去生产Q,才更有效率?

通过李嘉图的计算,结果还是A生产P,B生产Q,更有效率。这就是比较优势理论,通过分工合作,A在B生产Q基础上获得了比较成本优势,相对于自己生产Q,拿自己生产的P去换Q,更有优势。

很多企业由于没有搞懂这个原理,什么都干,最后没效率。

但是李嘉图的理论也是有缺陷的。和亚当·斯密一样,他没有办法从当时的经济环境中看到未来可能发生的事。

亚当·斯密局限在一国一地区,看到的A、B在不同产品成本优势,李嘉图局限在多国产品贸易,看到的强国对弱国的全面生产力优势,和与弱国贸易的比较优势。

局限在哪里呢?当时的国家环境,是不允许劳动力跨国迁移的,只能贸易产品,企业主不能去别国开办工厂,劳动力也不能去别国打工,除非你是搞黑奴交易的——也许这也解释了为什么黑奴贸易在那个时期如此盛行,需求啊!

就是说,更高的劳动生产力,更高的效率,是和经济环境密切相关,和具体哪国人,不相关!

经济全球化之后,企业可以选择在其它国家生产,人力资源可以跨国转移了,富国可以利用自己先进的生产效率,加上穷国廉价的劳动力,最大化获取利润,所以,富国更富,穷国只能用工作时间换取工钱,拿不到利润分配,比较优势理论中的两国互惠受益的情境也不复存了,穷国没有坚强的壁垒,就是没有完整的产品价值链,没有产品交易的基础!

我们回到企业效率。为什么有的企业没有效率?

就是因为你的效率被转移了:高效率员工的流失。

许多技术基层员工,根本就不愿意学习业务,因为他享受不到业务熟练的好处。互联网企业对传统IT最大的区别,就在于互联网有独立的经营,技术是直接可以通过产品运营转化为收入和利润,而传统IT没有转化,摆在技术人员前面就是两种选择:

  1. 学业务,没有明显的收益。
  2. 学技术,未来跳槽到能够独立完成技术经营的公司去,取得至少两倍的收益。

显而易见,大部分技术人员会选择后者,传统企业的技术效率,就这样被竞争掏空了。剩下的,就是纯粹的工时效率、流程效率,蜕化到200年前的工厂生产线,技术人员成了小时工、操作员。

不要拿现代制造业比,无人工厂、自动化制造,哪一样是IT业能想象的?

谈开发效率低的时候,应该想到,是你的公司,被时代的效率超越了。

至于岗位叫什么名字,叫项目经理还是产品经理,叫BA还是PO,在没有真正的专业化、没有优秀的人才之前,无疑就是小作坊!

四、如何提升效率

1. 建立有竞争力的分配制度

一家真正希望改变现状的企业,需要重新审视自己的资源分配制度,把收益分配,向希望提升效率的部门倾斜,否则,本文的标题应该叫作“如何节约成本”。效率,永远和一家企业的竞争力挂钩,企业不需要在每天清理多少次垃圾桶这种事情上讨论讨论效率问题。

2. 识别和管理核心人才

很多企业拿岗位来作人才判断。这没错,互联网公司也用岗位来招聘啊。但区别在哪呢?

在于级别和人才能力挂不挂钩。比如去看一下互联网公司的招聘,JD上会说,我们的要求是多少级,对标BAT大厂的多少级,这样猎头、人力资源就好去直接找人。

而传统企业并不知道、并不能评价这个人才的级别,他们的JD,这个级别要求是很模糊的。

梅西叫前锋,武磊也叫前锋,你要找个前锋,到底是找梅西还是武磊?

当你按照旧的企业管理思路,找来的人,甚至找来帮你解决问题的人,都不胜任,只是在现行规则下,搞搞形式,效率就变成了无解。

把这个问题想清楚了,就基本上解决了“为什么我的XXX玩不转,效率不高”的问题了。

 

作者:陈加兴,场量科技创始人,资深敏捷精益专家,精益企业认证产品概念领导者,微信号:one-oracle。

本文由 @陈加兴 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!