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的讀書筆記


/

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

更多精彩活動花絮請參考

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


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

於 沒有留言:
標籤： , , ,

2021年4月24日 星期六

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

 




感謝PM Tone 團長的熱情邀約，讓Peggy 有機會在社群分享AI PM 的愛恨情仇(?) 。

果然是一群放棄追劇的奮進向上職場工作者啊，大家的參與度很好，問題也詢問的很熱烈。

Peggy 覺得這些問題都問得很好也很實際呢！就趁著還有些印象，與週末有點空檔，來整理一下，希望對一些相關領域的朋友們有些幫助。

因為是憑印象，也許有些疏漏。

如果剛好當天有參加的朋友，看到您的提問沒有被列入，也希望有機會得到多些資訊的，也歡迎來信或是留言。

當日提問包含層面很廣，從資安到專案管理到 AI PM 都有，很有意思啊。
本篇為上集，主要包含 Q1 ~Q4，最近會再找時間寫下集 Ｑ5~Q8 的部分。 XD


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 上線維運的風險...



/

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

Peggy 有一段時間是蠻專注在和勒索軟體奮戰的專案中，對勒索軟體的演進和挑戰有那麼多些瞭解。

最好的方法真的是養成好習慣，包含定期備份！

早期一點的勒索軟體，很有機會可以反解密救出被加密的檔案。
但近幾年的，這種機率越來越低了。

但是還有機會的，有時候舊的勒索軟體，在幾年後，可能因為各種原因，有機會解密。著名的例子就是「WannaCry」這隻。
所以就的被加密的硬碟還是不要丟掉，先留著吧

解密好用軟體 > 可試試「Trend Micro Ransomware File Decryptor」

怎麼預防，可以參考下圖。(source: https://blog.trendmicro.com.tw/?p=12634)



補充個小提醒，對於離線的備份USB 。

1. 千萬不要在被綁架的電腦還沒清乾淨前，就接回來想還原。
2. 不要一直插在電腦連接著...

如果那就很容易悲劇了..

因為很多勒索軟體是會將整個電腦硬碟掃描一次，順便加密它感興趣的檔案類型，連接的USB與file server 也在掃描範圍內。




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

建議可以從目標公司群裡（假設是十家），先挑那種會想加入但沒入選也不會很遺憾的一兩家來練兵。

1. 先研究目標公司 job description， 抓住共同點（keyword)， 接著回頭調整自己的履歷。

為目標職務客製化履歷是很值得的！

基本精神，強調共同點，與您在這共同點上帶來的價值與亮點。
例如，職缺寫明要有很好的溝通能力，就往這方面著墨更多。
會增加履歷被挑中來面試的機率。

如果覺得履歷調整一直不是很順，也可以考慮參與協助調整履歷的課程或工作坊。
大人學的「A103履歷優化與個人品牌重塑」評價蠻好的，可以考慮看看。 

另外，也建議先多去了解軟體PM 需要的一些技能，先研究一下。
畢竟，當幸運地有機會面試，面試官問：「既然您對軟體PM 一直感興趣，請問最近有什麼相關的研究、接觸或了解嗎？」

當被問到類似這樣的問題時，如果沒有準備，就當場尷尬了...
也展現出，並沒有想像中的那麼有熱誠和想轉到這個領域。

這邊分享一個之前面試的小經驗，那時候big data 剛出來剛紅，有一些candidate 表達對big data 「超・級・有・興・趣」。

Peggy就期待地往下問問，一問之下，對方答不出所以然來時，就知道其實只是對這個領域有憧憬和想像而已，並沒有付諸熱情和行動的先多去了解。

那如果不小心上了呢？ 啊！那就恭喜啦！


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

先來說說Peggy覺得一樣的部分：強大的溝通能力、Customer Focus與定義問題的能力。

這邊先不細談這塊，有朋友感興趣的話，Peggy 再找時間寫一篇。

那差別在哪呢？以Peggy的看法，主要有這幾項。

  • 需要面對更多的挑戰、風險與不確定性
  • 需要能夠更明確的定義問題、需求
  • 需要提醒自己給 ML 專家更多點的時間探索
  • 需要及早規劃數據策略(data strategy) ，若貴公司打算持續在這方面發展
  • 需要更快的學習與應用的能力
  • 理解到ML產品的開發是跨更多領域的，也需要更多的耐心溝通


