沒藥醫

May 17 22:35~23:30

Teddy 的第一份工作是在一家只有 10 來人的純軟體小公司開發軟體，由於 Teddy 原本是念電子的，因此剛出社會對於軟體工程的知識所知有限，所以當時遇到的軟體開發問題，主要分成三大類：

• 需求問題：如何從顧客身上『撿到』可用的需求，用何種格式撰寫需求，如何訂定需求的優先順序，如何將需求順利的轉變成軟體。
• 技術問題：JDBC 要怎麼用，Java Applet 要怎麼寫，Web applications 要如何開發，要如何用 javascript 寫動態與互動式網頁，要如何透過 web cam擷取影像，exceptions 要如何處理，design patterns 要如何套用，軟體架構要怎麼設計等等隨便都可以再列個幾百個項目。
• 流程與專案管理問題：當軟體開發團隊逐漸成型之後，如何讓團隊運行順暢的共同開發軟體就變成一個重要且必須面對的課題，否則軟體開發只會事倍功半。

在這邊 Teddy 要考考鄉民們，以上三個問題，那一個最重要？

都很重要...廢話...嗯嗯...如果從 programmers 的角度來看，可能會認為技術問題最重要，因為技術問題沒有解決軟體就做不出來。從 PM （專案經理）的角度來看，可能會認為流程與專案管理最重要，因為不管用哪種技術去實做，反正東西給我生出來就對了。

等一下... 那...難道需求不重要？或是換個方式問，誰會覺的需求最重要？

答案很簡單，當然是客戶，因為『理論上』他們是最後要使用軟體的人（有些軟體做出來之後其實沒有人用...所以，只能說『理論上』客戶是最後會使用軟體的人）。如果做出來的不是他們要的，那麼時間與金錢就浪費了。
 

***

問題來了，如果你是開發公司的『產品』，還沒有真正的客戶，那麼在公司『高層』的豐富想像力之下，某種『極端』卻又『很常見』的問題就會發生，那就是軟體需求最後變成包山包海，亂七八糟的大怪獸，東西做好也賣不出去，大家白忙一場。

N 年後的今天，自我感覺良好的 Teddy 軟體工程的功力已經變得很強了。以 Scrum 為例，在 Scrum 的框架之下，技術，流程，與專案管理的問題都還有的救。但是，Teddy 要告訴鄉民們一個大家老早都知道的事實：需求出問題就真的是沒藥醫。

會想到開發類似『咖啡豆漿機』或是『雲端殺豬系統』的人，其聰明才智絕非常人能比，且其位高權重，不是『聖上』就是『親王』，『三朝元老』，『軍機大臣』等級的人，那一個你得罪的起？如果誰不長眼拆穿了『國王的新衣』，那麼下場可是......祝恐怖......。

如果有人想問：『在 Scrum 中如何解決需求並非客戶真正所需的問題？』 答案很簡單：

• 換掉 product owner ...... 背後的黑手....可能是『聖上』，『親王』，『三朝元老』，『軍機大臣』。
• 換工作。

第二點可能會比較快...不過，誰能保證『下一個老闆一定   會更好』（這一句要用唱的）。

***

友藏內心獨白：拜託，就算軟體架構設計的好，也不是這樣讓你拿來隨便亂加需求滴。