非常时期，这家科技公司开始用飞书“逆势招聘”
客户介绍
北京熹乐科技有限公司聚焦于工业互联网领域，专注在轻工行业，推动AI和云计算技术与工业场景的逐步融合，助力传统产业龙头围绕先进制造的数字化升级过程，曾分别带团队带队打造过多款影响过亿用户的科技产品。
以下内容截取自熹乐CELLA
Part 1：疫情期间的我们
2018年末我们开始进入产业互联网和工业互联网赛道。近期推出了一款产品，叫熹乐产业舆图，我们想记录中国这次传统行业数字化的时代进程。团队在北京和厦门两地，远程协作对我们来讲并不陌生。
但长达一个多月的全体Remoting确实还是第一次，所以面对工作，我们开始了一段“招聘Bot”的旅程。而这段疫情期间，我们还协助雨诺股份一起做了些公益——帮助中国几百家药房和几个地区提供在线“口罩预约”功能。这段时间里的收获和感受，在此记录和分享。
Part 2：工具箱Toolbox和“工具箱轴心”
每家科技公司，都一定会有自己的协作“工具箱（Toolbox）”，我们的工具箱文化是把飞书当做“轴心”，以此来定义和连接所有的协作。
我相信每家科技公司都有一个自己的“工具箱”，科技红利往往都是科技公司自身先行享受。
我把“团队日历”定义为协作型组织的首要工具，组织的所有动作都由目标驱动，而目标的最终出口，一定能在日历上体现：与客户的会议、连续出差的规划、产品上线的结点、失误出现时的记录、团队小伙伴们的生日等等，全部都在日历上，她是一个团队成长的日记。
在2019年之前，这个工具箱打磨得还算不错，所有的工具产生的消息Message，我们的协作文化要求都必须统一到一个Message Hub去做汇集。工具的目的是为了提升效率，人使用工具，就会产生内容（Message），随着这个量的越来越大，协作的复杂度开始提升：
工具箱的“熵” = 人 x 工具 x 频率 x 时间
有得必有失，工具的产出结果的直接副作用就是产生信息断层和信息孤岛。在享受单点效率提升的同时，整体上其实面临着复杂度的提升超越效率提升的交叉点。
这也是很多组织一直痛苦为何用了工具后反而带来整体一团乱的原因。所以，必须要找到一个Message Hub，在这里做内容/信息的分类分流和自动化处理，以达到收敛的目的。2013年下半年开始，开始尝试使用Slack来做为我们的Message Hub。
产生的内容/信息总是要持久化存储下来的，Excel、PPT、Word和PDF都是我们离不开的内容格式。文档类必须要支持两种能力：可多人同时协作编写 + 内容要与团队成员可直接Link。
随着团队规模和业务的增长，组织内的角色越来越多，组织内的信息流动越来越快，而为这个工具箱提供流畅的网络的成本在越来越高，我们清晰地感受到这个工具箱开始影响我们的协作效率了。
2018年底，我们遇到了“飞书”这个产品，当时它还没有Public Release，听了“飞书”客户成功团队的一次介绍和演示后，我们决定开始试用这个产品，第一个我关注的功能就是“团队日历”，这个最不起眼的子产品，其实逻辑非常复杂，仅仅是一个多人沟通时间的“排会”功能点，就足够让一众产品经理掉一地头发。也是因为日历逻辑的严谨和细节中体现了对协作的理解，我们也就一头扎进了飞书。
经过15个月的打磨，今天，我们的工具箱Toolbox升级到了2.0版本。
2.0版本的核心理念是“简单、可连接、自动化”。我们全部转移到飞书体系，成本上节省了70%，整个2.0版本的工具箱实现了最简洁的结构，充分利用我们的Serverless平台和飞书开放平台，通过“雇佣”飞书Bot来为我们连接各个平台的信息，这就是我说的逆势招聘，对bot我们也考核能力，也培育她的不断成长。
Part 3：“视域焦虑”
工具是手段，协作是文化。工具是用来实现一个组织的协作文化，反复地打磨改进以不断提升整体效率为目的。
这次疫情引发的“远程办公”潮，给不少人也带来了管理焦虑。比如飞书有一个功能：你在群里发一条信息，旁边会显示群成员的已读和未读状态。这个功能是一个典型的管理双刃剑：用好了，可以基于这种回馈机制做出快速灵活的协作调整；用不好，就会陷入“这几个人为啥不看我消息，工作被卡住了”的焦虑。
来源：国际货币基金组织
在我们的“工具箱”体系里：首先要消除数据断层，将组织内的信息都能在同一个地方汇集和流动起来，降低焦虑感后再有效减少盲点，是我们协作里定下的制度。协作，尤其是远程协作，要“异步化”，给予团队成员信任和尊重，将协作过程异步，减少团队整体的上下文切换（Context Switching），将单点效率发挥到最大。
工具只是手段，协作是一种文化，工具使用是协作文化的表达方式。飞书因为有开放平台的支撑，遇到问题的时候，我们团队的第一思考是：这个问题的本质出现在哪个环节？这个环节我可以写一个飞书Bot使其自动化吗？提升效率的过程我有没有打扰到其他人？
Part 4：熹乐产业舆图
今天，工业互联网相关信息分散和重复地出现在互联网的各个角落，加之信息爆炸后“千人千面”的内容分发形式，使得绝大多数人都只能看到局部信息。尤其是我国的轻工业行业，包含的类目多、跨度大，十分分散，在整个推动实体经济发展的宏观背景下，我们看到的是揣着好技术好产品好服务的公司在打着灯笼苦苦寻找客户，而对方，却也同样绞尽脑汁学习新技术的应用然后打着灯笼苦苦寻找供应商。我们想，能否通过我们的技术和我们对两个知识域都有的认知基础，做一款产品，能让这个领域的信息更低成本的汇集和流动，那就是一件有价值的事儿。
今天，这个领域的信息汇集程度还在下图的左上角，这个产品，希望能让整体状况逐步向右下角推进：
这个平台，需要市场、运营、产品、研发的全部参与，我们尝试用飞书Bot生态解决了一些环节的问题——毕竟每个产品再小，展示给世界的那部分只是一座海洋冰山的水上部分。
Part 5：基于飞书+开放平台的生态快速打造产品
熹乐CELLA团队是Bot的重度使用者。做产品时，UI是最费时间和精力的环节，而产品里“水下冰山”的部分大都具备“小、散、杂”特征，基于飞书及其Bot生态，可以使得很多后台产品不需要再做UI，这相当于我们做传统的CMS类内部产品迁移到了飞书生态上，这对整体架构和协作的复杂度大幅降低：
- 我们用飞书原生的 Bot 帮助运营人员收集部分信息（但这个bot不支持内容转发，如果可以，就可以把内容直接Forward给其他Bot，效率又会上升一大截）。
- Github Bot 这个不用多说，Push、Pull Request、Issue、Actions等信息必须集成。配合一个小工具对齐大家的Github Username和飞书ID，再加上Github刚发布的CLI，简直无敌。
- Google Analytics Bot 每天自动发送各种环境的监控日报，指导运营和产品的灰度和迭代。
随着业务的快速发展，团队压力在增加。我们就开始了招聘“另类员工”——飞书Bot，只要满足以下逻辑我们就自己做成一个飞书Bot，让这名虚拟员工为我们服务：
- 解决的场景里只有一端是分散型的，且将分散的数据汇集整理后对整体有效率提升
- 是重复操作
- 用少量的代码就可以实现这个Bot
- Bot出错不会导致系统性风险
- Bot的表现让2/3以上的人感受愉悦，否则它只能是“个人工具”，不能进入我们的“协作工具箱”
由于中文环境下自然语言处理、关键信息提取等能力AI还有很大的提升空间，当前阶段，为了保证质量，我们在机器处理完第一遍后，还会有运营涉入的过程，最终达到优选的结果——毕竟作为行业从业者，我们每天也要学习这些内容。TLDR-Bot这位小伙伴的职责就是把任何人给定URL，抓取其更丰富的多维度信息，然后塞到数据库的草稿箱里，再通知其他小伙伴另一个环节已经准备就绪，随时可以进入下一环节的处理。
Unix哲学的最大成者我认为是Unix Pipe，这也是我们熹乐CELLA使用飞书生态的核心制度，实践证明，确实收获颇丰，将这些年的实践和思考，成于此文，分享出来。伴随疫情开始的这个Decade，一开局就是Hard模式，而这次长时间的“远程办公”，更像是一面镜子，让我们看到在“协作”这件事上还是有很多可优化的环节，毕竟我们在面对的环境变化速度越来越快，我们的工具箱愈发显得陈旧了。一直在埋头打仗，有慢下来的机会，也是升级兵器的好时机。
