RPA 之術業有專攻篇

在傳統的軟件開發項目中，業務和技術是相輔相成的，缺一不可。業務搞得再明白，技術實現不了，或者，技術水平再高，業務搞的一團糟，都是不行的，最終都沒法順利的完成項目。

只不過傳統的開發項目中，兩者的分工比較明確。業務這塊有其的領域性，須要有必定業務背景的人員（BA）參與。技術這塊也有必定的專業性，也一樣須要技術背景的人員（SA）參與。兩者屬於互相配合，協同做戰。

可是，有些業務性不是很強的項目，就不須要專業的業務人員（BA）參與了，有些懂業務的 SA 就徹底能夠獨立完成。

那麼，在 RPA 項目中，靠業務仍是靠技術？

筆者在以前 《企業如何快速打造本身的RPA特種部隊》一文中提到過，RPA 項目須要特種做戰的打法，小快靈，穩準狠。因此單兵做戰能力要強，RPA的從業者就要作到懂技術還要作到懂業務，也就是如今比較流行的複合型人才。

如今市場上存在的一種誤區，認爲RPA項目比較簡單，沒有編程基礎的人也能夠，拖拖拽拽就能夠輕鬆搞定。有些RPA的廠商也存在誇大宣傳和廣告效應，說業務人員徹底能夠掌握RPA；還有些說RPA工具就像辦公軟件同樣，你們均可以輕鬆使用。

有些業務人員也會認爲，RPA的項目就是結合業務，將須要的組件拖拖拽拽鏈接到一塊兒就能夠了，也不是很複雜，做爲業務人員也能夠作到的。這些認識是對 RPA 項目的體系和細節還不是很瞭解。說白了就是隻看到表面，沒有看到本質的東西，僅僅掌握了些基本的概念和簡單的操做步驟。每個學習編程的人都會編一段小程序，那會編小程序就表明掌握一門語言了嗎?

RPA 工具雖然提供了比較豐富的功能組件，操做步驟也是拖拖拽拽就能夠，但這只是最基本的操做方式，也就是剛剛邁出了第一步，後續還有不少步驟來完成。

流程能運行並跑通只是剛剛開始，在開發的過程當中，須要考慮到各類各樣的特殊狀況，考慮到異常的處理，考慮到如何進行上下游數據的串聯，考慮到是否使用了最優的方案，並如何將你的代碼作到優化，健壯，安全，通用，易維護。

RPA 項目是遵循軟件開發的流程的，有專門的框架，有通用的組件庫，有統一的代碼存儲，有嚴格的編碼手冊和編碼規範。這些相應的要求或者規範，若是沒有在傳統軟件開發領域實踐和沉澱過幾年，是很難達到的。

還有一點就是風險意識的缺少，作高風險的事情都存在絕對的利和弊。例如，股票和期貨是掙錢最快的方式，可是若是操做不當，也會賠的傾家蕩產。如何在規避風險的狀況下還能掙到錢纔是最重要的。

RPA 項目也一樣面對潛在的業務數據出現錯誤的風險。對客戶來說，RPA 工具是提升生產效率和正確性最有效的方式，可是若是因爲考慮不周或者存在缺陷致使業務數據出現錯誤，就拔苗助長了。

不能否認有些業務人員是能夠開發簡單的 RPA 流程，可是我不肯定在沒有上述開發體制和經驗保證的前提下，業務人員是否對代碼質量有充分的信心？是否敢把流程放到生產環境中運行？是否能保證運行中不出現任何的錯誤？以及在遇到問題的時候，能快速地解決問題？有沒有 Backup機制？誰去維護和升級代碼？

做爲專業的 RPA 團隊，咱們在國內開展 RPA 項目也較早。其實，咱們對於開發人員的要求也是很高的。從 2015 年至今，我也面試過幾百個候選人了。要成爲咱們團隊成員的前提是技術開發出身，能夠是 Java 或者 C#，有1-3年，3-5 年和 5 年以上工做經驗。根據這 4 年多，在工做中的各個方面的觀察和考覈，我發現真正能作到獨當一面的（技術好，業務通），仍是 5 年左右開發經驗的這一批開發人員。

目前市面上的 RPA 工具都是功能組件和技術實現的結合，短時間內是沒法脫離技術實現的。因爲 RPA 的業務流程不是很複雜，對於有必定經驗的開發人員，再加上有必定的流程改善經驗，要作到獨當一面，不是很難。可是業務人員想要經過掌握 RPA 工具的操做來到達項目落地，在現階段很難。業務人員的價值更多的體現對業務流程的梳理，而後將這些業務上真正的 RPA需求發掘出來，能準確的反饋給 RPA 開發團隊。

還有就是，能作 RPA 和能作好 RPA 徹底是兩碼事。

總之，術業有專攻，讓專業的人作專業的事纔是正道，才能更好的促進 RPA 這一行業的健康發展。