2021年4月28日 星期三

職場 ｜ PM Tone 社群分享討論紀錄（下篇 )

 



下集來啦，趁著這幾天通勤與陪小孩寫作業的時間，終於把Ｑ5 - Q8 整理出來啦。

希望對有需要的朋友有點幫助，也歡迎一起討論。

上集( Q1 - Q4 ) 在此 >>  https://peggywulifelab.blogspot.com/2021/04/pm-tone.html

Q1 : 電腦被勒索軟體綁架怎麼辦，還有救嗎？

Q2: 想從硬體PM 轉軟體PM ，但苦於沒有拿到面試的入門票..

Q3 : AI PM 和一般軟體PM 的最大差別在哪裡？

Q4 : PM 怎麼和 ML 工程師與ＲＤ團隊合作的更好？

Q5: 不少公司號稱有導入AI 事實上只是撈Data 的BI , 到底怎麼讓AI 在公司真正落地？

Q6: 似乎最核心AI的部分都被RD 掌握，PM 似乎顯得微不足道？ 在這種情況下，PM 怎麼展現自己的價值？

Q7: 公司團隊很新、很有衝勁，都會希望建立完model 快上線驗證。身為PM ，一邊感動於團隊的積極，另一方面也很糾結著怎麼讓沒有經過適當測試、上線可能會crash 、會影響其他solution 等等風險好好傳達給團隊成員知道，

Q8: 很想多了解有沒有什麼實務上的作法可以降低 AI solution 上線維運的風險...

/

Q5: 經歷過不少號稱有導入AI 的公司，實際層面只是撈Data 的BI , 到底怎麼讓AI 在公司真正落地？

AI 是一個幫忙解決問題的優秀技術和工具，但其實如果在貴公司BI 就夠了，也不一定要導入AI。

讓我們回到一個根本的問題來思考⋯

為什麼您「不滿足」於BI，而想要導入AI?
是想解決什麼問題？想帶來什麼價值呢？
這個問題也是公司/老闆或顧客的痛點嗎？

下圖可以給您參考( source ) 



Q6: 似乎最核心AI的部分都被RD 掌握，PM 似乎顯得微不足道？ 在這種情況下，PM 怎麼展現自己的價值？

這可以回到一個根本問題來思考⋯
為什麼貴公司（老闆）要找您來，而不是把預算拿去 hire 一個 ML 專家來build model?

一定是有希望您帶來的價值！

如果一時之間還是想不透，那這兩件事一定要做

  • 問老闆：不是很直率的衝去問老闆「妳/你覺得我該做什麼？」 而是思考過後，把自己目前做的、想做的，有技巧性的和老闆溝通。 在對話的過程，也可以一起釐清老闆對您的期待。

  • 觀察核心合作團隊們的需求，協助搬開那石頭。 例如，是否團隊正苦無data 來做 ML POC?  那就去了解細節，到底需要什麼data ？ 需要多少量？等等 。 接著盡快幫忙合法的取得這data 。

以Peggy的經驗和觀察，PM 如果能把以下的功能發揮的很好，通常會是對團隊很有幫助的，也是老闆會仰賴的人。

  • 對整個產品服務狀況掌握得很好
  • Share credit. 不是PM 自己好棒棒，而是有一個很優秀的大團隊
  • 很好的溝通者與橋樑
  • 可以把business opportunity 、user behavior 、customer value 等帶回團隊
  • 幫團隊把優秀的solution 更好的傳播出去，用其他stakeholders 懂的語言、故事和畫面
  • 樂於協助團隊搬開石頭，以幫助往前move


Q7: 公司團隊很新、很有衝勁，都會希望建立完model 快上線驗證。身為PM ，一邊感動於團隊的積極，另一方面也很糾結著怎麼讓沒有經過適當測試、上線可能會crash 、會影響其他solution 等等風險好好傳達給團隊成員知道。

首先，要肯定這團隊啊！ 會想儘快上線驗證是很正確的觀念和方向，總是比一直用in house 的data 在那邊POC 來得實際！

那接下來談到更實際的怎麼傳達這些風險給團隊知道。

有幾個做法可以參考
  • 如果團隊上線是會影響其他solution 的，要想辦法high light 出來，可能透過架構圖、流程圖等等幫助理解
  • 如果之前有其他team 已經有急著上線但卻造成negative impact 的慘痛例子，也可以拿出來當提醒。
  • 溝通方式可以準備好後，先找 team 內的leader、意見領袖聊聊，表達您的肯定與小擔心。試著找到雙方可以接受的共同處。

Peggy 是相信大家是珍惜自己羽毛與reputation的，如果上線一直搞砸，其他團隊就會越來越不信任我們團隊了。

另外雖現在是DevOps practice 盛行，但是我想大家還是不會希望半夜一直被call P0 。以這樣的共同角度去溝通，可能會更順利點。



Q8: 很想多了解有沒有什麼實務上的作法可以降低 AI solution 上線維運的風險...

目前已經很多種實務上做法可以參考，可先了解概念，和團隊討論實際上選哪些來做、怎麼做。

基本上的測試概念有以下：

單元測試 Unit test
整合測試 Integration test
端對端測試End-to-end test


關於降低風險的部署方式也有很多種

滾動/斜坡式(Ramped) 部署：逐步增量地將新版本替代掉舊版本

藍綠(Blue/Green) 部署：建新的一套在原版本旁邊，直到新版本完成測試，直接切過去，服務無縫接軌。

金絲雀(Canary) 部署：先將一部分流量導向新版本，沒問題後再向全部開放

A/B 測試部署：只有符合特定條件的使用者才可以使用新版本

影子(Shadow) 部署：on production but silent

這邊有一個很好的比較表給您參考。( Source: https://thenewstack.io/deployment-strategies/ ) 

另外建立 monitor 機制也很有幫助，當問題發生前/時，可以盡快/提早回應，避免造成滾雪球，問題越滾越大。
這塊也很多可以聊的，改天再找時間寫一篇。



推薦讀物> DevOps handbook: 打造世界級技術組織的實踐指南   或參考Peggy的讀書筆記


/

希望以上的分享，對需要的朋友有點幫助。

更多精彩活動花絮請參考

如果喜歡本文，歡迎留言或來信討論 ^^


歡迎分享與轉貼。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用，請註明原文標題、連結以及作者。

於
標籤： , , ,

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)

Peggy的實驗空間| 小書庫 Index card ( 讀書筆記總目錄 ）

  一直很喜歡閱讀，也常從閱讀好書中與讀書會得到許多的力量與啟發，不管是在人生的低潮抑或是順遂的時候。在閱讀之路上，這幾年也保持一個習慣。當閱讀到喜歡的書籍，且那陣子時間允許，就會提醒自己閱讀完後整理出心得筆記。一方面藉機鍛鍊寫作肌肉與思路，方便之後的複習和查閱。另一方面，也可以...