產品開發
昨天到工程師場子分享，想說跟大家對照一下，現在是否多數人都跟我一樣，寫程式完全不手打任何一行 code，全部都是 AI 做的。 結果發現，現場只要有在用 AI 開發的人，多數時候真的都是讓 AI 來完成程式撰寫工作。 目前我的開發組合是 Claude Code / Claude Design / Fly.io / Github / Cloudflare，其他還有根據程式功能需要而使用的第三方元件。 做一個新系統的習慣是： 1. 跟 Claude 討論我想解決的問題，以及我的核心需求，中間我可能會用 Claude Cowork 做本地資料的分析，然後請他廣泛收集一下資訊，做幾輪 prototype 的模擬。確認方向是否是我所期待的。 2. 對完需求後，請他產出系統定位、限制、邊界與 PRD。 3. 把 PRD 跟幾個
產品開發
2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。 在這堂課程中我繪製了一張軟體開發過程管理的架構，這張圖我從公司策略->產品策略->需求管理，一路到開發過程管理、交付、市場回饋，最後再回到產品需求管理。 當年我曾說過，軟體開發最重要的其實不是程式開發本身，而是 align 公司策略與產品策略，同時兼顧好短期需求，將需求管理做好。 但我們也可以看到產品需求管理是上述架構中最主要的節點，上承策略，下接短期需求，右邊則是成為所以開發計畫的起頭，同時還要承接來自市場回饋，並能持續優化管理過程與技術債務管理。 簡單的說，決定做什麼，決定了產品定位，決定先做什麼，則決定了策略重心。但要做出決定，除了對目標有清晰的認知外，更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。 這陣子透入 AI 開發後我對這張架構圖有一些新的想法： 首先，是生產力過剩。 因為 AI 不用休息，生產力幾乎沒上限，
產品開發
之前用 AI 寫程式，比較 free style，簡單說，就是功能能運作就好，反正就解決單點問題，就算是個商業應用，也大多設計成可以離線使用，架構很簡單。 但最近為了要完成我 Growth OS 的野望，我又回到以前工程師年代，會很在意目錄架構、資料結構、資料流、權限控制，甚至也會思考更多關於擴展性、多租戶、系統邊界設計的問題。 也因為有較深入的思考，對於 AI 參與開發這件事，我有了多一點的體悟。 Rule-baesd 模式 從前的程式開發大多是建立在有明確規格之後，演算法就像數學公式一樣，輸入什麼樣的參數，往往就能得到一個可預期的結果。 簡單的說，就是「確定性」，所以以前的測試根據的是輸入 A/B，是否得到 C 結果。 直到現在，如果我們對一個程式的執行結果，最主要看的是「確定性」，也就是執行一百次都要得到可預期的結果。
產品開發
當 Vibe coding 興起後，有愈來愈多的資深工程師的工作重點轉換到修復 AI 寫出的各種 bug。因這個現象，有些資深工程師們打趣地說，他們現在的任務像是專門處理這些 vibe coder 寫出來的爛 code。而這個職務稱為 Vibe Coding Cleanup Specialist。 我個人絕對支持 vibe coding，因為這是軟體開發的典範轉移，用得好的話可以大幅提升生產力，加上 AI 顛覆職場的趨勢幾乎不可逆。擁抱變化會比抗拒變化更明智。 這讓我回想起 2005 年剛出社會時，因為我起步的程式領域是 C#.net，使用的開發工具是 Visual Studio。C# 的好與壞我就不提了，但在當年，Visual Studio 這工具被稱為地表最強 IDE 應該是沒問題的。 它有多方便呢？所見即所得，元件直接拉到畫面上，出來的畫面就長那樣，
產品開發
近期閱讀了一份文件，內容是關於大語言模型對軟體開發工作的影響，文件的連結在這：Assessing and Advancing Benchmarks for Evaluating Large Language Models in Software Engineering Tasks 這份文件聚焦於大型語言模型(LLMs)應用於軟體工程(SE)領域的效能評估。這是個有趣的題目，所謂的效能，簡單的說就是能直接在該工作任務中大幅增進效能的比例。 大家都知道現在的 AI 寫 code 已經不是什麼大不了的事，但透過 vibe coding 寫出來的 code 真的可以用嗎？符合需求嗎？品質可以嗎？能被維護嗎？ 關於這些問題，我們要如何衡量 AI 的有效性呢？目前的答案是透過 Benchmark(基準)。 舉例來說，之前有的 benchmark 叫 SWE-
產品開發
早上聽 Lenny 專訪 Revolut product head Dmitry Zlokazov 的內容，Revolut 是一家位於倫敦的科技公司，專注於提供金融領域相關的軟體服務。在這個專訪中我聽到幾個很可能是接下來產品經理定位的轉變。 Revolut 在找什麼樣的人來擔任產品負責人？以及如何培養他們成為全球等級的產品負責人？ 重視原始智力與飢渴感 在招募時，比起應徵者豐富的經驗，更看重他們的原始智力 (raw intellect) 和渴望打造事物的永不滿足的飢渴感 (unquenched hunger to build things)。有飢渴感的人就算經驗較少，也能快速學習、適應並推動改變並解決問題。 而 Revolut 也更傾向於招募那些處於早期職業生涯 (early in their career) 或具有創業背景的人。 專注於不懈的執行 如果一件事情只完成了 99%，那它更接近 0% 而不是 100%。這包括確保產品不僅僅是開發完成，還需要確保客戶服務、銷售和行銷團隊都能充分利用，否則它可能只是一個無人知曉的無用功能。
產品開發
最近兩個月，同溫層中興起一陣直覺式開發(vibe coding)的風潮，鼓勵大家用自然語言進行軟體開發。短時間內我就看到許多非技術背景的朋友們紛紛跳下來嘗試，也有些人真的做出一些有趣的東西。 我認為這種讓沒有技術基礎的人，也能開發軟體的概念，其實跟早些年 Windows 95 的圖形化介面，讓不懂得命令列(command line)的人也能使用電腦是相似的概念。 這是資訊科技進步的必然。再往下一階段，腦機介面的突破，還會進一步讓那些語言表達能力沒那麼好的人，也能透過腦袋中的想像來跟電腦互動，讓電腦幫忙完成程式開發。這很可能是下一波人機介面的革命。 但在這種革命發生的早期，許多的配套工具還未完善，但已經開始有大量的人投入使用。這些人寫出了一大堆無法維護，甚至無人能清楚解釋，但又運作正常的程式碼，這等同於創造了大量的技術債務。所以也有另一派人在討論，vibe coding 產出大量難以維護的程式碼，未來維護這套軟體的人將會身受其害。 從前寫程式的進入門檻較高，所以寫出來的程式再怎麼糟糕可能都還有人知道怎麼維護，所以 junior engineer 可能會寫出一些爛 code，但數量
產品開發
延續前一篇AI 時代的軟體開發變革-趨勢，本篇接著談我認為軟體開發即將發生的其他改變。 系統邊界的改變 - 先談客製化 在AI 時代，系統的 codebase 我認為會變小，也就是預先定義，並且被開發出來的功能會減少。或者大家可以解讀為，許多功能會由 AI 完成，甚至是不寫 code 就完成，因此實際人類要寫，或由 AI 代勞寫出來的 code，整體應該是減少的。 但因為 AI 的出現，也讓系統本身得以延伸，包含讓自己成為一個資訊中心，將自身的功能與數據極大化的與其他系統連結，又或者反過來，跟盡可能多的系統進行數據交換藉此完善自身功能。 在這邊先援引 Happy 的文章： AI 時代下的軟體產品發展指引AI 正在重塑軟體開發，未來的軟體產品將不再需要完整實現所有功能，而是透過 AI Agent 動態生成客製化功能，滿足不同客戶的需求。軟體產品應該專注於開發 核心功能 + AI Agent
產品開發
前陣子一直想寫這個題目，因為我認為未來的產品開發，將因為 AI 的出現有劃時代的改變，這變革或許不亞於當時數位時代的來到。 在往下談論主題前，我們可以先問問自己，過去一年的時間，我們對 AI 能做的事是否有了全新的改變？ 以我自己為例，我半年前曾說：「AI 目前的不足之處在於處理技術債，也就是維護的難度還是很高。」半年時間過去，我現在認為這不會是很複雜的問題了，一來是因為 AI 又進化了，推理能力更強了，還懂得反問好問題；二來則是因為當時我對 AI 的期待太高了，我希望他全知全能，但其實為他做好角色設定才能發揮他最大的效果。 半年前我無法想像他能直接解讀一份我給的文件或者某個架構圖，但近期我嘗試的結果卻發現他解讀正確的成功率之高，根本超乎我預料。而當我根據他的回應再補上一些資訊落差之處，他幾乎就能 100% 產出我所期待的內容。這種理解能力與產出品質，幾乎超越了 90% 以上的人類。 這讓我更確信，人類在軟體開發工作的未來，絕對不會是在 AI 擅長的領域，而在於創造、設計、決策與溝通。 前陣子我曾援引 Sam
產品開發
上一篇中我們提到了技術債，本篇就來分享另一個重要觀念-測試左移(Shift Left Testing)。 我們先來看一張很有趣的圖，這張圖的橫軸是開發階段，縱軸則是bug被修復的成本。從圖中我們可以看到 bug 如果發生在需求討論概念的階段，要修復的成本非常小，但隨著需求進入設計、開發、測試、發布階段，bug 的修復成本就以指數型成長。 舉一個很簡單的案例來說，想想，老闆有一天提了一個天馬行空的想法，現場的與會者每個人都對這個需求的效益感到疑惑，但礙於老闆的權威，沒有人敢提出質疑，所以這個需求就排入計畫開始進行設計，而在設計階段設計師們發現這個需求似乎跟現有的用戶需求間有所衝突。 比較理想的做法或許是重新討論這個需求的必要性或針對衝突的處理方式，但設計師覺得沒必要去挑戰高階主管們的決策，因此也硬著頭皮規劃了另一個功能分支，專門提供給對這個新需求有需要的朋友，從這個時間點開始，產品的功能就在主線之外，開始有了第二條分支。 來到開發階段，技術團隊一般不太對 PM 與設計師設計好的內容提出太多的 challenge，頂多說說這樣設計會帶來多少額外的工作量。而進入開發階段也意味著這個需
經營管理
在企業管理上，若要針對最棘手的問題排名，我相信如何決定優先順序，如何平衡長期與短期策略一定排在前三位。 針對這個議題，很多的商業或管理書籍都有探討，但始終缺乏一個很有效的決策框架來協助企業判斷該怎麼做才正確，因為這件事涉及到的因素非常多，企業的財務狀況、風險承受能力、所具備的資源、企業的發展階段、產品組合、短期市場的波動、長期市場的預測、管理制度的健全、企業領導階層的素質等，若只影響單一個項目或許容易判讀，一但這些項目都攪和進來，處理的難度就很高了。 我本身有個框架可以協助企業做有效判斷，但本篇我先針對長/短期策略之所以難以平衡的原因，以及有哪些基本的原則可以協助我們簡化任務的優先順序問題，進而做好長短期的平衡。 企業遭遇的現況 2015 年時我到一家 7*24 小時運轉的互聯網公司上班，到職時，我就發現團隊花在「救火」的比重過高，真正處理重要專案的時間嚴重不足。當時團隊成員們對既有系統，規劃了許多需要優化的地方，但往往不敵緊急案件的壓力。 重要的專案一再 pending，所有人都忙於不處理就沒業績，不處理客戶就退錢的案件。 到後來根本不分輕重緩急、優先順序，只要業務或客
產品開發
在軟體開發的世界裡，有一個經常被提起的難題，那就是如何有效的量化一個需求或一個專案的價值。在數據脈絡中，我提到，如果今天我們能找到價值衡量的基準，我們就能有效地進行手邊任務的排序。 但這個基準怎麼設計，又該怎麼獲得大家的共識呢？是否有一套結構化的方法呢？有的，本單元我就來跟大家好好介紹一下過去我是怎麼做的。 企業的優先順序是如何被決定的？ 過去經驗裡企業決定專案順序的方法通常有三種：權力決、數據決與共識決 第一種，權力決，通俗一點來說，就是由權力大的人來決定，排第一的通常是老闆或業務部門最高主管。權力決有另一種變形，那就是讓承擔該業務的主要負責人做決定，例如產品經理決定產品優先順序，業務主管決定業務需求優先順序。 權力決得好處在於，讓應該承擔責任的人來做決定，做對做錯他一力承擔，很容易究責，但缺點也是顯而易見的，決策過度集中，且決策的優劣仰賴一人之智，萬一他不是那個適合的人怎麼辦？ 第二種，共識決，由大家共同決定專案的優先順序，嚴謹一點的甚至會成立一個委員會來定期處理此事，讓決策從一個人身上移轉到一群人身上。好處是決策因參酌了較多人的意見，會變的比較客觀，但缺點是，當大家