数字化：多维表格在产研管理中的应用

在团队全面导入飞书后，产研团队的数字化能力其实面临一次非常大的升级机会。经过大概1年左右的摸索，我们从传统的、多地散落的信息化系统，全面转入到了飞书生态，而且基本上不需要花钱，但是整个效率却提升了至少10倍，团队内外都一致认为飞书的Slogan——「先进团队，先用飞书」真不是吹的，只要有心，完全可以零成本搭建一套高效、体验流畅的产研数字化体系。

1. 产研的传统信息化模式

在传统的产研管理流程中，大概会包含如下关键节点，每一个节点，都需要一套独立的系统支撑，作为团队负责人，最头疼的就是这些系统之间的连接和互动，通过一些手段，当然也勉强能用，但是体验到飞书生态的流畅感以后，几乎很难回去了。

以上这个表格，当然有它的背景，当时公司的办公信息化基建为钉钉，但是仅限于流程审批、考勤打卡等关键场景，其他的信息化如何玩，全凭部门自己弄，作为产研团队，在信息化上的需求和敏感度会更强，所以我们其实在2018年就引入了语雀——非常早期的用户了，当时看来，语雀是个非常牛逼的产品，可惜用现在的视角来看，与钉钉的协同性还是不够。我们当时面临几个问题：

1. 系统太多，每个系统都是一套账号，最直观的感受就是体验还是比较差——当然，当时是不自知的。
2. 因为各个业务系统间的数据不是互通的，信息效率是非常低的，这个也是在局中而不自知。
3. 钉钉的信息底座价值没有发挥出来，上面的系统都是自成一套，没有与钉钉集成，很多消息机制还停留在人肉口播或邮件等落后的方式上，而「消息」绝对是提升体验流畅度的关键因子，又一个身处局中而不自知。
4. 最重要的，就是完全没有协同理念，现在深入人心的「文档+评论」的协同理念，实在太优美。当时团队的状态是用工具（信息化系统）完成一项任务，思维还停留在「单个任务执行」阶段。

2. 最新的产研数字化模式

我们刚开始尝试使用飞书的时候，是从「飞书文档」这个产品开始的，其实它就是对标了语雀文档。飞书文档有几个在体验上无法拒绝的产品特性：

1. 编辑实时性。文档这件事情，如果还停留在Word时代的思维上，你不会觉察到「实时性」是一个多么重要的需求。我是如何觉察到自己对「实时性」的巨大需求的呢，是因为当时我需要异地管理，我的Base在长沙，而北京有个团队也划拨到我这边，让我来进行远程管理。我经常需要和北京的产品经理进行远程沟通，这个沟通不是简单的说话，而是要基于某个具体的议题，一起进行设计，设计工作的一大部分是进行画图、文字批注，飞书文档的实时性非常好的满足了我们这个需求。我们经常干的事情就是开启飞书的视频，然后共同打开一篇文档，我会在文档上进行一些架构图的绘制，远在北京的同学可以直接实时看到效果，几乎没有延迟，这个体验与大家坐在办公室一起讨论方案是没有任何区别的，就是这样的一个点，我们就被深深的打动了，于是不知不觉就对这个产品产生了依赖。
2. 评论实时性。对于一篇文档，遇到有疑问、有异议的部分，我们可以很方便的对这段文字发起一个评论，并「@」对应的人，飞书会非常流畅的把这个「@」推送到对应的同事。这是一个巨大的创新，虽然本质上并不是什么创新，但是组合到一起，对我们的工作模式而言，就是一个巨大的创新。它隐藏了两个要点：
   1. 评论，大家都有，最古老的Word就有，语雀也有，不是什么新的东西，但是你评论以后，对方如何知晓呢，你通过什么样的方式告知对方呢？Word的做法是，把Word再发到群里去，你自己打开看吧！语雀的做法是，你登陆了语雀的时候，系统会有个「未读消息」提醒。但是，如果是这样的话，评论的价值被极大的打了折扣，根本没有发挥出它的价值来，仅仅只是做了一个意见表达，当对方要和你再次Battle的时候，不知道啥时候去了。
   2. 而飞书，将「评论」插上了一双翅膀，它在一篇文档产生评论的时候，会往文档的所有者发生通知消息，会往被「@」的人发送一条通知消息，这条消息是一个飞书的IM，消息是实时推送到对方的，对方会第一时间阅读到这条评论，并可以再次发起评论；于是文档上会出现基于某个确定议题的长长的评论列表，整个讨论的过程全部被留存了。

这个体验，生生诠释出了一个词的份量和体验：「共创」。这种体验，就是传说中的你用了就再也回不去的体验。毫不掩饰的讲，「飞书文档」就是飞书产品矩阵中的尖刀产品，用这个可以把用户协同体验扎得透透的。

