軟體開發是什麼？從問題、需求到 MVP 看懂一個產品如何誕生

軟體開發是什麼？不是先寫程式，而是先確認問題、釐清需求、限制範圍，做出可驗證的雛形，才變成使用者真正能用的產品。本文以 Dropbox 為主線，說明 Prototype、POC、MVP 的差異，以及 AI 時代為什麼仍需要這套工程觀。

一、軟體開發是什麼？為什麼不只是寫程式？

軟體開發（Software Development）指的是一套軟體從構想到能被使用者穩定使用，中間所經歷的完整過程，通常包含問題分析、需求規劃、設計、開發、測試、部署與後續維護。寫程式只是這個過程中的一個階段，而且往往不是最先發生的一步。一個團隊如果直接跳過問題分析與需求規劃，逕自開始寫程式，很容易做出「技術上可以運作，但沒有人真正需要」的東西。

Dropbox 的起點就說明了這個順序。創辦人 Drew Houston 遇到的真正問題，不是「我想做一個雲端硬碟」，而是 2006 年 11 月一次搭巴士從波士頓到紐約，途中才發現隨身碟忘在家裡，重要檔案全留在另一台電腦上，完全無法工作——這段Dropbox 起源故事後來也廣為人知。這種在不同裝置間遺失最新檔案的困擾，讓他開始思考有沒有辦法讓檔案自動出現在所有裝置上。也就是說，Dropbox 要處理的核心問題其實是「如何解決跨裝置的檔案同步」，雲端硬碟只是解決這個問題之後，最後呈現出來的產品形式。先有問題，再有對應的軟體設計，這正是軟體開發與單純寫程式最關鍵的差異：程式碼負責實現方案，但方案從哪裡來，取決於問題有沒有先被看清楚。

二、Kickoff：軟體專案不是從開發開始，而是從問題開始

在正式進入設計與開發之前，一個軟體專案通常會先經歷 Kickoff（啟動）階段。這個階段要確認的不是技術規格，而是三個更根本的問題：為什麼要做這個專案、要給誰使用、以及它實際上要解決什麼問題。如果這三個問題沒有先想清楚，後面的設計與開發很容易失去方向，或是做出一堆功能卻答不出「這個產品到底為誰存在」。

Slack 的誕生過程是這種 Kickoff 邏輯很典型的例子。根據Slack 官方說法，Slack 的前身是遊戲工作室 Tiny Speck 開發的線上遊戲《Glitch》，團隊當時規模不大卻分散在不同地點，因此自行開發了一套內部溝通與訊息搜尋工具，用來協調團隊、留存討論紀錄。後來《Glitch》這款遊戲並未成功，團隊決定關閉遊戲事業，但他們發現手上這套原本只是為了解決自己溝通問題而做的內部工具，反而比遊戲本身更有價值，於是把它獨立出來，重新定位為對外提供的產品，也就是後來的 Slack。這個過程說明一件事：很多軟體專案的起點，不是先有一套完整的商業計畫，而是先有一個真實存在、迫切需要被解決的問題，Kickoff 的任務就是把這個問題界定清楚，再決定要不要、以及如何用軟體來回應它。

三、Requirement：把想法轉換成真正需求

問題確定之後，下一步是把它轉換成具體的需求（Requirement），而需求並不等於一份功能清單。「我要做一個雲端硬碟」是一句描述產品形式的話，但它沒有說明使用者真正需要什麼；比較接近需求的說法應該是「使用者需要在不同裝置間，簡單且可靠地同步檔案」。前者直接跳到解法，後者才是在描述需要被滿足的狀態，這個差異會直接影響後續設計的方向與優先順序。

軟體工程上通常把需求分成兩種。功能需求（Functional Requirement）描述系統應該做什麼，例如使用者可以把檔案放進特定資料夾、檔案會自動同步到其他登入同一帳號的裝置。非功能需求（Non-functional Requirement）則描述系統應該具備哪些品質，例如同步速度、系統穩定性、資料傳輸與儲存過程中的安全性。以 Dropbox 為例，「檔案能同步」屬於功能需求；但如果同步經常失敗、速度慢到無法接受，或是使用者的檔案外洩，即使功能存在，產品依然無法被信任使用。這也是為什麼需求分析不能只列出「要有哪些功能」，還必須同時回答「這些功能要做到什麼程度，才算真正解決問題」。

四、Scope：為什麼軟體開發一定要限制範圍？

需求確定之後，緊接著必須決定的是範圍（Scope）：這一版軟體要做什麼、不做什麼。軟體開發中常見的失敗模式之一叫做 Scope Creep（範圍蔓延），也就是原本明確的專案範圍，在開發過程中不斷被追加新功能，導致專案時程一再延後，甚至最後失去焦點。範圍限制的目的不是為了偷懶，而是讓團隊能先把核心問題做好，再逐步擴充。

