產品開發
當 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-bench，
產品開發
早上聽 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，所有人都忙於不處理就沒業績，不處理客戶就退錢的案件。 到後來根本不分輕重緩急、優先順序，只要業務或客
產品開發
在軟體開發的世界裡，有一個經常被提起的難題，那就是如何有效的量化一個需求或一個專案的價值。在數據脈絡中，我提到，如果今天我們能找到價值衡量的基準，我們就能有效地進行手邊任務的排序。 但這個基準怎麼設計，又該怎麼獲得大家的共識呢？是否有一套結構化的方法呢？有的，本單元我就來跟大家好好介紹一下過去我是怎麼做的。 企業的優先順序是如何被決定的？ 過去經驗裡企業決定專案順序的方法通常有三種：權力決、數據決與共識決 第一種，權力決，通俗一點來說，就是由權力大的人來決定，排第一的通常是老闆或業務部門最高主管。權力決有另一種變形，那就是讓承擔該業務的主要負責人做決定，例如產品經理決定產品優先順序，業務主管決定業務需求優先順序。 權力決得好處在於，讓應該承擔責任的人來做決定，做對做錯他一力承擔，很容易究責，但缺點也是顯而易見的，決策過度集中，且決策的優劣仰賴一人之智，萬一他不是那個適合的人怎麼辦？ 第二種，共識決，由大家共同決定專案的優先順序，嚴謹一點的甚至會成立一個委員會來定期處理此事，讓決策從一個人身上移轉到一群人身上。好處是決策因參酌了較多人的意見，會變的比較客觀，但缺點是，當大家
產品開發
某次在一個技術社群中分享關於敏捷的議題，演說後有一位年輕夥伴問了我一個問題：「公司內有很多 legacy code，架構疊床架屋，時常改A錯B，跟老闆溝通了很多次，但始終排不進去工作中，永遠都被業務的需求排擠，在這種公司工作，很無奈，怎麼辦？」 我告訴他：「這是很棒的一件事，技術債是屬於活下來的公司，而技術債會愈來愈嚴重，某種程度也代表公司還在成長與發展，正面來看是一件好事。」 我也跟他分享了我看過的各種可怕技術債，但這些滿滿技術債的公司，它們卻是逐年在成長，而且活得還不錯。如果技術債是不好的，那為何這些公司沒有因此而倒閉呢？ 「你怎麼看待『債』這種東西？它一定得償還嗎？」 如果你跟銀行借款，當你手上有錢的時候，你會立刻一次還清嗎？還是你會逐月逐月還，然後留些錢在手邊作其他用途呢？我相信多數人會選擇後者，留一部分的錢在身邊。為什麼呢？很大一部分原因是因為那些債並沒有立即償還的迫切性，也就是說選擇負債，但讓手邊有充足現金，對自己來說，有時是相對聰明的選擇。 對產品團隊來說，開發資源就如同手上的現金，這些資源是投入在償還技術債，或者開發新的需求，一樣也得從價值的角度來思考。 債
職場與工作技巧
2024 年 4 月份 Sam Altman 提出 One-person unicorn 的時代來臨了，他強調的是在不久的將來，可能會有一些公司只有一位 CEO，其他的工作全部都由 AI 來完成。而且這樣的公司不見得就是傳統小規模的一人公司，而是有機會成為一家獨角獸公司。 經過這半年多對 AI 的學習之旅，自己天天用 AI 工具，並用 AI 工具來解決具體問題。也聽了許多公司如何使用 AI，並參與了一些公司的開發團隊使用 AI 做軟體開發的過程。 我想藉由這篇跟大家分享一些我對 AI 融入工作與生活的想法。 相信 AI 做得到 我相信現在還是很多人在探討 AI 「做得到什麼」與「做不到什麼」。而這種想法的背後，往往是為了找到不使用 AI 的理由。 例如透過 AI coding，
產品開發
幾年前吉姆柯林斯出版了《十倍勝》這本書，書中談到了 20 哩行軍的故事。後來這個故事被廣泛地拿來作為商管的教材，多數的觀點談論的是關於紀律，部分則更著重於探討不確定性。 多年前我在講專案管理課程時，我也會以 20 哩行軍作為開頭的案例，鼓勵大家思考，從這個案例中，我們到底能學到些什麼。今天我想用這篇文章，再次深入探討這個故事所能帶給我們的啟發。 不過因為年代久遠，許多的史料以不全然可考，我僅就我能收集到的部分做了考究，內容肯定不完整。加上歷史往往是成功者撰寫的，所以真相是否真如往上文件所陳述我也不得而知，但我們姑且把這當成一個半虛構的案例來討論，試著從這個案例中有所學習。 關於背景 19 世紀末至 20 世紀初，隨著科技的進步和地理知識的擴展，探險成為一種流行的活動。許多國家對於探索未知的極地地區充滿了熱情，尤其是南極點被視為人類尚未征服的最後邊疆。 與此同時，探險也被視為國家實力和民族自豪感的象徵，成功抵達南極點不僅能為國家帶來榮譽，也能吸引資金和支持。 而在當時，有兩支比較知名的南極探險隊，他們的領隊分別是： 羅爾德·阿蒙森（Roald Amundsen）是挪威探險