说了这么多，我们现在产研部分的信息化体系是怎样的呢？

可以看到，出了产品设计、UI设计这两个专业性太强的领域，其他的产研过程，我们全部用飞书文档+多维表格+飞书知识库基本上就解决了，这套东西的体验是高度一致的，组织、消息、数据全部打通，工作体验极佳。

3. 案例：用多维表格做缺陷管理

在缺陷管理领域，我相信测试的同学一定逃不开「禅道」这个产品。不可否认，它是一个优秀的项目管理产品，但是时代的洪流给它的机会不多了，「协同」这个命题，需要组织结构+消息体系这两个核心基座，我对测试这个环节，非常坚定的认为一定要与飞书的协同体系连接起来，单独用一套系统来管理是无法接受的，效率和体验都显得很另类。

在与测试团队沟通的过程中，推进阻力很大。测试同学一致认为飞书的多维表格，本质上只是一个Excel而已，无法与专业的禅道相比，测试工作有很多特定的需求，不是简单往一个在线表格录入数据而已。

进行了很长一段时间的试用后，测试团队的反馈还是比较负面，觉得禅道这种专业的系统，怎么可能会被飞书一个增强版的Excel替代呢？

我于是认真的思考了一下这个问题，得出的结论是：多维表格一定可以满足产研的缺陷管理的需求，我们可以用多维表格搭建一个非常简洁、灵活的缺陷管理系统。

说干就干，拉着团队的产品、技术、测试的主要负责人，一起梳理需求，设计库表，很快就把核心的结构都整理好了：

字写得有点乱，有几个要点，翻译一下：

1. Bug缺陷的本质，只需要几个字段就能描述

   1. Bug描述：一句话描述清楚Bug是什么样的，可以是一句话，也可以是一段话
   2. 截图：有图有真相，截图把Bug现场说清楚
   3. 分配对象：这个bug是谁的，由谁负责处理。

我把它就做「Bug三要素」，只需要把这个3个要素定义清楚，一个Bug就确定了。其他字段，全部属于管理意图字段，如

1. 提交时间：方便用来按时间排序
2. 优先级：方便对Bug进行定性排序
3. 归属版本：方便对Bug进行分组
4. 状态：方便对Bug进行过滤，分组

这些字段都不关键，但是也重要，我们可以利用多维表格的默认填充机制，默认写好值，这样就极大的解放了测试同学的工作量。

解决了核心的表结构设计问题，还有好几个管理层面的问题需要解决：

1. 测试同学的录入体验如何保证？
2. 如何按版本对Bug进行管理？
3. 团队有几十个研发，大家如何都只需要专注自己的Bug，而不是在整个表格中一条条中找自己的？
4. 在测试交互的过程中，能不能有一些温度，不是像禅道那样冷冰冰的信息化工具而已？

这些问题，本质上也是禅道没有解决的特别好的，我们看看基于多维表格如何解决这些问题。

我差不多花了差不多2个小时，一个非常漂亮的系统就搭建出来了。如图：

上面的这几张图，有一些共同的特点：

• 在重要的命名定义上，加了Emoji这样俏皮的元素
• 文案上，跳脱出之前死板的定义，例如禅道上优先级的定义是：低、中、高，紧急，诸如此类的一大把很抽象、听不懂的定义。而我就采用：普普通通、重要问题、致命问题之类的描述，让整个文案充满了俏皮感，大家工作的时候，使用这样的系统一定是更轻松、更开心的

这个多维表格叫做「缺陷管理系统」，主要用于产研团队的Bug缺陷管理，就是要取代禅道这样的笨重产品。最后总结下核心设计思路：

• 版本管理，缺陷管理分离。主要考虑迭代还是以版本为基本单位进行推进，所以将版本表单独抽象出来。
• 缺陷管理聚焦于最重要的几个字段，我称之为缺陷3因子：描述，截图，分配对象。其他内容基本上全部自动填充。
• 视图上，主要有3种类型：表单视图、版本视图、个人视图
• 表单视图，主要用户为测试同学，可以快速提交bug
• 版本视图，主要用户为产品经理、测试，用于衡量某个版本的bug情况
• 个人视图，主要用户为开发，专注于自己被分配的bug，自行维护，避免与其他人产生冲突
• 另外，在字段定义的文案上，尽可能采用俏皮、轻松、活泼的文案，推动团队协同优质氛围

这个是我们用多维表格替换IT系统的一个小小案例，类似的案例还有很多，只要有心低代码、协同这样的案例在飞书这样产品中，会有越来越多的涌现。