看了一圈，谁都没说到点儿上
胡布斯是纳闷儿，把组织机构绑在应用上，为什么会有这样的需求呢？
其实特别简单
我给你讲一个故事哈，在很久很久以前……
一个活字格的用户，好不容易开发了一个应用出来，卖给了一家企业，这时，产生了三方：活字格官方，活字格的开发者，应用的使用者。
从活字格的开发者的心态来说，他不希望最终用户知道活字格，因为太简单了，客户如果拿到了工程文件，很可能自己搞了，最终用户越是小企业才越会鸡贼，我这里说鸡贼并没有骂街的意思啊，只是对一种行为方式的形容，什么叫鸡贼呢？就是客户有冲动甩掉开发者自己干，总怕开发者挣了他的钱了，完全不顾开发者付出了多大的努力。如果最终用户是大企业，本着各管一摊，又有合同约束，反而会跟开发者长期合作而不会甩掉开发者，因为甩掉开发者的风险极大，万一审计、巡查来了，有开发者挡着还有个甩锅的，你把开发者甩了，锅你就自己背着吧。
好了，因为最终用户是个小企业，可以说是一点儿技术能力都没有，这个小企业可能是一家出租车公司（说到这儿，胡爷是不是有感觉了？），可能是一个小机械厂，可能是一个小食品作坊，这个”小“，可能只有几个人，也可能有个十几、二十来人，也可能会有一定的组织机构，而且小企业往往还愿意搞出一套机构来，好让他的甲方觉得他很正规，以此树立合作的信心。
因为这个小企业没有技术能力，就会委托开发者来进行部署和运维，而开发者也很愿意在研发的基础上再挣一份服务器运维的钱，还有最重要的——
以下才是最最重要的——
开发者不愿意把工程文件交付给甲方，由甲方的技术人员安装部署。你知道把工程文件交付给甲方意味着什么吗？意味着开发者自尽了，因为这个工程文件必然会流出去，开发者辛辛苦苦的劳动，轻易地被人拿走了。
正是这个原因，所以，开发者会怎么办呢？
开发者会租用一台云服务器，向活字格官方购买相应的用户数，然后帮助（或者说代替）甲方把工程文件发布在云服务器上，并向甲方提供运维服务。当然，用户数、服务器的租金最终都是由甲方来承担的，本着雁过拔毛的原则，开发者肯定会加一点点价的，但是这可绝对不可耻，我相信加的那一点点价，真的是一点点，就如同冬夜天桥上卖头绳的老奶奶加的那点价一样，连糊口的钱都算不上。
而在这整个过程中，甲方都始终不知道活字格官方的存在。
在传统商业上，开发者相当于零售商，活字格相当于厂家，最终用户相当于顾客。零售商当然不希望顾客直接从厂家购买了，对不？
可是，这也并不能说，就需要把组织机构和用户绑定到应用上啊？
不，现在开发者碰到了一个麻烦。
我们可爱的甲方，我们的最终用户，只肯付出5个用户的授权价格，这时，开发者就尴尬了， 因为开发者从活字格官方购买授权数时，是一口气儿买了20个的，现在客户只肯出5个用户的钱，这怎么办？
其实这难不倒开发者，开发者只要能再找到一个客户，再做出一个应用来，而这个客户肯付出 15个用户，那么开发者就能把所有的用户数都卖出去了。
这个客户还真被开发者找到了，第二个应用也顺利开发出来了，而顺利部署上线了。
此时，在这台开发者租用的服务器上，有活字格的20个用户授权，部署了两个应用，一个应用5个用户，另一个应用15个用户，一个应用对应着一个做微商的宝妈，另一个应用对应着一个异型轴承加工厂。
突然有一天，那个做微商的宝妈家的布偶猫跳上了键盘，宝妈的电脑没有如愿进入她的客户界面，而是出现了一个轴承……
这就是原因。
你再往下想啊，开发者是继续再开发另外一个新的应用更好呢，还是把这两个已经开发完了，各有了一个用户的，已经部署上线的应用——再卖出一份去更好呢？
哪个策略对开发者来说是更优解？
万幸，开发者又卖出去了一份，又有一个类似业务的轴承企业购买了开发者的应用，开发者又向活字格官方购买了20个用户授权，并且分配给第二家轴承厂了15个用户数，这时，在这台服务器上，已经有3个应用了，一个宝妈的CRM，两个轴承厂的工艺数据应用，还有开发者手上没有消耗掉的5个用户授权。
这时，开发者发现，他可能碰到麻烦了，因为，两个轴承厂各有各的组织机构，而活字格的服务器只有一套组织机构和用户系统。
开发者向活字格官方反映了这个问题，可是反馈的信息给开发者感觉却是官方在敷衍他，而且官方也并没有真的想解决这个问题。
好在这个问题通过一些骚操作还是能解决的，只是手工赋权麻烦一些罢了，而且有一个轴承厂总换人，向开发者提了好几次了能不能向他们开放，让他们自己就能管理用户。开发者心说，不行啊，你一登录管理控制台，有哪些用户不全者看见了吗？只能各种敷衍用户。
而另一边，胡爷一边喝着咖啡一边纳着闷儿，一边自言自语：“我就奇了怪了啊，你说，吃不上饭，他为什么不吃肉糜呢？“
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图
