面向工程师的内部系统需要 Web 界面吗？

每个互联网公司内部都有一些 Web 界面是为工程师开发，比如 CMDB、容器平台、应用发布系统、可观测性平台、配置中心、数据库管理平台等等。这些界面往往设计风格不一致，功能简陋，易用性差强人意，简单概括就是「能用，但既不好看，也不好用」。

内部系统的设计通常来自于两类人：产品经理或工程师。一般的产品经理很难设计好面向研发的系统，原因在于这些产品的内部逻辑为技术驱动，且目标用户是公司内部的工程师。内部逻辑技术驱动会迫使产品经理花费大量时间和精力了解专业知识，目标用户是公司内部的工程师意味着用户基数小、需求不稳定甚至刁钻。对于产品经理而言，既要花费大量精力了解专业背景，又要满足少数用户的刁钻需求，过程会比较波折。一般的工程师也很难设计好面向研发的系统，原因很简单：不专业。即便出现一两个天赋异禀的产品经理或工程师能把自己负责的系统设计得十全十美，他们也不可能去参与设计所有内部系统界面。不同系统的设计输出没有收口，系统间的体验一致性也就无法保证。现实是：并非人人都能做产品经理。

即便设计得很好，设计到实现之间还有一层来自于前端开发的损失。我们假设有一个专职的前端团队负责开发这些页面。由于这个团队并不直接面对公司的客户，它的资源配备规格通常不高，这既体现在工程师个人能力上，也体现在团队规模上。配备不高的同时，这个团队还将面临激烈的资源竞争。竞争的结果就是交付质量不如预期，设计还原度差，且迭代迟缓。为了解决资源问题，这个团队也会想一些办法。最典型的就是做一个通用的低代码平台，希望后端工程师或者产品经理能够用它自助地把页面「拖拉拽」出来。但实际使用时，一旦需求稍微复杂一些，低代码平台这层抽象就会泄漏，没有前端知识或前端工程师的帮助依然做不出来，甚至使用低代码平台的效率要低于前端工程师直接开发。此外，投入精力到低代码平台还会进一步加剧资源竞争。

总体来看，为面向工程师的内部系统开发 Web 界面是一件各家公司都在做但绝大多数都做不好的事情。我一直有在思考这个问题是否有更好的解决方案。目前有一个阶段性的结论，暂且记录在这个博客里，希望有一天能有机会验证：

如果在可见的时间范围内公司业务允许绑定在单个云服务提供商上，可以尽可能去使用云服务商提供的后台界面，云服务商有专门的团队来保障不同产品界面的交互体验与一致性。这时公司内部的相关团队就无需关注产品设计，开箱即用。如果绑定单云不是一个可选项，我的想法是尽可能推迟开发 Web 界面。怎么推迟？开发类似 awscli 的统一命令行工具，这时公司内部的相关团队只需设计一个命令行开发框架，相对于设计和开发 Web 界面，设计命令行工具将问题范围缩小了很多。甚至还可以进一步考虑将命令行工具迁移到公司内部的即时通信系统中，实现 chatops，通过聊天机器人完成原本需要在 Web 界面上的操作，将使用范围扩大到工程师之外的员工。