需求變更 的 反覆模型

需求變更的

反覆模型

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

越好的軟件設計

越容易應對修改

只要有心，人人都可以當大大

世界一直這樣運作

就是因為沒有人去改變

請走出第一步

讓工程變成樂趣

願各位

不被需求變更折磨

都有健康的肝臟

謝謝