軟體專案開始之前
先來回覆一下讀者來信
這系列的投影片風格
你也看得出來很特別
這叫做高橋流
至於內容
是我一個好朋友託我寫的
主要是為了給硬體出身的 PM看
讓他們大概知道硬體跟軟體的不同
才不會被軟體公司牽著鼻子走
或是對客戶說出一些荒唐的
話
對我自己來說
正好可以把自己的思緒整理整理
有人問到
軟體的囤貨是什麼意思?
我自己的想法是
所有寫好了但沒有為公司帶來直接或間接
的收入的程式
叫做軟體的囤貨
對 PM來說
這其實不重要
可以當作是 RD們在磨練技術的一段時間
的半成品
(廢話,那就是囤貨 )
但囤貨通常不是重點
是有時間讓 RD能加強自己的能力
好了
大概回答到這邊
有問題也可以隨時在留言中提出
好要開始了
這次要談談在專案開始前的事
是的也就是需求
對於身為發案方的你來說
最根本的需求就是把軟體做出來
就這麼簡單(雙手一攤 )
但對於開發團隊來說
你不說的我不知道
你以為理所當然的我以為完全不用做
所以務必要把需求講清楚
這邊我建議以下的流程
第一步
說故事
在軟體裡面
很多功能是很難用文字表達的
所以很多軟體的案子在最開始的時候
也就是還在 cook的時候
會用說故事的方法
來說出倒底想做出什麼軟體來
這我相信不難
然後
第二步
由業務或軟體PM
來把你說的故事切成小故事
而一個小故事大概就是一個使用情境
然後開發團隊才知道
大概這個軟體要長怎樣
一般會稱作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
假如他們夠專業的話
ㄎㄎ
下一篇仍然會接著講
專案開始前的事情
就講到這裡啦掰