采访背景

2012 年美国提出工业互联网战略，2013 年德国提出了第四轮工业革命“工业 4.0”，2015 年中国推出“中国制造 2025 ”。毫无疑问，一个全面自动化、数字化、智能化的工业时代正在加速到来。这个信息化与工业化深度整合的过程，是工业互联网、云计算、大数据在企业研发设计、生产制造、经营管理、销售服务等全流程和全产业链的综合集成应用。软件研发管理平台作为工业软件研发的引擎，如何帮助制造企业实现高效产品研发与敏捷生产？

本次采访的仙工智能是一家专注于智能生产和智慧物流的高新技术企业，业务涵盖了通用 AMR（Autonomous Mobile Robot）控制器、仙工智能企业数字化中台 SEED、基于视觉技术的全感知 AI 系统 RoboView 及自动叉车等 AMR 产品。仙工智能于 2020 年实现了销售额破亿，且业务增速达到一倍以上。仙工智能联合创始人兼产品总监叶杨笙，在移动机器人控制器领域有多年的产品研发以及企业管理经验，致力于推动 AMR 控制器产品快速迭代并取得了行业领先地位。

本文将带大家从研发工具、研发流程、研发团队建设等多个角度来了解仙工智能对于工业产品研发效能提升的探索，希望对工业以及其他行业的研发团队有所裨益。

CODING：首先想请叶总介绍下仙工智能目前的核心业务以及战略发展方向。

叶杨笙：我们目前总共有四大块业务。首先最核心、做的最久以及占比最大的业务就是机器人核心控制器，主要是用于智能制造、工厂生产物流的场景。

第二条业务线是从核心控制器延伸出来的机器人本体业务，分为自动叉车、小型工业 AMR。我们重点会放在自动叉车，因为小型 AMR 已经很成熟了，我们不会投入太多去制造机器人本体，而是更加专注做核心控制模块，给业内生产机器人本体的企业提供核心控制器。因为自动叉车是个新领域，所以我们会先研发整机，在成熟之后我们也还是会专注做叉车的核心控制器。

第三条业务线是我们的第二代系统软件产品体系——仙工智能企业数字化中台 SEED，这个数据中台包括了四大模块：移动机器人业务实施工具（KHS）、机器人及自动化设备资源调度系统（RDS）、仓储物流管理系统（WMS）、设备运行时数据可视化显示系统（V）。

第四个业务，就是基于视觉技术的全感知 AI 系统 RoboView，利用人工智能、机器学习等 AI 算法来进行移动机器人的视觉导航、视觉辅助定位等，实现车厂协同，这块业务在整个行业都处在比较新的阶段，虽然对外还未正式销售，但是已经在很多项目中进行产品验证了。

CODING：也就是说仙工智能的业务中既有硬件产品也有软件产品。在工业产品研发过程中，以您的经验，硬件研发和软件研发相比哪个难度更高？

叶杨笙：我觉得难度差不多，但区别还是很大的。比如两者迭代速度不同，软件比较敏捷，基本每周可以出一个版本。硬件的迭代周期就长很多，比如开发一块电路板，从原理图、 PCB 、再到打板，一般来说一个月能迭代一个版本，达到一个稳定的版本至少需要五到六个版本的时间，那么大半年就过去了。随着研发能力的积累，目前我们升级硬件版本的速度已经比以前快很多了，基本每个月都能迭代一到两个版本。

CODING：可以看出你们在提高产品研发效率方面费了不少功夫。在之前的产品研发过程中，仙工智能遇到了什么问题，促使你们去寻找一个类似 CODING 的研发工具？

叶杨笙：那故事得从创业之初开始说了，刚从学校毕业开始创业的时候，我们还是用着 SVN 的代码协作方式，这种方式基本可以满足几个人的协作。随着团队人数开始扩张，我们开始尝试自建 GitLab 来使用 Git 协作，但发现自己维护服务器非常麻烦。

后来就搬到云端，开始使用 GitHub，随着人员规模进一步壮大，我们团队发现没有专业的需求/缺陷反馈渠道，我们就使用了一个开源的工具 Redmine 来做缺陷管理跟踪。这套工具持续一段时间之后，我们团队发觉这种方式还是不够高效：比如代码和需求的管理是割裂的，开发人员希望的是代码的提交可以关联到某个缺陷或者需求；而且 GitHub 没有一个项目的概念，就会导致我们的项目代码散布在几十个仓库中，这种方式并不适用较大规模的企业研发团队使用。

