5.25

说实话，当我第一眼看到隔壁团队那个配置管理子系统的时候，心里真的是五味杂陈。我们团队也做了一个，十九个模块，一个不少——车站管理、网格管理、位置管理、设备分类、设备用途、巡检线路、巡检项目、保养线路、保养项目、检测线路、检测项目、故障字典、备件库位、备件分类、备件型号、设备厂商、键值字典、流程定义、流程路由。我们吭哧吭哧干了好几个月，赶在五月底交了差。当时还挺自豪的，觉得该有的都有了，用户能配了，能存了，能查了。直到我点开了隔壁团队的“智配版”，我才知道什么叫“能做”和“好用”之间的距离，比我家到公司还远。

先从最直观的界面说起吧。我们做的界面，说白了就是一堆表格套着另一堆表格。左边一个模块树，右边一个列表页，点进详情又是一堆输入框。用户要新建一条巡检线路，得先记住巡检项目有哪些编号，然后一个一个手动填进去。保存完了想看看这条线路挂在哪个车站下面，得再切到车站管理模块去查。隔壁团队呢？人家在同一个页面里，左边是车站的树形结构，右边是线路的可视化看板，你点一个车站，它关联的所有线路、项目、保养计划就像展开的地图一样铺在眼前。创建巡检线路的时候，人家直接从项目库里多选打勾，甚至支持“快速新建项目”——弹一个小窗，填三五个字段，项目就建好了，而且自动关联到你正在建的线路上，不用跳来跳去。我当时站在他们同事身后看他演示，十几秒就配完了一条复杂的线路，而我们那边至少要来回切三四次页面，花上两三分钟。那一下我就觉得，我们做的东西，像是一台老式手动档拖拉机，人家的则像是带自动导航的电动车。

再说说那种“用着用着就想骂人”的细节。我们的系统里，你删一个设备分类，它会弹出一个框说“该分类被引用，无法删除”。至于被谁引用了、引用了多少、怎么才能删掉，它一概不说。用户只能自己一个一个模块去翻，找到那些引用了这个分类的备件型号、故障字典条目，手动改掉或者删掉，然后再回来删分类。运气好的话折腾十分钟，运气不好的话两个小时都搞不定。隔壁团队的做法让我眼前一亮：删除的时候，人家直接弹出一个依赖图谱，用连线和小图标展示这个分类下面挂了几个备件型号、几个设备用途、几个故障字典。更重要的是，它给了三个选项：第一个，自动把所有引用的对象改成你指定的另一个分类，然后删除当前分类；第二个，强制删除，同时把所有引用的条目也一并删除（当然会二次确认）；第三个，暂时停用这个分类，保留所有引用关系，以后再说。这三个选项一出，用户几乎不用离开当前界面就能把事儿办得干干净净。我当时就忍不住拍了一下大腿——我们怎么就没想到呢？

还有一个让我特别崩溃的对比，是流程配置。我们的“流程定义”和“流程路由”是两个独立的表格模块。你要定义一个审批流程，得先定义好节点名称（比如“提交申请”“部门审批”“技术审批”“结束”），然后去路由表里一行一行地配置条件，比如从“提交申请”到“部门审批”要满足什么条件，从“部门审批”到“技术审批”又满足什么条件。全部用文本字段手填，条件表达式没有任何提示，比如你写${amount} > 1000，少写一个括号，保存的时候它只会说“表达式错误”，但不告诉你是哪个节点哪一行错了。有一次我自己配了二十多个节点的流程，调试了一整个下午，最后发现是某个节点的大小写拼错了。隔壁团队呢？人家直接做了一个可视化流程设计器，拖拖拽拽，连线，双击节点就能写条件，而且条件表达式带自动补全和实时语法校验，写错了当场标红，还给你一个“模拟运行”按钮，可以输入假数据走一遍流程，看它会不会卡死。他们的运维同事说，现在配一个中等复杂度的流程，平均七八分钟搞定，而我们那边至少要半小时起步，还经常配错。
性能上的差距就更不用说了，说出来有点丢人。我们的位置管理模块，当数据量涨到五万条左右的时候，列表页的模糊搜索要等四五秒才能出结果。隔壁团队同样的数据量，同样的模糊搜索，基本上一秒以内。我问他们怎么做到的，对方轻描淡写地说“用了Elasticsearch，顺便做了个缓存”。我们连索引都没建全，难怪慢得跟蜗牛一样。还有批量导入，我们导入一万条巡检项目，页面直接卡住，用户只能盯着那个转圈圈的图标发呆，运气好的话四五十秒后提示成功，运气不好的时候浏览器直接崩溃。隔壁的批量导入是异步的，你点完导入之后可以继续做别的事，右下角会有一个进度条告诉你“已处理第3820条，预计还需12秒”，而且就算某几行数据格式错了，正确的那部分照样能导进去，最后给你一个详细的错误报告，告诉你第几行哪个字段错了，正确格式应该是什么。我们的做法是一旦有一行错，整个批次全部回滚，用户得对着Excel一行一行找错误，改完再重新上传，周而复始。
文档和生态方面，我们基本就是空白。我们交付的时候给了用户一个PDF，里面是每个字段的说明，连个截图都没有。隔壁团队直接在内置的帮助系统里嵌了引导式教程，每个字段旁边都有一个问号图标，鼠标移上去就告诉你这个字段是干嘛的、填什么格式、有没有依赖别的配置。更过分的是，他们还提供了完整的API文档和Python SDK，用户可以用脚本批量管理配置。虽然我们目前还不需要对外开放API，但看到对方那种“让用户用代码来操作”的开放程度，我真的觉得我们做的东西还停留在上个时代。
当然了，我也不是光涨他人威风。我们做的系统有一个地方是隔壁团队暂时没有的——我们特别省资源，部署起来特别快，一台两核四G的服务器就能跑得挺顺。他们的系统依赖了Elasticsearch、Redis、图数据库一大堆东西，部署一次要半小时，硬件要求也高。而且我们的代码特别简单，没有什么花哨的设计模式，新人接手一周就能改需求。他们的代码我瞄过一眼，抽象层次很多，想改一个字段可能要动七八个文件。但是说句公道话，在真正的日常使用体验面前，这些优势显得有点苍白。用户不会因为你部署快就原谅你每次搜索等五秒，也不会因为你代码简单就忽略掉配置流程的繁琐。
这次对比让我明白了一个道理：功能和体验真的是两回事。我们团队做完了十九个模块，自认为功能完整，但那仅仅是“能跑通”。隔壁团队做的，是“能让用户跑得舒服，跑得开心，跑得不容易摔跤”。他们比我们多花了三个月，没有增加新的模块，全在打磨这些细节——依赖可视化、批量操作增强、流程设计器、性能优化、智能提示。这三个月，我们一开始觉得他们是在浪费时间，现在看来，我们才是那个浪费了真正机会的人。
如果非要给我们的系统和他们的系统各打一个分的话，我会说我们的系统是一个“60分的作业”，及格，但没有任何惊喜；他们的系统是“85分的产品”，已经能让用户主动说“这个真好用”。那15分的差距，不是天堑，但每一分都需要用对用户的敬畏之心去填。下一次，如果我们还有机会重写这个系统，我希望我们能从一开始就问问自己：用户最痛的点是什么？我们能不能让用户少点一次鼠标？我们能不能让用户犯错之后不只是报错，而是告诉他怎么改正？这些问题，隔壁团队给出了漂亮的答案，而我们，才刚刚开始学习提问。