“CREAMS被抄袭了怎么办？”
发布时间：
2022-06-23
“短时间能抄出来的是UI和界面，抄不了的是背后的设计逻辑和我们对资管场景的理解”6年前，匠人科技以“CREAMS”命名团队自主研发的第一款SaaS系统，同时这也是国内市面上第一款楼宇资产管理系统，而产品名正是Commercial Real Estate Assets Management System（商业不动产资产管理系统）缩写。此后6年间，不断有客户、学员或者合作伙伴问起“CREAMS被抄袭了怎么办”，而我们的回答始终如一。本篇文章将带大家走进CREAMS团队背后的故事，深度拆解楼宇资管系统背后研发逻辑，帮助大家选好工具、用好工具！
如何将业务需求准确地转化为软件设计？这是所有项目方最本质的需求。无疑，这要求研发团队首先进行大量业务知识的梳理，建立领域模型，再根据领域知识一步步驱动软件开发，这就是匠人科技始终遵循的「领域驱动设计（DDD）」理念。举个简单例子，「可租面积」这个数据维度，在很多项目和开发者而言，下意识这就是“还没有租掉的空置面积”，但在CREAMS系统开发中，我们基于“预招商“的业务场景，在可租面积的范围中加上了那些租客即将退租的房源面积。且考虑到即将退租房源的时间界定，可租面积的意义相对较为模糊，因此我们也在系统中精确到「空置面积」、「可招商面积」。DDD理念可以保证软件开发将关注点放在业务需求上，而非技术。这也给匠人科技垒起第一道防护墙。在DDD的驱使下，匠人科技也自觉承担了更多的责任与使命，基于资管收益增长逻辑，首创了很多新的功能点，例如「计租率」和「流转空置期」。
计租率：计租率 = ∑(房源面积 * 计租天数)/总面积*总时长，客观体现资产经营整体效益，计租率越高，资产运营状况越好，也可将绩效与计租率指标绑定，考核维度更加全面。目前，计租率已被行业广泛关注与使用。流转空置期：指从A公司搬离到B公司搬入的过程中，项目房源的空置天数。流转空置期越少，计租率&租金收益越高。◎CREAMS清晰展示每一房源流转空置期（虚拟数据，仅供参考）页面可以雷同，概念可以直接copy，但背后的技术逻辑和对资管场景的理解不可能抄近路。没有扎实的底层业务架构，后续的迭代将失去内在的逻辑与方向，举步维艰。而匠人科技CREAMS团队始终保持2周/次产品迭代的研发传统，在不断积累的客户实践案例和需求驱动下，这形成匠人自有的、已跑通的产品研发工作流程，支撑着我们陪客户走得更远。毕竟，商办资产管理需求也并非一成不变，而习惯抄袭的团队注定不会擅长思考和创新。匠人科技是产品化的SaaS服务商，有别于项目制公司按照需求提报计算工时和费用、单向性满足客户需求，匠人科技则会基于深入的场景化分析，对需求价值进行评估与反馈，与客户间形成双向的需求交流与探讨。以合同管理为例，不少客户提出过「合同执行期间拆分、合并房源」的需求。事实上，匠人科技在该问题之前便已考虑到相关功能，并提出了更好的解决方案。一般来讲，合同签订之后，除非双方同意修改，否则不应因其他业务操作引起合同变化，房源签合同时，租赁面积、租赁时长、起始时间、单价等都是定好的。此时相比市场上其他SaaS系统的「引用型」设计，匠人科技的房源则是「快照」形式。「快照」就比如，当你在网上购买商品，创建订单时的商品描述、下单信息都会以交易快照的形式保留下来，无论后期商品价格、详情描述如何改变，快照中的信息是不会变化的。同理，合同里记录的房源是房源快照而非房源本身，即使在合同执行期间进行房源的拆分、合并，也不会影响之前的合同内容，对房源的管理、合同的管理也具备了更多灵活性。在6年发展中，匠人科技服务楼宇已超过16000幢，真枪实战地接触、面对过各种各样客户需求，在不断探索、尝试、复盘的经验积累里，我们能有效、成熟地甄别某一需求能否对客户的工作有实质性的帮助、我们是否有更好的解决方案等。基于众多需求做成的产品化系统，普适性更高，面对客户可做到当下即用。这是匠人科技用长时间的坚持和经验垒起的第二道防线。许多商办客户反馈使用别的SaaS软件时常遇到这样的情况：新建一个合同后，因业务需要进行了合同的修改、延期、扩租等等操作后，最终发现数据不准确了，其实问题就出在软件开发水平上。举个例子，客户在年底时看到一个租客租了150方房源，按照这个面积计算，发现最终的收入数字与公司的实际收益有很大出入。原因在于，客户使用的软件只显示租客当下租赁的面积，之前的很多事件流程都丢失了，归根结底是开发人员缺乏业务思考和架构思维，没有做好「事件驱动」（Event-driven）。
而如何做好这些过程数据与事件的记录？财务的复式记账可以为我们提供参考。财务记账需要记录往来双方的信息，这笔钱是谁打给你的？是因为什么打给你的？是收入还是仅为预支款项？复式记账需要把事件发生的过程记录清楚，而非简单的流水进出，这样才能算清公司究竟赚了多少钱。同样，系统开发中如果只记录简单的数字流水，或者只记录最终的数据，也会造成数据的丢失。匠人科技坚持「事件驱动」的开发理念，将业务流程中事件的来龙去脉记录清楚，这样即使将软件逻辑打乱重做，也能凭借这些记录下来的事件按照顺序重新跑通。那么在上一个例子中，客户使用匠人科技的产品就能看到租客的事件轨迹：先租了100方的房源，半年后扩租100方，再过半年退租50方，到年底的时候最终面积是150方。数据与事件都可保证100%的准确度，以及100%可追溯性。但是软件开发水平差的公司不会选择事件驱动。其一，虽然事件驱动的开发好处更多，但同时也要求更复杂的逻辑、更高的开发成本；其二，他们更多的是项目思维和外包思维:开发软件是为了满足客户表面上的需求，而不考虑后期迭代的便利性、功能开发的难易度，不去思考底层架构的问题。匠人科技是国内商办服务商中最早开始微服务架构的公司之一，在六年前行业普遍使用阿里开源的dubbo服务框架时，我们就已基于大量国内外技术调研，开始使用Spring Cloud微服务解决方案，如今已是行业内最为流行和普遍的框架。技术的前瞻性使匠人科技在微服务部署方面一直保持领先。以匠人CREAMS为例，我们将业务相关的服务切分成了楼宇、房源、合同、账单、审核等等众多的服务个体，它们合可撑起整个系统的正常运行，分则相对独立运作，互不影响。与「微服务」相辅相成的是，匠人科技的架构部署又是「容器化」的。抽象来看，CREAMS的整个架构是一个容器，当需要增加新的功能服务时，只需将服务做完后放到容器中即可，并不需要调整容器本身。客户需求量大、需求不断新增是SaaS服务商共同面临的问题，一版软件能够满足客户大部分需求其实是天方夜谭的。因此，要迅速消化客户的各种需求，对软件的架构要求极高。相比之下，那些一体化的软件系统，各个服务与功能之间的关联性和依赖性更大，若想要增加某一个服务则需在代码中新增功能，他们无法确保是否会引发bug，继而对其他模块甚至系统整体运行产生不利影响。匠人科技相比其他SaaS服务商的明显优势在于，我们对微服务架构已有六年部署经验。随着微服务架构逐渐成为主流，我们还需警惕和鉴别“为了微服务而微服务”，他们虽然采用了微服务的架构，但本质上并没有把该切分的服务，如楼宇、租客、合同、账单等等细分开来，而是放进同一个微服务中，架构设计僵硬，难以消化客户需求，甚至还会影响其他功能，使用体验感也会大打折扣。我们相信，技术的质变始终是最重的筹码，埋头做技术，保证代码质量和程序稳定性，在初期将竞争品远远甩在身后，可以让我们走得更稳；而对于商办资管场景不断更新迭代的理解则可以让我们走得更远。“没有人「致敬」的产品也不算好产品，说明它走在正确的方向上。”
关注专属顾问
获取完整资管干货