Q4: PM 怎麼和 ML 工程師與RD 合作的更好。

主要可以三個角度來思考 — 態度、價值與學習。

態度

  • 不懂別裝懂啊！！！不懂就問，不懂就google 去了解。ＭＬ工程師等研發團隊都是很聰明的，裝懂也很容易被識破，裝懂也常會帶來慘劇。試想，如果以裝懂下的理解開Spec 是不是一件很恐怖的事情。
  • as A team ：PM 自己不是那個唯一的英雄，當這個 solution 會成功、反應很棒，一定是有一群很棒的同事一起協作完成的，不會是自己一個人好棒棒的。
  • 互相尊重：若PM 自己的態度眼高於頂，相信合作的團隊無形間都會感覺出來，真心的好好合作和敷衍的合作，結果會有差。

價值

PM 要很認真的思考，自己可以為團隊帶來什麼價值。
講句直白一點的話，為什麼老闆要付錢給您，而不是直接找一個 ＭＬexpert 來build model.

PM 先天上免不了有些角度和ML 工程師團隊有些抵觸。例如以schedule 的角度來看，慘烈的情況下可能會工程師團隊想著“PM只會出一張嘴來壓時程!! (怒）”。

Peggy自己是傾向把自己當成團隊的一份子。

可以產生價值的地方很多：如幫忙翻譯客戶的痛點、幫忙講故事，把團隊的很棒的solution 可以讓更多客戶用到與理解價值。當團隊反應說很難做到時，第一句話不是挑釁的問為什麼，而是應該基於信任團隊已經認真評估過的前提下，去了解為什麼。 那是否有機會可以一起討論，怎樣調整達到目標。 縮小範圍？減少Feature? 協助溝通Priority ? 等等

另外
PM 務必要比工程團隊更了解客戶、市場價值、user behaivor 、客戶價值層面
PM 也要協助搬開石頭，例如了解需要什麼data，幫忙去談去取得。
PM 也要更會問問題，協助定義需求、釐清spec 等 

快速學習

熱切地去了解共同語言與世界。聽過一次就要查，最慢聽過兩次同樣的行話就要去了解那是什麼。

以output 為前提的進行input 是最有效的！！

費曼學習法 >  Source: ✒️如何學習得更有效率。費曼學習法｜學習的知識#6｜【閱部客】
https://www.youtube.com/watch?v=SLzn0LaR0lE  （下圖左部分出自此)

也推薦輸出達人劉奕酉「高產出的本事」一書 


/

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

更多精彩活動花絮請參考


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


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

於 沒有留言:
標籤： , , ,

2021年4月7日 星期三

讀書筆記 ｜ 從「Amazon 的人為什麼這麼厲害」一書，探探Amazon 的秘密～

 



本文內容包含

  • 為什麼Peggy會選擇看這本書？
  • 本書適合讀者群
  • Amazon 怎麼招募人才？
  • Amazon 強大的秘密 - 數字管理
  • Amazon 怎麼進行內部資訊分享？
  • Amazon怎麼提升開會效率？


/

現在服務release 超級快 , 以近期手上的project 來看，每天上新的code ，release 新的feature/enhancement 已經是像呼吸一樣的那麼自然。

然而，新的挑戰也出現了！

以往code complete 之後， write document —> TOI/ training —>  customer  這流程中，每個步驟都來幾週時間，已經趕不上了。

RD的部分， infrastructure as a code 已經引起很多關注/討論與實踐，在相關社群中也看到不少專家分享實務經驗。

那 feature release 後面一直到support 再到客戶這一段呢？ 如何降低所需資訊的落差呢？ 如何縮短sync information 所需的時間呢？

若Support  team 同仁在收到客戶詢問，再回來問問題，一來一回，效率不好，客戶也須等待。

在今年初的公司DevOps Expo，AWS 專家的sharing session中，有提到Amazon 運用working backwards 解決相關部分的問題。（想像中是對應到給customer 資訊前的internal information sharing 的部分）

因為時間關係，講者無法介紹的很細，Peggy 就想著找相關資料來多了解。

因為在DevOps Taiwan 社群內，有來自Carousell 的臉友提到因為CTO來自Amazon，因此也是這樣做的，另外也說到這本書有相關介紹。因為好奇心，買來拜讀。




這本書合適讀者群

  • 對Amazon practice 和強大的秘密有興趣者
  • 想參考或從Amazon Practice 中得到靈感以進化手上工作的人

/

Amazon 怎麼招募人才？


  • 天天、永遠不間斷地在徵才。
  • 六個面試官，六次一對一面試。面試後召開會議，討論是否錄用。反對者要說明理由。寧缺勿濫。
  • 重視的特質— our leadership principles ( OLP)
    • 顧客至上 Customer Obsession
    • 主人翁精神 Ownership
    • 創新與簡化 Invent and Simplify
    • 在多數情況下，決策正確 Are right, A lot
    • 好奇求知 Learn and Be curious
    • 選賢育能 Hire and Develop the Best
    • 最高標準 Insist on the highest Standards
    • 遠見卓適 Think Big
    • 崇尚行動 Bias for Action 
    • 勤儉簡約 Frugality 
    • 贏得信任 Earn Trust
    • 刨根問底 Dive Deep
    • 敢於建言、服從大局 Have Backbone; Disagree and Commit
    • 達成業績 Deliver Results
  • Amazon 特有的榮譽頭銜「抬桿者」：第二關面試一定有一位是抬桿者。被認為「找他擔任面試官可以錄取到優秀人才」。
  • 抬桿者觀察包含兩點，一為錄取此人的理由，二為candidate 是否可以在Amazon 重現以前的優秀表現？


/


Amazon 強大的秘密-數字管理


"make the impossible possible"...

 

  • 「數字 ＝ 度量(Metrics) 」，徹底落實 PDCA(plan, Do, Check, Act)。 「本週目標是什麼？」「上週的目標達成率是多少？」「目前達成率多少？」一整套的管理系統。
  •  零售、營運、客服等部門都是縱向組織，有各自的財務團隊．各自與總部不斷交涉決定下一期的度量。 
  • 觀念：錢花在刀口上，不要停止思考。日本營運單位和美國總部交涉實際例子：提案多蓋幾座倉庫，被果斷的拒絕，要求思考如何將每個貨架利用率再提升10% 
  • Y = F (X) , Ｙ是上層的關鍵績效指標（如銷售額），X 是指下層的關鍵績效指標 (如左右銷售額的因素）
  • 要訂出清楚的Ｘ和 Ｙ。例如，要達成一百億日圓的業績，行銷部門需要吸引兩萬名新客戶，業務部需要和其中一千人成交....
  • 發現問題，須即時採取對策
  • 步驟：分解目標 -> 讓目標可以讓大家都「看得見」，決定檢核的時間點
  • 如何設定數字目標？在沒有正確答案的時代，必需自己設定目標


/ 

亞馬遜怎麼進行内部的資訊共享？


  • 用「新聞稿形式」撰寫文件，那種開始一項新服務或新商品發售時,會發的PR。
  • 使用時機：
    • 公司内簡報時
    • 組建新的專案團隊時，共享資訊時用
  • 具體內容包含
    • 新服務的概要
    • 顧客迴響
    • 負責人的意見
    • 新服務的特色
    • FAQ
    • 聯絡窗口

/

Amazon 怎麼提高開會效率？


  • Amazon 文件基本上是 1 頁（多是商務簡報） 或 6 頁（年度預算或專案說明）。一般而言，禁止用PTT。
  • 流程：
    • Step 1 . 會議一開始，負責人會先把文件發到各個與會人手上，如果是六頁的話大概閱讀時間是15分鐘。
    • Step 2: 文件負責人會開始詢問讀完了嗎？
    • Step 3: if yes, 接著開始正式開會，先針對文件內容發問和回答。「請問第一頁有問題嗎？」「沒有」「第二頁呢？」...一直到最後一頁
  • 用越短的時間結束會議，是好的會議。

/

閱讀時意外的發現，本書除了不少貝佐斯的貼身小故事外，也分享怎麼招募人才、留住人才、數字管理、怎麼和 super smart 的老闆相處、Amazon 的準則等等，蠻有意思的。

希望以上的整理摘要對有需要的朋友有點幫助囉。



 歡迎轉貼，禁止商業使用，請註明原文標題、連結以及作者。
於 沒有留言:
標籤： ,
訂閱： 文章 (Atom)

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

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