軟體開發專案流程大解密— 了解產品開發的各階段每個團隊成員在忙甚麼?
前陣子剛把一個專案產品順利推上線，彙整了一下過往開發產品的專案經驗整理起來跟大家分享。因為我過去是工程師的背景出身，又兼有帶產品經理、專案經理和 UIUX 設計師的經驗，打算透過一系列的文章，聊聊軟體產品上線的流程。
每家公司產品開發的過程可能不同，但多少都會經歷以下幾個階段:
需求訪談 →規格定義 →執行評估 →工程開發 →驗證測試 →上線營運
接下來，我們就來展開每個階段，詳細說明每個步驟。
需求訪談
需求從客戶而來，比如說有時候是老闆想要開啟作某個專案，像我最近兩份工作都是甲方，自有品牌的軟體服務(甲方)，需求主要是從老闆的腦海中開始構思某個產品，再交由公司 PM 或是 UIUX 設計師去發想討論。
若公司一開始沒有設計師的角色，那就是老闆自己想辦法把產品生出來。當甲方公司推出第一代產品銷售業績不錯之後，接下來就會有很多機會收到用戶回饋的聲音，這部分就包括對現有產品改善的建議、使用上 Bug 的反饋…等等。
另一種型態，如接案公司(乙方)，接收到某個需求，如果讀者不清楚的話可以連上任一個接案平台(Tasker)，登入之後可以看到比較詳細的案件描述。
過去曾經與非軟體業的業主朋友聊過接案的過程，只能說隔行如隔山，業主通常會把想像的範疇定義的龐大又兼具智能化。無奈資源始終有限，這類型的案件前期就需要花比較多的時間溝通，這也是乙方公司在經營上困難的地方。
備註:甲方，自有品牌，乙方，協助甲方完成甲方想要有的軟體產品，可以想作是甲方的外包團隊。
規格定義
當前項需求已經漸漸收斂，此時就會有專職的 PM(專案經理，以下假定公司會有一個這樣的角色，但不限定於該 PM 本質是老闆、設計師或是工程師)。將需求減化成User Story，並用 User Journey Map 將每個 User story 填到對應的位置，雖然現在工具很多，但其實 Excel 或是 Google Spreadsheet 就可以把這樣的內容表現出來。在規格定義時，可能會有以下六項文件 User Journey Map 使用者旅程、Flow diagram 使用流程、Wireframe 低擬真草稿圖、Prototype 高擬真介面圖、Spec 規格撰寫、Copywriting文案內容
User Journey Map，使用者旅程圖
在 Excel or Spreadsheet表格中橫軸可以描述旅程或任務，縱軸則是 Stakeholder，利害關係人(比如: 假想上的使用者或行銷、業務、客服部門…等，不歸在產品開發的同事)，每隔格子則可以寫上利害關係人在該步驟要完成的任務內容。因 User Story 可能會牽涉到多個部門的實際操作，這個時候就要特別與各利害關係人明確定義出相關規格。
Flow diagram 使用者流程
要完成一項工作通常不只是單一個畫面可完成的，因此對應的使用流程要先畫出來。
Wireframe，低擬真草稿圖
用來在前期與工程開發部門或是與各利害關係人討論可行性，。
Prototype，高擬真介面圖
透過前項 Wireframe，PM 與 UI 設計師溝通，將高擬真介面圖繪出，方便跟利害關係人做最後的確認。此時 UI 設計師產出的 Prototype 通常也都是可以直接讓工程師開發的檔案。
Spec，規格撰寫
當前述項目可能完整度到 70~80% 的時候，PM 就可以開始進行規格相關的撰寫，可以依照每個畫面上需要有的元件，及對應互動的流程進行說明，如點擊之後的下一步會發生甚麼事，正流程、錯誤流程、例外處理進行描述。
Copywriting ，文案內容
軟體的互動，在每個介面的交互(interaction)，通常伴隨著許多互動，透過介面上的文字說明，可以讓非程式開發相關人員實際了解未來產品上線後互動的感覺。通常產品開發的過程中，需要多次打磨文案，因此，這個步驟就需要花比較多時間，也可能會橫跨多個部門。
雖然上面的文件看起來種類繁多，但也還是要看每個公司注重的項目而定，並不一定會每項都有。當然如果有的話，整個產品開發團隊做起事來都會比較順暢些。
執行評估
在真的進到開發前，如果前面的文件都準備得差不多，產品團隊的每一位成員不管是 PM、設計師或是工程師都會被要求評估工時，雖然大部分公司的需求都會一直小步調整，但 PM 的就是會被老闆要求在一個時限內，讓產品開發團隊成員把東西生出來。畢竟老闆每天一覺醒來就是在燒錢，資源有限的前提下，越早可以交付產品到市場上驗證(賣得出去)，就可以越早減輕公司營運上的壓力。
工程開發
當產品進到工程開發，相關的工程文件，就會落到 Tech lead 或是資深工程師身上，如軟體架構的規劃，資料庫的 Schema，API 的撰寫。此時對應的 User Case，或是測試計畫如果有 QA 的配置，QA 就會就著「規格定義」中的相關文件，開始寫測試計畫。
如果沒有 QA 的配置，這份工作可能也會落在 PM 身上，大原則就是，只要不是寫程式的事情，設計師也沒辦法幫忙完成的事情，也不太能分給業務人員或是行銷人員的事情，就是 PM 的職責。
驗證測試
產品上線總少不了測試，測試的方式初步可以分成內部測試及外部測試。
內部測試就是工程師本身要作好的 Unit Test(單一功能測試，工程師寫完單一功能需要確認功能是否正確)、Regression Test(回歸測試是指重複執行既有的全部或部分的相同測試)、Stress Test(壓力測試，如電商網站需要考量短時間大量使用者進到網頁的狀態)。
外部測試可分成各部門成員測試，或邀請鐵粉使用者進行產品上線前的測試，又或是上線後，但未有大量宣傳前的使用者測試。
上線營運
通常上線之後，就會有不同管道而來的客戶反饋(或客訴)，此時客服人員站在第一線幫所有產品人員擋著，但這個時間點專案經理也需要找出與客服人員協作的方式。最常見到的就是 Bug issue (錯誤事件)的整理，透過軟體工具(JIRA)，直接在頁面上撰寫。
緊急的需求，就需要讓對應的工程師趕緊處理，再用 Hotfix 上線(只要一修改完成就上線)，如果不是那麼緊急，可能就會被排到 Product Backlog 中，之後再透過固定的 Sprint 會議，決定該項目是否要進到開發階段，若有這樣的需求，可能又會回到最前面的需求訪談開始。
這一系列預計會有 10 篇文章，我打算將過去 7 年自身曾經參予過的專案經驗，整理起來與大家分享，以下是目前規劃的內容，如果有想要知道的軟體開發內容，也歡迎提出來跟我說。
- 軟體開發專案流程大解密 — 了解各階段每個團隊成員在忙甚麼?
- 如何推進專案進程? — 會議記錄的過去、現在與未來
推薦早鳥方案搶先使用
如果你也想了解軟體開發常見的問題，推薦你一個新的生成 AI 服務 — Rebaz.AI。Rebaz AI 獨家專利【教練模式】可以根據你提出的問題，一步步引導你思考，產出真正幫助到你的文字內容！
如果你覺得使用 ChatGPT 還要學提問很麻煩，那就到 Rebaz.AI 試用，目前免費加入，就享有 7 天試用期。
現在 11/11 前只剩 500位，原價 4990 元，現在早鳥優惠只要 2380 元！
👉 點這裡了解 RebazAI
👉 想要知道更有效率的使用 AI ?
👉 按這裡購買 Rebaz.AI 系統，小資族，早點下班方案
下一篇，如何推進專案進程? — 會議記錄的過去、現在與未來
哈囉！我是Jasper，喜歡閱讀，產品設計、專案管理、數據分析，歡迎追蹤，任何關於閱讀的想法都可以提出來一起切磋討論，想看更多內容也可以到下面這些地方逛逛！
Facebook https://www.facebook.com/JasperChang.Startup
聯絡我請至 threeche@gmail.com— — — — — — —
如果你覺得這篇文章不錯，請給我1~10個掌聲，
如果你覺得這篇文章值得跟你的朋友分享，請不吝於幫我轉發分享，
如果你想繼續看到我的文章，歡迎你按下follow來追蹤我的最新文章。
— — — — — — —
