軟體專案開始之前

先來回覆一下讀者來信

這系列的投影片風格

你也看得出來很特別

這叫做高橋流

至於內容

是我一個好朋友託我寫的

主要是為了給硬體出身的 PM看

讓他們大概知道硬體跟軟體的不同

才不會被軟體公司牽著鼻子走

或是對客戶說出一些荒唐的

話

對我自己來說

正好可以把自己的思緒整理整理

有人問到

軟體的囤貨是什麼意思？

我自己的想法是

所有寫好了但沒有為公司帶來直接或間接

的收入的程式

叫做軟體的囤貨

對 PM來說

這其實不重要

可以當作是 RD們在磨練技術的一段時間

的半成品

(廢話，那就是囤貨 )

但囤貨通常不是重點

是有時間讓 RD能加強自己的能力

好了

大概回答到這邊

有問題也可以隨時在留言中提出

好要開始了

這次要談談在專案開始前的事

是的也就是需求

對於身為發案方的你來說

最根本的需求就是把軟體做出來

就這麼簡單(雙手一攤 )

但對於開發團隊來說

你不說的我不知道

你以為理所當然的我以為完全不用做

所以務必要把需求講清楚

這邊我建議以下的流程

第一步

說故事

在軟體裡面

很多功能是很難用文字表達的

所以很多軟體的案子在最開始的時候

也就是還在 cook的時候

會用說故事的方法

來說出倒底想做出什麼軟體來

這我相信不難

然後

第二步

由業務或軟體ＰＭ

來把你說的故事切成小故事

而一個小故事大概就是一個使用情境

然後開發團隊才知道

大概這個軟體要長怎樣

一般會稱作User Scenario

或是叫做我比較喜歡的User Story

這些小的 user story

也是你與開發團隊的最基本的共識

這也是我很建議的方法

由發案方說故事

由接案方切成 User Story

第三步

身為發案方 PM的你

請要求接案方的軟體PM展示解決方案

比如說要用到什麼 server

什麼平台程式語言是用哪種

database是用哪種等等

這些東西看不懂沒關係

是為了讓軟體開發團隊對專案的樣貌有個

overview

不然傻傻做一下就爆了

第四步

請你 prioritize這些功能或 user story

有哪些東西是你希望優先看到的

而

如果專案不幸 delay了有哪些是可以捨棄的

第五步

把用的資源列出來

比如說

這個某某專案

成員有 8個其中 5個 RD

2個 QA1個 designer之類的

估計時程約為 3個月之類的

怎麼估計？請看前一篇

以上是我覺得專案 kick off前要做的

事情

其中不管是發案方接案方

都有很多事情要做

然後需求大概就完成了

假如你的開發團隊是

waterfall的

你最好檢查再檢查

再檢查 ...

再檢查一次

因為

對於waterfall團隊來說

要殺死他們最快的方法

就是三不五時更改需求

不是開玩笑的

面對waterfall團隊

一直更改需求的話

會喪失士氣

做出來的軟體品質也不會好到哪去

同時

這也代表了

發案方的你沒有做好你的工作

當然你會說

吃芝麻哪有不掉燒餅的

需求總是不小心要改

如果要改

請給團隊充裕的時間

不要壓他們 deadline

犯錯的不是他們

是你

也因為軟體的特性(請見第一篇 )

我建議

在waterfall的開發階段

還是要設立一或兩個milestone

大家來看看現在狀況到底有沒有不對勁

就當作是 DVT EVT 吧

相對的

假如你的團隊是 agile的

請在整理需求的時候

最重要的幾個需求或是 user story 準備

好了

就可以要求團隊開工了

然後寫好 測試以後

馬上驗收這幾個需求

假如發現團隊做的不是你要的

請立馬新增一個需求

把產出物改回你要的方向

在此同時

請趕快把下一群重要的user story 準備好

以上

這篇說的有沒有看懂啦？

這篇其實還好只要把故事說出來

對方團隊應該都會接下去做

他們會把你的故事轉化成 spec

假如他們夠專業的話

ㄎㄎ

下一篇仍然會接著講

專案開始前的事情

就講到這裡啦掰