如何在開發討論看起來很厲害
更新於 發佈於 閱讀時間約 3 分鐘
軟體開發是在虛擬的空間重新描述並解決現時的問題，多數時候並不存在正確答案。如何穿越這些不確定及未知就體現了開發者的功力以及對事物的把握度。
過去的開發及顧問生涯跟很多形形色色的人合作，正向積極的討論固然有之，但也常碰到討論後反而讓事情變得更模糊的情況。當中部分的情形事後復盤覺得對方是有意為之，甚至可能出自於想要顯擺的奇怪心態。
標題有點聳動，但且以這篇短文紀錄幾個印象比較深的、飛一陣後發現什麼節論都沒得到的可能作法（？
所以其實是要反著看 …
如果去查詢 WIKI 上關於廢話的定義，大概如下
廢話（英語：Nonsense），即無意義的話。廢話指的是一段在當時情況下對事情發展沒有任何正面作用的語言，或者是在邏輯上矛盾的話。另外，亦指以文字或符號組成但不具備任何意義的聲音或句子，或可指某人。
當然把這些對於事情發展無益的話直接歸成廢話是有點武斷了。想表達的只是說有效的討論及溝通前提必定是建構在一致的背景理解及目標，如果無法真正的收斂，那結果可能確實與廢話也沒有差太遠。
以下列舉三個常碰到的情況跟大家分享
1.「你的架構有問題！」
這句真的是大殺器，搭配上莫測高深的表情效果不錯。聽到的人通常會先檢討自身。如果不夠有經驗甚至會直接掉入自我審查的泥淖 (然後越想越覺得有道理 …)。
說到底哪裡有百分之百完美的系統架構呢？假如真存在這麼一個完美的解，隨著成功架構帶來的紅利，也會逐漸使系統變得不完美。比如經典的 C10K 問題就會發生在取得一定的業務成功之後。
真實世界的開發是商業模式、領域知識、開發技術、成本規劃及流程管理的複合結果。「你的架構有問題」這句話如果為真，其實也只是描述一個結果，重要的是更細緻的拆分問題。
2. 多聊理念而不聊取捨
「你們要寫完整的測試再開發啦！」「你這個抽象層不夠清晰？」「你們這個的資安做到什麼地步？」「這樣效能會不會受到影響？」…
不知道大家會不會常聽到這些話？
其實這些都是很好的意見，但說實在過度強調往往會遮蔽真實發生的問題 — 比如時間或資源不足。這類型資訊太過的話很常其實會落入各說各話的情形，到最後可能只是在闡述自己在意什麼而不是什麼對解決當前問題有幫助。
有句話說得很好，「大家都不滿意的結果才是最好的結果」。系統開發亦然，更多時候是妥協取捨而不是理念之爭。
3. 聚焦在一些不太會發生的情境以示自己的滴水不漏
當今的軟體系統開發後，面對的外在環境變化往往超出想像。任何一個事前沒預料到的情境都可能造成問題。
您總有遇過死不更新手機的用戶對吧？這些 bug (?) 需要被解決嗎？
其實系統的正確運行，是環境、操作者與軟件本身三方面合作的結果。或者我們可以說，錯誤的發生是由於三者中有一方沒有正確履行自己的職責而導致的。假如以這個視角觀察，引入類似「契約」的概念的來理解系統，這些所謂的 bug 更可能是一種已知的未知。
而這並不是說我們可以不處理例外狀況，但一樣的，過度強調也是一種忽視現實考量的超譯。
當然這可能會讓你看起來很聰明（？
總結：時間有限，但問題無窮
系統開發的討論有他的迷人之處：一方面是工程及自然科學，背靠邏輯嚴謹性，另一方面又揉和了一些比較軟性的（甚至涉及到社會科學）開放議題。常常討論到後來不知道是在「盍各言爾志」還是真的有聚焦收斂。
作為一個工程開發人員，我們的目標往往明確，但內容卻充滿不確定。說到底我們時間有限，但面對的問題卻數都數不完。穿越那些無效的對話及話術才能省掉浪費。
您又聽過哪些似是而非的廢話呢？
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
「大家意見好多...要怎麼找到最佳解法?」
「叫我解決?根本沒想法啊!靈感枯竭啦!」
「難道沒有更好的解決方法嗎?」
「問題到底出在哪!?」
你是不是想找一套方法來解決問題或是構想創新方法呢？
「設計思考」也許就是你積極追求的解答，往下閱讀來初步認識這個新思維！
文章探討了建立良好的溝通互動，釐清了「討論」與「檢討」之間的差異，強調了對彼此需求和感受的關心與合作。藉由討論來找出方法靠近對方的需要，而非僅滿足自身需求。同時提到檢討別人並非有效的互動方式，只會在短期省力省時，但會在長期付出更大的成本。
重要的對話像是理念或政見的討論，通會都有以下三個共同點：
1. 一定會有歧異，參與對話的人不可能意見完全相同。
2. 對話過程感覺會很艱難、棘手。
3. 除了對話之外，還有後續其他的事要被完成，要導出實際的行動或改變
試著回想一下和別人進行重要的對話的經驗，結果如你預期嗎？相信不會每一次都順利。
親愛的讀者
感謝你提出這個問題。這是一個現代社會中很常見且重要的疑惑。隨著科技的迅猛發展，程式設計似乎成了人人必備的技能，讓許多人產生了焦慮和壓力。讓我們從多個角度深入探討這個問題，希望能為你解答心中的疑惑，並提供實用的建議。
專案失敗以往被定義為超期、超預算或無法結案，但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
系統的分析與規劃
在談到程式設計時，首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃，這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果，重要的是擁有對產業的清晰邏輯認識和深入了解。
進行深入了解
若要進行系統分析，必須對企業的設計和程式設計的對象進行深入了解，以充分理
本文探討了普通人和優秀人解決問題的差異，提出了大膽假設、小心求證、得出結論、進行調整的解決問題模式，並強調了不被利益或立場左右的重要性。
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
「大家意見好多...要怎麼找到最佳解法?」
「叫我解決?根本沒想法啊!靈感枯竭啦!」
「難道沒有更好的解決方法嗎?」
「問題到底出在哪!?」
你是不是想找一套方法來解決問題或是構想創新方法呢？
「設計思考」也許就是你積極追求的解答，往下閱讀來初步認識這個新思維！
文章探討了建立良好的溝通互動，釐清了「討論」與「檢討」之間的差異，強調了對彼此需求和感受的關心與合作。藉由討論來找出方法靠近對方的需要，而非僅滿足自身需求。同時提到檢討別人並非有效的互動方式，只會在短期省力省時，但會在長期付出更大的成本。
重要的對話像是理念或政見的討論，通會都有以下三個共同點：
1. 一定會有歧異，參與對話的人不可能意見完全相同。
2. 對話過程感覺會很艱難、棘手。
3. 除了對話之外，還有後續其他的事要被完成，要導出實際的行動或改變
試著回想一下和別人進行重要的對話的經驗，結果如你預期嗎？相信不會每一次都順利。
親愛的讀者
感謝你提出這個問題。這是一個現代社會中很常見且重要的疑惑。隨著科技的迅猛發展，程式設計似乎成了人人必備的技能，讓許多人產生了焦慮和壓力。讓我們從多個角度深入探討這個問題，希望能為你解答心中的疑惑，並提供實用的建議。
專案失敗以往被定義為超期、超預算或無法結案，但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
系統的分析與規劃
在談到程式設計時，首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃，這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果，重要的是擁有對產業的清晰邏輯認識和深入了解。
進行深入了解
若要進行系統分析，必須對企業的設計和程式設計的對象進行深入了解，以充分理
本文探討了普通人和優秀人解決問題的差異，提出了大膽假設、小心求證、得出結論、進行調整的解決問題模式，並強調了不被利益或立場左右的重要性。