于是我们就开始找新工具，在找到 CODING 后，发现 CODING 和企业微信的结合也非常顺畅（因为我们公司在使用企业微信），研发管理的功能完善度也非常高，我们就决定了使用 CODING。

在确定了使用 CODING 之后，我们花了不到两个星期就把在 GitHub 和 Redmine 所有代码和跟踪问题全部切换了过来，并且我们是全员使用 CODING，无论是产品经理、售前、交付、测试人员等等都可以在 CODING 上交流产品问题。

CODING：也就是说随着组织规模的扩大，你们的研发协同方式和研发管理方式也在不断变化。经过这一段时间的使用，你们过去的问题有得到逐步的解决吗？

叶杨笙：最大的矛盾已经解决了，代码开发和需求、缺陷管理可以结合得非常紧密了，这对效率的提升是非常有帮助的，因为我们的需求非常多。有了专业的协同工具后，我们整个团队也可以更好地去合作，因为“透明”的信息让那些主动、有想法、有担当的团队能够同步获取信息，并且快速地做出业务决策。

CODING：说到业务需求量大这个问题，我们了解到国内的工业还没有走到标准化和高质量的阶段，这意味着大量的工业软件要为这些不是标准化的东西去买单，这样会不会导致你们的研发团队为了去适配这些不同的项目，做很多定制化需求？

叶杨笙：我们软硬件产品研发和升级迭代的理念一直是，面对非标的需求，一定要想办法转换成标准需求。这意味着我们一直都只有一个代码主干分支，我们最终一定会把需求抽象成一个通用逻辑，代码都会合并回主干。

CODING：除了非标需求的问题，工业软件的本质是工业品，是需要时间的积淀形成的，技术壁垒很高，这个行业也不像互联网那么开放，很多技术都是闭源的，没那么多开源的力量供大家学习和参考，你们是如何去解决这个问题的？

叶杨笙：因为我们研发的是控制器，控制和硬件的关系是很强的，如果写代码能力很强但不懂硬件那也很难参与研发的。所以在里面有很多我们称之为 know how 的过程，就是不断踩坑、不断解决、不断积累。很多内容在网上都查不到的，虽然网上也有一些开源的机器人方案，但是那些主要是通用的理论，和实际的工业应用是差很远的，真正的生产环境中的问题经常是复杂、边缘、诡异的。如果没解决好这些问题，机器人的程序挂了，在工业现场问题影响是非常大的。所以我们会把这些知识统统沉淀在 CODING 的文件网盘和 Wiki 上，这样团队成员可以随时随地查看与学习，最大化发挥知识效力。

CODING：那看来在这种高度生产化的工业场景，软件的质量要求是高的，一旦出现 Bug 就有可能会造成生产损失。你们目前在 CODING 上有没有采取什么软件质量保障措施呢？

叶杨笙：我们上 CODING 也是为了能够更好地做好这块，包括自动化测试、持续集成，我们都正在完善；也在使用制品库来对软件制品进行统一管理。我们在借鉴互联网的先进研发经验，希望能够应用在工业软件当中。

CODING：那除了上述提及的知识沉淀、持续集成、制品库、代码托管这些产品功能外，在使用 CODING 过程中有哪些令人印象深刻的体验吗？

叶杨笙：印象最深刻的一个点是 CODING 对客户的响应速度，比如我提了一个小需求，可能过两天就做好了或者有解决方案了。关于使用体验，因为我不是具体的研发角色，所以我还是从管理者的角度来谈谈。整个事项筛选器、所有事项的页面非常方便，可以让我很快就看到问题的全貌，比如今天发生了哪些问题，哪些问题优先级比较高。而且我们的研发告诉过我，在 git commit 里去关联需求 ID 是非常的方便。CODING 持续集成用起来也非常方便，可以自动化地进行版本发布，配置也没有很复杂。还有就是集成了网盘和 Wiki，以前我们用 GitHub 和 Redmine，文件没地方放，Wiki 没地方写，现在都可以放在 CODING 上。也就是说研发要干的事都能在 CODING 上完成。