你永远无法说服一个不愿意改变的人，低代码的困境就是这样，同样的低代码工具，对于不同的业务部门的作用完全不同，低代码对于企业本身有比较苛刻的要求，普及之路任重而道远。低代码也很难解决传统需求的路径依赖问题，你要剥夺原来业务部门已经拥有的权利是很难的，但低代码可以解决新激发的需求，数字员工就是典型。如果生产关系改变不了，IT部门搞低代码不要去提什么降本，多提提增效。一般解决不了IT部门 “公地悲剧” 难题，只会激发业务原来没有满足的需求，我们原来搞了自助取数平台，发现人工取数没减少，自助取数飙升，K哥作为一名IT管理顾问，有机会接触到许多公司。不论是大型上市集团，还是中小企业，都面临一个同样的问题：IT部门缺人，需求堆积严重。也许你会说，缺人就招人呀，这还不简单。要知道，企业不可能无限制加人，就算有计划地招聘，你会发现加人的速度永远追不上需求增加的速度，IT部门永远缺人，需求堆积严重，业务部门怨声载道。这个现象就叫做“公地悲剧”。
“公地悲剧”是一个经济学的概念，最初由英国人哈定于1968年提出，哈定说：“在社会当中，当人们面对公有物的时候，每个人都追求各自利益的最大化，于是他们毫无节制地使用公有物，最终导致公有资源的枯竭，这就是悲剧的所在。”举例来说，一群牧民在一个公共草场放牧。其中，有个牧民想多养一头牛，因为多养一头牛增加的收益大于其成本，是有利润的。虽然他明知草场上牛的数量已经太多了，再增加牛的数目，将使草场的质量下降。但对他自己来说，增加一头牛是有利的，因为草场退化的代价可以由大家负担。于是，他增加了一头牛。当然，其他的牧民都认识到了这一点，都增加了一头牛。人人都增加了一头牛，整个牧场多了N头牛，结果过度放牧导致草场退化。于是，牛群数目开始大量减少。所有牧民的如意算盘都落空了，大家都遭受了严重的损失。理解了“公地悲剧”，我们再回到IT部门缺人的问题：IT部的资源，对于各业务部门来说是公用的，因此每个业务部门都想尽可能多的提需求，以占用更多的IT资源为自己开发更多的业务系统，这样对自己是有利的。而又没有一个更高级别的部门来统一管理这些需求的合理性，于是就造成了IT部门的“公地悲剧”。
一、产权是集体共有的。即每个人都对财产的整体具有使用权。我们以IT部门来举例，每个业务部门都可以使用IT部门的资源来开发系统。二，使用权是平等的。即每个人都没有权利干预他人对财产的使用。每个业务部门暂时没有对其他业务部门进行干预的权利，比如财务部门没有权利对市场部门说，你少提一些开发需求，反之亦然。三，财产是有限的并具有使用成本。对业务部门来说增加使用IT部门资源的次数会导致IT资源匮乏，而开发业务需求是需要一定周期的，也就是说在需求排期满了之后，没有任何一个业务部门的需求能够被及时开发出来，IT部门暂时陷入瘫痪了。导致IT部门“公地悲剧”的本质，其实是业务部门不考虑IT部资源的有限性，不断追求自身利益的结果。
简单来说，就是把公有资源转化为私有。当产权有了明确归属之后，产权拥有者就能够对资源的使用进行有效的管理，因为他要考虑这个资源的长久使用的问题，不能够无限制地去使用它。在牧民问题中，把有限的草地进行区块划分，每块土地的所有者都将自主地考虑它未来长久的收益，如果草地只够放养100只羊，他就绝对不会放养101只。因此，作为一个经济理性的人，“公地悲剧”就绝不可能发生。对于IT部门来说，把它拆分到各个业务部门去，也可以解决“公地悲剧”的问题，BAT、TMD等互联网巨头就是这么干的，每个BU都有自己完整的IT团队。这样做有一个弊端，就是资源相对来讲浪费一些，因为没法共用了嘛，但是对于大公司来讲是利大于弊的，他们有的是资源。就是说，还继续保持资源的公共所有制，但是建立一个组织，对资源进行有效的管理。比如国际渔业组织、国际野生动物保护组织，就属于这一类型的联盟。以放牧为例，当人们意识到过度放牧对土地资源的影响是如此严重后，几乎大部分牧民都会同意互相约束不要过度放牧。如果有人胆敢违反相关公约，就要付出相应的补偿。企业内部可以成立类似的公约联盟，来对IT资源进行有效管理。比如“IT资源管理委员会”，由IT部门Leader、业务方Leader及相关领导组成，他们定期进行各业务部门的需求优先级PK，回顾上一阶段已上线需求产生的价值，制定出下一个阶段的需求排期计划。相对来说，这种公约联盟的方式，对IT资源的利用更加充分，所以许多对资源投入比较敏感的中小型公司，更愿意采用这种方式。
在解决工地悲剧的问题上，除了上述两种方法，还有第三种可能：以放牧为例，假设我们能够教会羊自己种草，吃掉多少草自己再种回去，即能够实现一定程度上的资源再生，尽可能少占用公共草场资源，理论上就可以解决“公地悲剧”的问题。回到IT部门资源使用的问题，低代码提供了一种“拖拉拽”就能够实现软件开发的能力，极大降低了软件开发的门槛，让业务人员经过简单地培训就能够自己开发程序，实际上就是让“羊学会自己种草”，使得业务方80%的开发需求都能够通过低代码自己实现，大幅降低对于开发资源的使用，从而解决IT部门“公地悲剧”的问题。
风华新能源的CIO，他自己是车间工人出身，带领7个非科班出身的业务人员， 在氚云上开发了400个业务系统，每天2500多人在使用，支撑起集团9亿多的生意盘子。他们不是什么技术天才，他们只是使用了低代码开发工具，经过2个月就完成了系统搭建。通常来说，开发这样规模的系统，需要一支50人技术团队半年的工作量。
对于IT部门资源使用的问题，除了来自外部“公地悲剧”问题，还需要关注IT部门自身工作效率的问题。因为，随着IT部门人数越来越多就会出现“金字塔上升现象”，也叫做帕金森定律，俗称“官场病”或“组织麻痹病”，是西方管理学三大定律之一。是指职场中，一些管理者并不希望自己的下属能力超过他，认为这样自己的地位会受到下属的威胁。所以在招聘的时候，这些管理者更倾向招一些能力一般，但足够听话的新人。这就极易造成企业既人浮于事又效率低下的现象。长此以往，组织越来越肿，冗员越来越多。想要尽可能降低“帕金森定律”对组织效率的影响，就要通过提升人才密度的方式，在关键岗位上引进优秀人才。因为乔布斯说过：“A类人才，会吸引A类人才，因为A类人才不喜欢平庸的人；而B类人才只会招来B、C类人才。”总结一下，如果你所在的公司，IT部门交付缓慢、需求排期严重，那么大概率是“公地悲剧”造成的。解决的途径有三个：私有产权、公约联盟、引入低代码。同时也要警惕“帕金森定律”对IT组织效率的侵蚀，在关键岗位多引进优秀人才，增加人才密度。最后，需要提醒的是，技术团队效能提升没有“银弹”，没有一劳永逸的方法，优秀的管理者身份永远只有一个，就是学生，而且一直在路上。共勉。
作者简介
Mr.K，国内知名IT管理专家，「顿悟山丘」创始人，科技媒体「技术领导力」创始人。畅销书《技术人修炼之道》《技术管理之巅》作者，曾担任壹药网 技术VP、1号店技术总监。分享个体成长、团队管理、企业数字化转型、IT热点评论。
架构设计：复用是邪恶的
阿里技术人 | “一直写代码会丧失竞争力吗？”
中国为啥没有大的企业软件产品公司
互联网上下50年，万字长文推演Web1.0到Web5.0
2022中国大数据企业50强
项目型IT公司要怎么干才不会死
企业自研系统能拿到市场上去当软件产品卖吗？
查看全部文章
点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！