微知識引擎，共同打造無窮複利

  圖片來源 RPA(Robotic process automation)，機器人流程自動化，主要幫助企業執行重複的任務，並透過 排程於特定的時間點自動化完成特定規則的工作 ，像是常見的訂單輸入、報表、發送通知...等日常作業皆可透過RPA來幫我們完成。 相信每間企業的核心價值絕對不是在處理日常事務，因此假如我們可以將日常事務交由機器人來幫我們完成，那麼企業的員工被賦予的職能價值也相對的提升，將寶貴的人力用在需要判斷、決策、設計高價值的工作上，提升整體企業品質，而RPA就是為了這樣的目標而誕生，許多公司也開始推出一整套專業領域的RPA機器人(財務會計、存貨管理...)。 特性 擅長處理結構化資料。 依照標準規則執行。 橫跨並串接不同系統(Excel、ERP...)。 可複用性高，開發時程短。 面臨的三大挑戰 規則必須嚴謹，且經過測試後才能將規則上線，試想如果一個非常重要的日常工作出包，導致後面一連串的工作都發生錯誤，那麼相信對企業的損失是難以估計的。 系統環境必須穩定，硬體設備與作業系統皆是風險因子。 若導入AI的輔助，由於變因增加，那麼相對應的也可能造成新的風險。 除了自動化，還能智慧化嗎？ 圖片來源 看到這邊我們可能會產生一個疑問，那就是RPA的誕生不就是為了解決重複性的工作嗎？那跟AI又有什麼不同？ AI主要是負責處理比較智能化需要統計、推測的任務，與RPA要解決的問題在本質上本就有所不同，但我們有思考過嗎？ 將兩者結合會發生什麼事？ 試想，假設我們將AI技術的語音辨識、影像辨識加入到RPA的規則，那麼這個機器人除了自動化之外，也被賦予了智慧化，甚至搭配NLU語意理解，那麼只要我們以口語化的指令輸入，就能簡易的完成任務，對於使用這套自動化系統的人來說，減少學習成本之外，也節省複雜規則的檢查時間，讓時間花費在刀口上，對於大型企業來說更是不可或缺的自動化流程。 什麼條件下不適用RPA？ 流程不具被重複性，經常變化的流程，可能就不適合RPA了。 特定知識領域，需設計的工作，例如美工設計、架構設計...。 偶爾才執行的工作，這類工作用RPA價值不高。 RPA有哪些應用？ 圖片來源 結語 生命就該浪費在有價值的事物上，我們應該把重複的工作交給機器人，轉而進行高價值的任務，實現「work smart not ...

  會談這個主題主要是工作上預計進行 Pair Programming 的模型來開發，因而蒐集了一些關於 Pair Programming 這方面的相關概念與執行方向，並整理讓大家共同參考、討論。 但實務上真的可行嗎？ 老闆同意嗎？ 在執行前個人心中的兩大疑問，那麼以底下例子來看，這個問題的確沒有絕對的答案，取決於我們的思考面向。 如果大家認同航船過程中要有船長及副船長才足夠安全，那麼 Pair Programming 就是這樣的保險概念，透過雙人合作、互補來保障乘客順利抵達目的地，套用到產品的開發上也是如此，雖然兩個人共同做一件事情看似很蠢，但後續的經濟效益通常是我們沒有考慮的部分，試想我們的產品如果品質不好，在客戶端老是出包，那麼相信維護人員只會疲於奔命，對公司無非是莫大的損傷，產品給客人的觀感也不佳，影響公司的名聲，只要這樣的聲量傳開來，相信競爭者看到也一定很開心吧! 我想這並非公司所樂見的，因此 Pari Programming 就成為了這問題的解方之一，除了改善品質之外，還能用來進行新人訓練，甚至新產品研發都是非常適合的模式。 總之，取決於我們看事情的角度，假若我們重視的是後續的維護成本及產品品質，那麼 Pair Programming 就非常適合導入，但若僅是為了短期專案，只要快速結案就好，那麼用 Pair Programming 就多此一舉了，接著就直接進入主題吧！ Pair Programming 是軟體領域中經典的開發方法，源自於極限編程的一種方法，又稱為結對編程，白話來說就是兩個人一起寫Code或者是完成某項指標任務，共同合作、互補、創新，主要會由以下兩個角色組成，分別是導航者(Navigator)跟駕駛者(Driver)，導航者負責觀察、規劃及回饋，而駕駛者負責實際執行。 過程中2位工程師會用同一台電腦，針對同一支程式進行開發，上圖中每個人都可能是導航者與駕駛者，因為可以互相交換角色，以不同觀點來發掘問題與提出解決方法，減少單獨開發的盲點，提升產品品質。 🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔 優點 俗話說獨樹不成林，單打獨鬥難以成事，一個人寫程式想必存在許多盲點，而這個盲點如果有另一個人一起檢視，那麼或許問題就更容易被發現，也減少在正式環境上發生BUG的機會，但如果讓兩...