almost 9 years ago

我在兩年多前寫過類似的這樣一篇文章

現在我的想法轉變成:我認為不應該導入,而是應該導入 MDD ( Money Driven Development ) 。

到底現在這篇文章是要闡述什麼邪魔歪道?

重看我當年的那篇文章,我想我寫那篇文章時犯下跟很多程式師,以前從來沒想過的一個問題:對 startup 定義錯誤。

在繼續講下去之前,我想我要把我近兩年來理解到的一些名詞再重新寫一次,後面的文章脈絡才能拓展開來。

Startup

Startup 是有一個點子,你認為可行,於是你想要嘗試這個商業模式,或者是將你想像的概念轉換成商業模式。

Company

而 Company 是你有一個已經稍有形狀的商業模式了,你想固定下來,以一個商業組織的形體去營運。

程式設計師加入多半的是 Company 不是 Startup

絕大多數的程式設計師都是加入 Company(因為 Company 才有錢付給工程師去每天專心優化塑形商業模式),而不是 Startup。只是很多大家以為的 Company 根本連商業模式沒有,天真的以為程式寫出來,交付正確的 Spec ,消費者就會自動買單。

Startup 需要的是不斷探索什麼行為是真的可以賣錢的。為了達到這件事,未必需要寫程式,可以是放需求表單,可以是用露天拍賣,可以是用 FB 訊息交易,可以是用 FB 養觀眾。

這些,可不可以自己寫程式達到?可以,只是成本超級高,高到難以想像的地步。同時,程式設計師通常也不希望做這樣的工作,因為他們會覺得「老闆是王八蛋,什麼都沒有想清楚就叫他們做。」

所以程式設計師通常本質上加入的是一個 company,只有已經確定要做什麼了,程式設計師拿到「確定的需求與模式」,將之塑形。

正常的業界

接下來要討論,為什麼有這樣的爭議。原因在很多的「公司」,進行軟體專案的方式是在一般人眼中是很奇怪的。

首先,他們會任命一個不懂生意也不懂技術的人,其實是一個跑腿人物,負責「跟老闆或 BD搜集需求」再「寫 Spec」再「請工程師完成」,擔任一個翻譯的工作。這個職位叫 PM。這也是大部分專案完蛋的原因。

既然是「翻譯」,那中間的那個人兩邊的語言都不會說,你覺得會發生什麼事情?當然是交付錯誤(與 BD 所要的的解決方案不同)。程式設計師為了解決「翻譯者」能力低落的問題,主張中間應該不需有翻譯。所以開始主張 BDD。

實作一個軟體時,需求者應盡量提供原始情境:

1) 誰會使用這個軟體
2) 使用者在操作時會產生什麼情境。
3) 基本邏輯
4) 什麼是必要的,什麼是應該可以有的,什麼是完全不能做的。
5) 以 Story 敘述,而不是 Spec。

讓程式設計師,可以盡量出設計貼近可以解決原始需求(程式設計師稱之為『正確』)的方案。

好了。回到 Startup 與 Company 的話題。這套手法在 Company 行得通,也必須。因為中間需要經過太多的合作人員,所以我們要透過這樣的手段,盡量減少「翻譯」Cost。

Startup 本來就不是規模化自動化的階段

但是 Startup 需要 BDD 嗎?Startup 都沒人沒錢沒時間耗一天到晚在實驗新需求了,怎麼會是需要用到 BDD 這樣的技巧。Startup 所需要的是 Money Driven Development。只做賺錢必須的功能,找到幾個有錢賺的模式,能 Scale 需 Scale,那時候大家才有興致談 BDD 。

所以 Startup 前期應不應該導入 TDD / BDD?我現在認為這兩個名詞根本不是可以放在一起討論的東西。

就跟我覺得 Startup 跑 Scrum 是奇怪的做法一樣。

(我不是反 Scrum,Scrum 的一些手段對於釐清時程,Story ,權重。不管是專案大小都很有幫助。但是不是每個團隊都可以導入或適合這套流程的。)

← 做產品的一些雜談 用 EC2 上的 Windows 玩 GTA 5 →
 
comments powered by Disqus