|
|
我們觀察，生成式 AI 應用對企業的價值，常常是：加快「本來就會的事情」，價值不如「做到本來做不到的事」。所以 no-code 工具既然存在，裝備在 PM 身上，比裝在工程師身上，更有價值。而重點是，多好裝？所以我們開啟了這條實驗之路。
本文作者為 宇鯨智能 共同創辦人 / 前上櫃公司 企業商務流程系統 PM Team Lead
裝備在誰身上，更有價值？
其實從去年底開始，我們默默一直在討論一個「PM+」的概念。
一般no code、low code 工具雖然強調「非工程師」也能做到，但我們實際觀察是⋯其實是工程師的小幫手啦，還是要工程師操作，只是讓他們做得比較快而已。
但宇鯨選擇了一個稍微不同的角度，我們在看的價值，是從 PM 這角色去改造。
no-code + 工程師 = 工程師降維打擊（可以更快寫更多程式）
no-code + PM = PM 升級打擊（可以做以前不能做的事）
普遍在生成式 AI 的應用中，我們的觀察是：對企業的價值是：加快「本來就會的事情」，價值不如「做到本來做不到的事」（至少在一部分企業主眼中是如此）。
所以 no-code 工具既然存在，裝備在 PM 身上，比裝在工程師身上，更有價值。而重點是，多好裝？
所以我們開啟了這條實驗之路
AI 賦能版的 PM 實驗
我都戲稱，我在拿自己做實驗。
作為不會寫程式，連 Excel 函式都不會寫的 PM（我本人），加上 no-code 工具、AI 寫程式，能做到什麼程度？
【一點背景介紹】
在這個項目上，我們團隊主要是2個人參與：
一個是不會網頁開發的 AI 工程師
一個是不會寫半點程式語言的 PM
就是一個在企業端，獨缺網頁開發工程師在中間（不是應該就做不了事了嗎？）的奇怪組合。
【不會寫程式的 PM 做出了這些】
目前做過了 B端的客戶管理、各種表單、文件生成、報表下載、專案管理系統、行銷管理、薪資管理、Chat 或 Line 的自動通知、帳單結算、簡單的財務管理，包含一些 AI 工具的串接。
【觀察到的限制】
基於本身接觸的需求方屬性及 數據量 vs. 工具效能 考量，目前認為服務大量C端用戶的服務，比較不適合。但大量資料經過匯總後，提供企業內部做運營管理之用的系統則可能較為適合。
【使用工具】
使用過的工具包含 Airtable、Appsheet、Microsoft PowerPlatform、GAS(Google Apps Script)、Make、ChatGPT。
因為本身需求原因，最終選擇在 Appsheet、GAS、Make、ChatGPT 這幾個工具範疇深耕。
「文組生也能寫程式」 vs. 「no-code 工具很難用」，怎麼那麼衝突？
在實際的各種工具使用上，我觀察到一件有趣的事：
是關於「文組生也能寫程式」 vs 「no-code 工具到底多難用」的衝突光譜。
各種 no-code 工具的學習曲線各不相同，但我覺得會明顯感覺撞到壁的，是要做「比較複雜」的「自動化」時。在沒有 ChatGPT 以前，我就死在這裡了。用「點」出來的難度，其實不低。
有了 ChatGPT 後，我就插上翅膀直接開掛：Trigger 設置好後，不跟你點來點去了，直接 call scripts，結束。
這個反轉點很有趣，是因為，我看到拼死研究設計，為了把「點來點去」流程做得很簡單的團隊。心碎一地 💔 的畫面（身為產品人，我自己幫人腦補，然後還覺得難過😂）
在內建自動化功能的 no-code 工具裡，過去的設計邏輯是「把程式碼藏起來（不要嚇人）」，主打一個「用點點點就可以做到唷，啾咪😘」。但是這個「點來點去」的過程，其實需要的是「運算思維」的能力。
而為什麼 PM 工作是文組生也能做？因為一個能將需求梳理清楚，轉成工程師語言（而不是程式語言）的 PM，仰賴的是「思路清晰」而不是運算思維。我們的職能重點放在：能清楚告訴工程師（或ChatGPT）要什麼、不要什麼、什麼情況下要怎麼走。剩下寫成code 都是工程師（或GPT）的事。
一般口語常說 PM 要邏輯清楚，但實質上比較偏思路清晰，而非數學意義上的邏輯。這就是為什麼 PM 可以思路清晰但沒有運算思維（至少我本人是😅😂）。運算思維跟數學很像，其實更像是一種語言、一種有強制規則的語言。這也不是我擅長之處，就不展開多談。
但這就是為什麼，運算思維對 PM 而言更偏學習程式語言（OS：我就沒有要學吼 / 我就學不起來吼）。造成「主打不用寫程式，但實際上要求更高的程式理解基礎」衝突。
當然，是因為 ChatGPT 的出現，才會有比較有傷害。寫 Script 被 ChatGPT 代勞後，只要克服看到程式碼就恐慌的症頭。善用文組生其實非常可以思路清晰的，掌握 input 及 output、以及掌握測試、回饋，去跟 ChatGPT 反覆搞出 可用的 code，反而是門檻更低的方式（因為用的是思路清晰的能力）。
這也是為什麼，我其實認為 PM 非常適合成為用 no-cdoe + AI 來做部分系統，取代工程師工作（oh，好狂妄，不不不，是 offload 工程師永遠沒有時間來開發的部分啦🤣 ）
至少我嘗試過的這些上述系統，都偏向企業內部流程使用。而往往在有技術開發能力的企業裡，工程師資源會優先放在C端的開發（畢竟是開源），而內部流程所使用的，比較難拿到資源。這是開發資源有限的情況下，很多公司都會遇到的痛點。過去身為電商平台內部系統的 PM Team Lead，個人很有感。
痛點存在，而我看到生成式 AI 出現後，似乎有了新解法的「可能性」。讓 PM + AI 後，PM 就能一條龍把需求做掉，就能真的減少被卡在工程師身上才能做的事。（最明顯的案例，是以前撈資料都要工程師或分析師，但環境設定妥當，行銷+AI 就能做到，其實雙方面都省時省力）
而除了上述 PM 的職能特性適合外，我看到的，是這個學習對 PM 的學習養成也很有幫助。
要能操作 no-code 工具來做掉需求，需要2個能力：
1. 梳理流程能力
2. 評估相應的技術限制能力
其實 PM 的規劃能力要完整，兩端同時需要。才不會出現流程超讚卻做不出來的需求、或太低估技術可行性而犧牲流程太多。
我過去帶過偏文科生出身的 Junior PM時，除了需求面外，另一種常見卡關是技術面的不熟悉。例如，開給工程師的需求太粗，原因是PM對資訊流、資料庫架構不熟悉。但經歷 no-code 工具的培養，就能蠻好的把 PM 需要的基本工打起來。對 PM 職能裡，和技術方合作的能力，也是一個加分項。
結論
以上是目前為止，一些實驗心得分享。這些經驗，我們也整理成了培訓課程。近期的公開課程內容，請見：Accupass 活動通
若有企業內訓的需求，歡迎聯繫：hello@yujing.io 洽詢。