創業團隊如何準時交付正確的軟體產品

作者介紹:

本文作者是姚長安(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. 可參考ScrumAgile建議的工作方法,透過事前的Sprint Planning與Stand-up meeting隨時檢視、調整、修正、改善每個階段的衝刺,確保產品的目標、品質與時間能夠接近預期!

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

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

 

 

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

★ 本文特色圖片來源:pixabay

★ 責任編輯:Vista Cheng

 

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

歡迎關注TeSA的LINE@帳號

好友人數

相關文章

;