如何確保系統開發失敗？

相關分享
1. 軟體顧問到底在顧什麼？https://revteltech.pse.is/sw-consult-what
2. 跨越不同領域的軟體開發經驗 https://revteltech.pse.is/crossdomain

忻旅科技軟體開發顧問：https://consult.revtel.tech/

近幾年看到蠻多光怪陸離的開發鬼故事，也見識過各種奇醜無比的失事原因。當中有些問題來自對方、有些問題來自自己，時時檢討總是沒錯。

這篇文章試著描述一下如果在顧問及開發時刻意要搞死合作案時可能會訂下哪些原則，算是幫自己設定一些邊界避免踩線（或者在面對機車對口作為行為準則？）。

原則一：已投入 > 再投入，面朝過去背著往前走

過往已發生的成本非常重要，並將相容於目前視為第一優先

在意過往的失敗及既有成本是人性，但卻未必理性。

很常有人說「前一手開發商跑掉/失敗了，但我已經花了 xxx 元 …」。當然不能直接回他關我屁事（？），只能提醒不同團隊的開發近乎獨立事件。此外，如果有這些經驗，積極作為應是分析是否前一次開發有預估失誤的地方才有可能避免重蹈覆轍。

而新開發被既有系統綑綁造成無法把事情做對也很常見，向下相容是一個隱性的詛咒。這在一些軟硬整合系統或者大型系統延伸時很常碰到。不是說不要考慮既有投入，但過往留下的程式碼不一定會對後續開發有幫助，這些程式碼可能是負債而不是資產。

善用軟體架構進行分解或隔離會是可行方向。

原則二：開局即終局，直上 production！

瞄準月亮，至少射中老鷹。直接在第一階段就將目標設定在可大規模商轉

軟體的可擴展、快速迭代及允許自由介接的特性常常給人一種可以用短時間快速打造出成品進而實現商業成功的感覺。

可這種感覺其實是錯覺。

在第一階段就把目標設定在 mass production 很容易出事，想要一步登天的結果往往是悲劇收場。雖然每個開發階段都該要有其核心方向，但像需求釐清、概念驗證、架構設計及人員訓練等諸多議題都得花費時間去對標。

畢竟真實開發畢竟是品質、速度及成本的取捨議題，切勿過度期待一次到位。

原則三：所謂的溝通就是指開會

盡量多進行會議討論以確保大家不會走偏

溝通是什麼？每週一固定的例會或者某些流派追求的每日站立會議嗎？如果僅是如此感覺不應該發生這麼多雞同鴨講的窘境。

其實很多開發到後來未必是出錯在解法不對，而是大家對題目的定義不同。在這種情況下討論再多只是浪費時間。

乍聽之下有點奇怪，但總結溝通失敗的案例，很大一部分是往往只做到了想法的「傳達」而已（這裏先放下方法論及個人因素等影響因素）。

有效的溝通應該是試著透過「表達」，取得對方「理解」之後進而達成「共識」。如果沒有真的讓彼此真的能聚焦在最終取得共識，各說各話的結果也就不難想像了。

原則四：致力追求 bug free — 你們怎麼會有 bug ?

軟體開發出來就應該是穩定的

這個點其實蠻好玩的，過往曾有傳產人士跟我提到說他們都是終身保，為何軟體不能做到這樣 （痾）。

軟體在開發時會面對很多動態的外在變化，如開發中的第三方介接或營運後的流量起伏。在給定的預算及時程限制下，能追求的應該是整體可控性，要做到無死角的包圍是不太可能的。以有窮逼近無窮可能不是科學問題而是神學問題。

「這不是 bug，這是 feature」常常是不得不接受的美麗哀愁。

原則五：線上的東西放著就能運作，維運只需考慮伺服器等剛性成本

軟體上線後只要不去碰它就能一直維持運作

這和上一個小節是相關聯的。系統開發可以想成是對將真實世界的問題抽象化，並在虛擬世界進行申論作答的過程。假如想要在每個時間點都能有好的答題品質，應該要維持源頭活水的不停持續修正。

換個角度思考，假如你開了一個實體店面，不論裝潢的多合心意，實際營運時還是得安排門市人員巡巡看看才能確保順利運作。甚至隨著客源變多，調整動線及小修小改也不在話下。

如果實體是如此，線上系統維運也應該有類似的概念才是。

反思：先追求不失敗再追求成功

軟體開發的規劃不存在絕對的正確做法，根據團隊的組成、預算的多寡、業務推廣的節奏及商業目標的設定有很多不同的作法。

因應之道應該是戰戰兢兢的把每一步踏穩再求前進。慢慢修正且小心避開一些誤區才能降低失敗的風險。

你有沒有遇過其他奇怪的開發鬼故事呢？