如何確保系統開發失敗
閱讀時間約 4 分鐘
相關分享
1. 軟體顧問到底在顧什麼？https://revteltech.pse.is/sw-consult-what
2. 跨越不同領域的軟體開發經驗 https://revteltech.pse.is/crossdomain
近幾年看到蠻多光怪陸離的開發鬼故事，也見識過各種奇醜無比的失事原因。當中有些問題來自對方、有些問題來自自己，時時檢討總是沒錯。
這篇文章試著描述一下如果在顧問及開發時刻意要搞死合作案時可能會訂下哪些原則，算是幫自己設定一些邊界避免踩線（或者在面對機車對口作為行為準則？）。
原則一：已投入 > 再投入，面朝過去背著往前走
過往已發生的成本非常重要，並將相容於目前視為第一優先
在意過往的失敗及既有成本是人性，但卻未必理性。
很常有人說「前一手開發商跑掉/失敗了，但我已經花了 xxx 元 …」。當然不能直接回他關我屁事（？），只能提醒不同團隊的開發近乎獨立事件。此外，如果有這些經驗，積極作為應是分析是否前一次開發有預估失誤的地方才有可能避免重蹈覆轍。
而新開發被既有系統綑綁造成無法把事情做對也很常見，向下相容是一個隱性的詛咒。這在一些軟硬整合系統或者大型系統延伸時很常碰到。不是說不要考慮既有投入，但過往留下的程式碼不一定會對後續開發有幫助，這些程式碼可能是負債而不是資產。
善用軟體架構進行分解或隔離會是可行方向。
原則二：開局即終局，直上 production！
瞄準月亮，至少射中老鷹。直接在第一階段就將目標設定在可大規模商轉
軟體的可擴展、快速迭代及允許自由介接的特性常常給人一種可以用短時間快速打造出成品進而實現商業成功的感覺。
可這種感覺其實是錯覺。
在第一階段就把目標設定在 mass production 很容易出事，想要一步登天的結果往往是悲劇收場。雖然每個開發階段都該要有其核心方向，但像需求釐清、概念驗證、架構設計及人員訓練等諸多議題都得花費時間去對標。
畢竟真實開發畢竟是品質、速度及成本的取捨議題，切勿過度期待一次到位。
原則三：所謂的溝通就是指開會
盡量多進行會議討論以確保大家不會走偏
溝通是什麼？每週一固定的例會或者某些流派追求的每日站立會議嗎？如果僅是如此感覺不應該發生這麼多雞同鴨講的窘境。
其實很多開發到後來未必是出錯在解法不對，而是大家對題目的定義不同。在這種情況下討論再多只是浪費時間。
乍聽之下有點奇怪，但總結溝通失敗的案例，很大一部分是往往只做到了想法的「傳達」而已（這裏先放下方法論及個人因素等影響因素）。
有效的溝通應該是試著透過「表達」，取得對方「理解」之後進而達成「共識」。如果沒有真的讓彼此真的能聚焦在最終取得共識，各說各話的結果也就不難想像了。
原則四：致力追求 bug free — 你們怎麼會有 bug ?
軟體開發出來就應該是穩定的
這個點其實蠻好玩的，過往曾有傳產人士跟我提到說他們都是終身保，為何軟體不能做到這樣 （痾）。
軟體在開發時會面對很多動態的外在變化，如開發中的第三方介接或營運後的流量起伏。在給定的預算及時程限制下，能追求的應該是整體可控性，要做到無死角的包圍是不太可能的。以有窮逼近無窮可能不是科學問題而是神學問題。
「這不是 bug，這是 feature」常常是不得不接受的美麗哀愁。
原則五：線上的東西放著就能運作，維運只需考慮伺服器等剛性成本
軟體上線後只要不去碰它就能一直維持運作
這和上一個小節是相關聯的。系統開發可以想成是對將真實世界的問題抽象化，並在虛擬世界進行申論作答的過程。假如想要在每個時間點都能有好的答題品質，應該要維持源頭活水的不停持續修正。
換個角度思考，假如你開了一個實體店面，不論裝潢的多合心意，實際營運時還是得安排門市人員巡巡看看才能確保順利運作。甚至隨著客源變多，調整動線及小修小改也不在話下。
如果實體是如此，線上系統維運也應該有類似的概念才是。
反思：先追求不失敗再追求成功
軟體開發的規劃不存在絕對的正確做法，根據團隊的組成、預算的多寡、業務推廣的節奏及商業目標的設定有很多不同的作法。
因應之道應該是戰戰兢兢的把每一步踏穩再求前進。慢慢修正且小心避開一些誤區才能降低失敗的風險。
你有沒有遇過其他奇怪的開發鬼故事呢？
RevtelTech 忻旅科技 https://www.revtel.tech/
email：contact@revteltech.com
facebook：https://www.facebook.com/RevtelTech/
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
今天想跟大家聊聊軟體開發中那些年大家踩過的「坑」，沒錯，就是那些看不見的陷阱，常常搞得我們焦頭爛額的坑，痛到想哭。
需求改來改去
本來覺得這次的需求挺清楚，覺得「這很簡單，幾天就能搞定」，結果寫完第一個版本，需求就改了。還沒喘口氣，需求又變了！連改了五六次，改到懷疑人生。
會議太多，程
你有沒有遇過這樣的情況？當你設計一個系統時，一開始覺得一切順利，結果過了不久，客戶突然要求增加新功能。問題來了，每次改需求，你的程式碼都變得一團混亂，越改越多錯誤，最後讓你崩潰了。
軟體開發中需求變動是常態，但每次修改都得動到核心程式碼，難免會增加出錯的風險，也讓開發效率大打折扣。今天就要來聊聊「
「所以，你想要用A框架，但又覺得B框架也不錯？」David挑眉問道，一臉的疑惑和一絲不易察覺的笑意。
....
David神秘地笑了笑，「技術選擇可不是簡單的喜好問題，它牽扯到技術轉移的成本、技術負債的累積，還有整個團隊的長期發展。先來聽聽我的想法吧。」
在專案管理中，如何有效經營利害關係人是確保專案成功的關鍵。這篇文章分享了一些技巧，包括識別利害關係人、設定期望、保持良好溝通及找到共同利益等策略，幫助讀者在專案中建立良好的關係，減少誤解和不必要的驚喜，最終達成專案目標。
你是否曾提案要為客戶做許多事，卻得不到客戶買單或認同。
或是簽了約，客戶要你做更多事，或是與合約不相符？
據國際專管機構統計至少80%專案執行失敗，表示專案成功機率20%是偏低的，因為在一個充滿變數的商業環境中，如果你公司面臨著一個重大的挑戰。
專案失敗以往被定義為超期、超預算或無法結案，但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
軟體開發專案管理的失敗原因複雜多樣，但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步，需對軟體開發專案的特徵進行評估，選擇合適的軟體開發生命週期和專案管理方法。
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
今天想跟大家聊聊軟體開發中那些年大家踩過的「坑」，沒錯，就是那些看不見的陷阱，常常搞得我們焦頭爛額的坑，痛到想哭。
需求改來改去
本來覺得這次的需求挺清楚，覺得「這很簡單，幾天就能搞定」，結果寫完第一個版本，需求就改了。還沒喘口氣，需求又變了！連改了五六次，改到懷疑人生。
會議太多，程
你有沒有遇過這樣的情況？當你設計一個系統時，一開始覺得一切順利，結果過了不久，客戶突然要求增加新功能。問題來了，每次改需求，你的程式碼都變得一團混亂，越改越多錯誤，最後讓你崩潰了。
軟體開發中需求變動是常態，但每次修改都得動到核心程式碼，難免會增加出錯的風險，也讓開發效率大打折扣。今天就要來聊聊「
「所以，你想要用A框架，但又覺得B框架也不錯？」David挑眉問道，一臉的疑惑和一絲不易察覺的笑意。
....
David神秘地笑了笑，「技術選擇可不是簡單的喜好問題，它牽扯到技術轉移的成本、技術負債的累積，還有整個團隊的長期發展。先來聽聽我的想法吧。」
在專案管理中，如何有效經營利害關係人是確保專案成功的關鍵。這篇文章分享了一些技巧，包括識別利害關係人、設定期望、保持良好溝通及找到共同利益等策略，幫助讀者在專案中建立良好的關係，減少誤解和不必要的驚喜，最終達成專案目標。
你是否曾提案要為客戶做許多事，卻得不到客戶買單或認同。
或是簽了約，客戶要你做更多事，或是與合約不相符？
據國際專管機構統計至少80%專案執行失敗，表示專案成功機率20%是偏低的，因為在一個充滿變數的商業環境中，如果你公司面臨著一個重大的挑戰。
專案失敗以往被定義為超期、超預算或無法結案，但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
軟體開發專案管理的失敗原因複雜多樣，但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步，需對軟體開發專案的特徵進行評估，選擇合適的軟體開發生命週期和專案管理方法。
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式