產品開發
延續前一篇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）是挪威探險
產品開發
今天下午看到一個 2021 年 Elon Musk 接受專訪的影片：https://www.youtube.com/watch?v=t705r8ICkRw 裡頭提到蠻多產品開發的觀念，包含需求、分工，以及工程師的職責，我個人認為非常值得一看，以下我幫大家摘要了部分我有感觸的內容。 讓你的需求更簡潔 簡化需求，而非複雜化需求，許多工程師會傾向於增加需求或規格，但真正好的做法應該是減法。這個減法理論從 Steve Jobs 到 Elon Musk 都非常推崇，我個人也認為是很關鍵的議題。 在一個產品中，增加東西是容易的，但往往會增加複雜度，當我們總想著增加時，思考解決問題方法時，我們往往只有「增加」這個方向，而不會想著「減少」與「重新設計」。這其實也是所有技術債的成因之一。 而習慣用加法的產品，很容易模糊了產品的焦點。 當產品核心功能不具備競爭力時，很多產品團隊會開始想給客戶更多，而更多經常意味著失焦，
產品開發
近期因為研究 Github Copilot，也一併看了 Figma to code 相關的服務，因為我想生成式 AI 會影響的並不單純是寫程式本身，而是直接影響了整個軟體開發生命週期。 釐清需求，我會考慮直接用 Figma 或其他設計工具搭配 AI 模組直接跟使用者溝通，然後若有雛型可以直接使用應該是非常快的。設計，Figma 應該就夠好用了，Figma to code 還能直接轉出前端程式碼跟 UI flow，也可以省下一些功夫。 Canva 或 Adobe 的工具也能轉成 html，也能省下一些功夫。Pseudocode to code，將虛擬碼轉成程式碼，目前還沒找到其他可以將規格直接轉成後端程式碼的工具，但合理來說，一些做軟體設計、UML 或者 pseudo code 相關的工具應該能做到。 程式撰寫、code review、