作者介紹：

本文作者是姚長安（Frank）先生，曾經共同創辦Pubu電子書城，目前正在準備第二次創業，計畫創辦HourMasters.com，希望HourMasters能夠成為Personal O2O的Portal，並朝國際化發展。

為什麼當軟體或網路服務公司面臨一波離職潮後，新來的同仁總是會抱怨：沒有規格文件、沒有版本管理、Bug修不完、不如重新開發等耳語。又或者，為什麼交付團隊開發的軟體，就算老闆自己跳下來當QA都還是很辛苦？顯然有穩定性失控的問題！

看到這一段話的人，可能有些老闆想Echo說：「對呀！為什麼？我是不是被搞了？」

在筆者的觀察，會發生此結果的原因往往是：

1. 公司沒有相應的制度（或流程）。
2. 老闆不遵守制度（或流程）。
3. 老闆對正確的軟體誤判。

關於第一點與第二點，有兩個面向：一個是組織架構面，另一個是開發管理面。而關於第三點，筆者只能說，這是God’s feeling了，不論是經驗、時機、品質或維護等，其實都攸關產品的成敗，這種事情就交給老天了。

在組織架構面，公司的產品多半是由老闆發起，然後團隊成員討論，然後交由PM勾勒頁面、動線後，SA進行系統分析，最後交由RD開發。但是一旦老闆突然的想到某個功能很重要，此時PM可能會說：這樣的話會延遲之類的，老闆可能就變成直接對RD要求規格變更，常此以往規格文件便會自然的喪失作用。最後的結果就是產品無法維護或者功能需求崩潰。

另一個面向是開發管理面，最近坊間最流行的開發方法Scrum或者Agile，筆者認為此兩種方法中最重要的部分不是每天stand up meeting，而是衝刺規劃中的內容要：獨立、可量化、可被測試。其中，可被測試又最為重要，換句話說，如何定義出可被測試的規格文件，便是一種以終為始得需求分析。有了可被自動測試的規格，其產出的結果一開始就決定了，穩定性相對就提高了。

而團隊如何準時交付正確的軟體，筆者建議流程如下：

1. 團隊應該建立一個檢查清單，確保該討論的有被討論，被討論的結果有被納入規格文件中（可以是分階段開發，但仍要標示）。
2. 規格文件中有三種測試架構包含：行為測試、可接受測試（類似抽樣檢查，檢查最重要的環節）、單元測試（配合可自動化測試平台檢視）。
3. 規格文件中要包含補充修正章節，確保所有的補充與修正，是書面的、是延續計有主軸中又可以被查詢、理解的。
4. 可參考Scrum或Agile建議的工作方法，透過事前的Sprint Planning與Stand-up meeting隨時檢視、調整、修正、改善每個階段的衝刺，確保產品的目標、品質與時間能夠接近預期！

透過上述的流程，讓老闆與團隊從一開始也許是目標、預算、SEO與程式架構等，都可以事先透過有系統的規劃跟討論，不僅可以提升討論品質，也能減少老闆事後需要大幅調整或插入功能的需求。

關於導入Scrum，讀者可以參考筆者之前整理的筆記。

★ 延伸閱讀：一個八年級生的創業故事：初嚐失敗，卻獲得更多

★ 本文特色圖片來源：pixabay

★ 責任編輯：Vista Cheng

歡迎加入TeSA的LINE@帳號，共同關注電商、創業領域的最新資訊！