又是一週的開始, 來談談一個實際與RD溝通的心得, 那就是畫出架構與流程圖, 嚴格說來比較像是系統架構Framework, 因為程式運作的流程可能有很多迴圈, 很多規則, 說實在不是我們這種非資訊專業的PM所能支持的, 但整個系統圖就是我們用來做溝通的工具, 至少你可以說明你的End Point (Client Device)到Cloud (Server)之間到底是怎麼串連起來的? 中間經過幾個中介的Server去存取相關的服務API或是儲存使用者資料的DB, 每當辛苦畫出來一個系統圖時, 也是得請資深的RD同仁協助review, 或是講解給他們聽, 看看自己理解的是否有誤? 若定稿下來, 未來當作技術說明或是debug, 修改架構時的討論資料就非常好用, 而且當因為資源分配問題, 需要換另一組RD team接手未完成的開發時, 提供這樣的圖表, 也有助於新團隊快速了解原本coding的邏輯內容

其實這一切也都是回歸到當初是想讓自己趕快上手理解軟體開發上的各種服務之間的關聯性, 是要畫給自己看的, 例如上面一張範例是我們過去開發一套LineBot的串接我們IoT device的流程圖, 但經過幾次向不同部門的報告經驗之後, 發覺其實大家都很需要, 而且一目瞭然, 雖然不見得知道每一個Function Block裡面詳細的運作原理, 或是每一個來回的箭頭裡到底需要花多少功夫去implement, 但至少當某些服務出問題時, 也至少能明確指出是可能是哪一塊出了問題? 以另外的語音服務為例, 若是Intent辨識錯誤, 就可能是文字進到自然語言處理引擎(NLP, Natural Language Processing)中被分析出錯誤的結果, 但這時又要往前去看說是STT(Speech-to-Text, 語音轉文字)就轉換錯誤了呢? 還是被歸類到錯誤的Intent(意圖)....等等之類的開發中, 可能常會遇到的狀況, 心中有圖, 和RD溝通起來大家也都比較清楚, 有共同的認知語言, 就算我們或許無法把原因說的非常"精確", 但我相信已達到溝通的目的, RD也知道哪裡需要調整

而且有時候軟體RD也是各有擅長的領域, 隔行如隔山, 除非平常有在廣泛涉略的, 不然其實以我的觀察, 寫APP的RD對於Cloud RD在做的事情也是非常陌生, 尤其是當這種語音服務是串聯了從終端送到雲端又回到終端的架構, 有時候反而我們PM還需要先跟RD先概略解釋一遍整個Voice Service的流程之後, 他們也才容易去閱讀相關的開發文件, 雖然很坦白說的以我們不是軟工背景的人來做說明無法真正深入技術與問題的核心, 但畢竟整個產品開發專案要串連的不只有軟體RD, 還有其他許多配合的單位, 努力降低各單位在整合時的"溝通與認知的鴻溝", 讓大家On the same page也是PM很重要的職責之一