分類
教學

系統開發步驟與文件制定

前言

我是一個工程師,專門寫程式的那種,從 VB 6.0 玩到 C++,一路走上來後來寫過 .bat、PHP、C++/MFC、Perl 與 .NET 從前端寫到後端,大致上是這樣。

在某次工作經驗中,被一個高手帶領者完成一個專案,他是寫 .NET 的高手,那時我的角色類似 PM + 客服,所以我主要在老闆、工程師與客戶之間爭吵溝通,造就了這一份心得分享。

如果你想帶領一個專案,卻不知道怎麼作,請嘗試依序完成下列文件,我知道這看起來很多文件很複雜又費工,你一定覺得不合乎成本校益會拖很久,可是我可以跟你說的是,不論文件的多寡,你總體專案開發的時間是不會變少的,也就是說,如果你想要省略某一個步驟,那你只會在其他地方補回來,例如,整體開發專案的時間是兩年,那最好的情況就是兩年,通常只會比兩年多,不論你用號稱的敏捷、瀑布、微服務任何一種開發模式,都是一樣的,開發模式只是讓你在某個環節中知道怎麼做,而不是代表你可以省略或是加快這個步驟。譬如說敏捷開發其實只是在 4,5,6 的階段有一個指標,但是你還是必須完成 4,5,6 的階段。

許多老闆的想法可能都是要快,身為一個 PM,你不應該去滿足任何一個人,包括你的老闆,對!你不能去滿足老闆與你的客戶,你應該要做的是全盤了解整個專案的目的、價值、流程、問題點與進度。你要與你的團隊討論出所有的可能、不可能、能做與不能做,並且你要知道為什麼,別人提出的流程缺點在哪裡,為什麼要採用你的流程/建議,這是說服客戶/老闆,非常重要的關鍵。

文件與步驟

1.願景

如果客戶想要一個東西,那這部份你可以比較快完成,所謂的願景,譬如你老闆想要開發一個新產品但是目前你們沒有客戶,這時候你要跟老闆溝通,嘗試描繪出他要什麼東西,你要找幾個人一起來開會,逼者你老闆講出他要的東西,千萬不要以為你知道他要什麼東西。所以你透過開會,會有會議記錄,或許在多次開會之後,你才拿抓到你這個產品的願景圖是什麼。
產出:
會議記錄, 願景圖(Road map)

2.研究 + 討論

依照 Road map ,收集需求與制定原則(Policy),開始找一個懂的人,或是公司內部的 key man 來聊天,如果找不到,表示你們公司沒有人懂這東西,所以很危險,你們會做出自己以為會賺錢的東西。你可能需要:
(1) 外部專家會議
(2) 內部教育訓練、內部討論
產出 :
需求書(草案)
原則書(草案)

3.需求系統討論

依照 需求書 與 原則書,討論需求與原則,確定每個需求與原則都是可能的,並且列初步可能的項目,列為原則,然後制定資料與系統流程圖。

需求 = 可以改變的東西,譬如: 這個按鈕是紅色。原則 = 無法變更的項目,譬如:系統使用 Linux 為底層。

產出 :
需求書(定案)
原則書(定案)
資料與系統流程圖(草案)

4. 系統概觀討論

依照 需求書(定案) + 原則書(定案) + 資料與系統流程圖(草案) 確認系統流程符合規格,
產出 :
資料與系統流程圖(定案)
系統架構圖(草案)

5.系統分析

依照 資料與系統流程圖(定案) + 系統架構圖(草案) 切割系統, 建立 架構圖/系統模組/程式
產出:
系統架構圖(定案)
系統階段開發說明書(草案)

6.系統細部討論, 測試方法討論

依照 資料與系統流程圖(定案) + 系統架構圖(定案) + 系統階段開發說明書(草案) 討論
產出:
系統階段開發說明書(定案)
系統說明書(草案)
系統測試書(草案)

7.系統開發 + 例外討論 + 衝突討論 + 修正

產出:
系統說明書(草案)
系統測試書(草案)
軟體系統 Alpha

8.系統開發 + 系統測試

產出:
系統說明書(定案)
系統測試書(定案)
軟體系統 Beta
部份測試文件

9.專案收尾

所有文件:
需求書(定案)
原則書(定案)
資料與系統流程圖(定案)
系統架構圖(定案)
系統階段開發說明書(定案)
系統說明書(定案)
系統測試書(定案)
測試文件

10.系統

軟體系統 1.0(stable)

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *