寫程式就像蓋大樓，地基，設計圖都很重要，施工隊人員質量直接決定了樓的質量和進度，要規劃，出效果圖，最終由碼農一塊磚一塊磚搭建起來，想想蓋一棟樓有多複雜，你就可以想想寫一個程式有多難了！

在絕大多數的情況下，我認為程式設計師都沒有必要向一個非程式設計師的人員去解釋關於程式上的問題，因為對於不理解的人來說，你所說的任何內容，其實都是無字天書，他們完全不明白你到底在說什麼的。

尤其是當一個程式設計師回到家裡，千萬不要跟家裡的人去解釋這些事情，我們完全可以去找一些其他的事情去做，比如說聊聊風花雪月之類的。

當然如果這個人是你的老闆或者是產品經理的話，那麼你就很有必要去解釋了。

比如要學會類比，你可以說這樣一個簡單的程式就像一把斧頭，而這個複雜的程式就像一把電鋸，斧頭的使用是非常簡單的，而且也不容易損壞，但是它的效率極其的低下，但是電鋸的話呢就是另外一個那種東西了，首先它必須依賴電力才能夠運轉，而不能夠徒手使用。並且因為機械結構比較複雜，所以在使用的時候比較容易損壞，雖然說有這些缺點，但是它的效率是極其高的。

你需要透過類比這樣的方法，去給非程式人員去解釋這種問題。

當然，如果實在聽不懂的話，你也不必解釋了，只要按照他們說的做就行了。如果說老闆或者是產品經理實在是傻逼的話，那麼就換一家公司好了。

這種我認為很難，隔行如隔山。儘量避免去跟他直接溝通程式程式碼問題。因為那是在對牛彈琴。在講解的時候，先畫下核心程式業務流程圖，然後透過流程圖為切入點，跟其講解每個業務節點在執行的時候，我們程式在這個階段做了些什麼事，為什麼要在這個階段做這些事情，以及做的這些事情要消耗多長時間等等，如果按照這個思路講下去，故計應該能聽懂個大概。在跟其溝通時，儘量用通俗易懂的話跟他溝通，不要在溝通中帶有計算機專業術語。與這種小白溝通，儘量畫圖說明。

您好，關於這個問題，取決於你對於程式開發的認知能力和個人溝通能力。對於一個非程式設計師來說，他可能對程式開發流程一點都不清楚，但是他又對這一方面比較感興趣，樂意和你溝通，更有興趣去學習。這樣的話，無需去講的多麼深入，想要對方更快的理解和學習，就需要你用通俗的例項去舉例說明。如果舉例還不能解決問題，只能說明自己的溝通表達能力欠佳，還有待提高。

我覺得給外行人解釋一件專業的事情，是很困難的；比如給一個非程式設計師解釋軟體開發的過程，很多人認為一個軟體外表能看到的樣子，就是這個軟體的全部；所以很多人認為開發一個淘寶是一件很容易的事情。

如果要解釋清楚的話，最好能找到一個對方熟悉的事務流程做比較，這樣便於對方的理解。下面我就舉個例子，很多細節不一定很恰當：

軟體公司開發軟體=飯店做飯；

前者的產出物是軟體，後者產出物是飯菜；

業務人員=食客，都是業務的提出方；

需求人員=點菜服務員，他們都是記錄和分析客戶的需求；

程式設計師=廚師；

看起來廚師炒菜只花了五分鐘，但是飯店需要經歷採購、清洗、切好備用等一系列的操作；軟體開發也一樣，不要只看到表面看到的東西，可能一個APP只開發了兩週，但是後臺的介面服務已經積累了好幾幾個月甚至幾年；

食客有時候不知道要吃什麼，說“你給我介紹介紹你們的招牌菜”；業務人員有時候也不知道自己的需求是什麼；

食客說“不要放香菜”，但是服務員忘了記錄；需求人員也有犯錯的時候；

食客點完菜了，過了十分鐘說“菜裡別放辣椒”；開發人員做到一半的時候，需求變了；

廚師把鹽放少了，醬油放多了；程式設計師有一個情況沒有考慮到，有一個判斷寫錯了；

廚師說：“來，我再給你炒一盤。”；程式設計師說：“來，我把Bug改了。”

廚師為了不失業，沒事兒學學新菜；程式設計師為了不失業，沒事兒學學新技術...

總之，如果想給別人解釋清楚，那就得讓對方感同身受；但是這個過程會很累，所以借用老羅的一句話：“我只對兩種人解釋，第一類是親戚朋友，因為他們真的關心我，我給他們解釋一下，避免他們擔心我，第二類是警察。其他人，愛怎麼想怎麼想吧。”（大概的意思）