以強調簡單與專注著稱的 Basecamp（由 37signals 開發）是理解 Scope 概念很好的參照。Basecamp 早期甚至先只做訊息討論這一項功能，待辦事項與時程里程碑都先擱著不做，等實際使用一段時間、確認真正需要什麼之後，才逐步加進來；37signals 也在《Getting Real》中明確表示不打算做複雜的報表分析、甘特圖等圖表統計功能，即使這些功能在其他專案管理工具中相當常見。這個取捨背後的邏輯，是先確保少數核心功能真正好用，而不是一次做出一套功能齊全但每項都做得不夠深入的工具。這也點出軟體開發中一個經常被低估的難題：真正困難的往往不是「知道還可以做什麼」，而是「知道現在應該先不做什麼」，因為每一個被排除在外的功能，都必須有意識地被判斷為「現階段不是核心問題」。

五、Prototype、POC、MVP 有什麼不同？

在正式進入開發之前，團隊通常會先用某種形式驗證想法是否可行，而這個驗證階段又可以再細分成三種常被混用、但目的完全不同的做法。

Dropbox 曾用一支約三分鐘的操作示範影片，讓當時還無法大規模公開使用的產品概念變得具體可見。這支影片很適合用來理解 Prototype 的功能：先讓看的人具體看到「如果這個產品成立，體驗會是什麼樣子」，再觀察市場反應，而不是急著把完整功能與商業模式一次做到位。

Figma 在開發初期，需要先確認一件在技術上還不確定的事：能不能用 WebGL 讓瀏覽器具備足夠強的圖形渲染能力，撐起一套不需要另外安裝軟體、專業等級的向量設計工具。這件事在動手打造完整產品之前，必須先被驗證是否技術上可行，因為如果答案是否定的，整個產品方向都必須重新思考。這種只針對關鍵技術是否可行進行驗證的做法，就是 POC，重點在於排除技術風險，而不是展示完整的使用體驗；至於後來讓多人可以同時即時協作編輯，則是Figma 官方回顧中，團隊確認 WebGL 這條路走得通之後，另一階段才逐步驗證與完成的能力。

Midjourney 最初並不是一個獨立的網頁應用程式，而是先以 Discord 機器人（Bot）的形式推出，讓使用者直接在既有的 Discord 社群裡輸入文字指令產生圖片。從 MVP 的角度來看，這是一個很好的例子：不必先建立完整獨立平台、投入大量開發成本，也能把核心價值直接交到真實使用者手上，觀察大家是否真的願意持續使用，這正是 MVP 的核心目的——用最小的投入，驗證市場是否存在真正的需求。

六、從問題到 MVP：把軟體開發前期幾個步驟串起來

把前面五節的概念串在一起，可以看到軟體開發前期大致會經歷以下順序：

先有一個真實的問題
↓
Kickoff：確認為什麼做、給誰用、解決什麼問題
↓
Requirement：把問題轉換成具體的功能與品質需求
↓
Scope：決定這一版要做什麼、不做什麼
↓
Prototype／POC：先驗證想法能不能被理解、關鍵技術是否可行
↓
MVP：把最小版本交到使用者手上，開始取得真實回饋

用這套順序回頭理解 Dropbox 的發展，可以看到一個清楚的脈絡：先確認「檔案跨裝置同步」是真實存在的問題，接著鎖定要解決一般使用者、而非企業級客戶的痛點；需求可以理解成「檔案自動同步」與「跨平台穩定運作」等具體條件；範圍先聚焦在核心同步功能，而不是一開始就做複雜的團隊協作與版本控制；示範影片先讓構想被看見、被理解；產品上線初期則以精簡功能開始取得真實使用者的回饋。Dropbox 當年並非按這幾個正式名稱逐步執行，但用這套架構回頭檢視，能清楚看出軟體開發不是一次到位的過程，而是每個階段都在回答不同層次的問題，前一步沒有走穩，後面的投入很容易白費。

MVP 並不是軟體開發的終點。需求確認之後，軟體還會進入設計、開發、測試、部署與維護等階段，這正是下一篇「軟體開發流程」要繼續處理的問題。

AI 時代為什麼更需要理解軟體開發？

AI Agent 已經可以自己寫程式、修改程式碼，甚至建立測試，這確實大幅降低了「把想法變成程式」的門檻與成本，也讓 Prototype 與 MVP 的製作速度比過去快上許多。但這並不代表軟體開發的其他階段因此失去意義。AI 能加快程式產生的速度，卻無法代替人判斷「這個問題真的值得解決嗎」，也無法自己決定「這一版應該先做什麼、先不做什麼」；定義問題、判斷需求、控制範圍、驗證結果，仍然需要人的參與與判斷。

Midjourney 先以一個 Discord 機器人推出，而不是一開始就打造功能完整的獨立平台，正是這個道理的具體示範：即使有能力做出更複雜的系統，最小的形式也足以先把產品交到使用者手上、看清楚市場反應，再決定接下來要往哪個方向擴充。這件事在 AI 讓寫程式變得更快、更便宜的現在，反而更值得留意——當產出程式碼的成本大幅下降，真正稀缺、也真正決定一個產品成敗的，就變成了是否有人能持續問對問題、劃出合理的範圍，並且知道該用什麼方式驗證。如果想看這套判斷方式落在真實案例中如何運作，可以參考《AI 程式設計：從截圖工具需求開始設計自己的軟體》這篇文章。這套判斷能力，正是理解軟體開發流程之後才能建立起來的工程觀。