采訪背景

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 上完成。