需求變更 的 反覆模型
TRANSCRIPT
需求變更的
反覆模型
Ben Lau
來自香港
上年 COSCUP 2011
也講了一場Lightning talk
題目:『嵌入式開發
的一則小故事』
講述一位小小的工程師
多艱難才拿到 GPL Kernel代碼的故
事
是個很痛苦很悲哀的故事
但大家笑得好高興
這太沒有同情心了吧?(笑)
雖然我的國語真的很爛 ...
今年又再講
痛苦的故事
需求變更的
反覆無常
先聲明
以下內容純屬虛構
如有雷同實屬不幸
在專案開發到一半的時候 ...
你喜歡修改嗎?
喜歡?
討厭嗎?
但你是專業的!
怎能不改?
現在說這句話的那位在來台灣前幾天每天只睡 3 4﹣ 小時
錯誤示範
一般來說,修改的來源有二個
客戶
老闆
但我不喜歡這麼叫他們 ...
神
神說
要有光
就有了光
但是 ...
會說:太光了
又說:太暗了
彩色好不好!?
喜歡大型動物時
就有了恐龍
不喜歡時
就拋了顆殞石落去
可憐的是
其他動物 ...
以上的神不屬於
任何宗教的神請見諒
但如果你把老闆當成神
你的生活會好過一點
但我不信神
所以生活都很苦
幸好有了 Agile
傳統的Water Fall / 瀑布開發流程
需求階段後就不會再改
永遠不變的
只有變化
Agile
2星期改一次總好過朝令夕改
工程師被解放了!
才怪
修改的來源才不可能衹有客戶及老闆
我想提出用這個模型來代表一間公司及需求變更
行銷:拿掉這功能,客戶之後會多拿一點錢出來
營運:上線前一刻我們發現有個問
題 ...
工程:這個要求我們做不到,請改
成 ...
設計:這樣會好一點
設計:這樣會再好一點 ...
設計:這樣會更完美
只要有心 人人都可以是神
這不是最麻煩的問題
客戶的要求一般是這樣傳達的
即使是同一間公司
每人收到訊息的時間並不一致
而且內容也可能不一樣
有些人會不知道 (留意工程那部份)
一個假設性的故事 ...
某天,在一間 Cafe閒聊時
權威人士:功能 X拿掉吧,現在是 Just
works的時代
某天老闆路過工程部見到菜鳥 A
『你知道 Apple為什麼成功嗎?因為
Just Works (刪掉20 分鐘的說教)把功能 Y 拿掉吧。』
菜鳥 A說:「老闆要我們拿掉功能Y,原因,呀,呀,呀 ...」
展示那天
管理層大罵:「怎麼功能 Y沒有了?」
推出後
老闆罵管理層:「怎麼功能 X還在!?」
囧
到底應該做什麼啊!?
God Knows.
因為剛才的模型變成了這樣 ...
一片混亂
每個人的認知也不同
需求變更的傳遞不是直線的
需求變更是可以變質的
需求變更的內容是可以反覆回彈的
否決過的要求,有天可能會變成Zombie回來
需求變更本身並不可怕
你是專業的!
沒有中央管理的變更才是惡夢
(剛才的模型就是為了說明這個現像)
Agile還是能幫你
星期 X+2 -加入了功能 Z
星期 X+4 –功能 Z被取代
星期 X+12–Z又要復活了
砍掉重練好玩嗎?
不能再放任這問題
你可以試一試拜神 ...
請一個 Product Manager回來
讓他告訢你什麼該做
或者請一個 Release Manager回來
讓他協助你,跟所有的神溝通。
或者自救
教會你的上司什麼是 Release
management
跟上司說:
(偷偷告訢你Product Manager比
Project manager更加威風啊 )
但別要求許多許多的文件
有很高的機率會變成文件地獄
這比沒有文件更糟糕
剛剛好的文件數量
但誰知道什麼是剛剛好?
成為
邁向神境的Programmer
越好的軟件設計
越容易應對修改
只要有心,人人都可以當大大
世界一直這樣運作
就是因為沒有人去改變
請走出第一步
讓工程變成樂趣
願各位
不被需求變更折磨
都有健康的肝臟
謝謝