請多討論問題，而不是解決方案 - frankel

• 討論問題
• 評估備選解決方案
• 選擇最合適的一個。有時，這個步驟是利益相關者的責任。

"我想要一個Drupal"
當時，我正在為一個公共管理部門工作。請允許我不透露具體是哪一家。他們的流程規定，每個專案都應該有一個解決方案的架構師來實施上述工作流程。

有一天，一位專案經理要求與我會面，討論一個新專案。他對要解決的業務問題描述如下。"X部門的IT主管想要一個Drupal。他有很多權力，所以讓我們開始行動吧"。

不用說，我對他的做法多多少少有些驚訝。我試圖討論潛在的問題，但沒有任何結果。他並不想解決根本問題：他只想順從主任的心血來潮。

由於官僚主義的性質，他遵循的程式是需要解決方案的架構師來驗證任何解決方案。他只需要我批准主任想要的解決方案。我離開了房間；我不記得到底是怎麼結束的，但我沒有批准任何東西。

順便提一下，那些只是充當他人代理的人在組織中的投資回報率非常低，是零負值。有些組織往往比其他組織更能吸引他們。例如，沒有競爭的組織不會遭受任何低投資回報率的後果，往往會吸引他們很多，例如，公共管理部門。

.env檔案或不
我最近偶然發現了另一個例子。一位谷歌工程師寫了一篇文章，名字很有挑釁性："立即停止使用.env檔案！"。在這篇文章中，他解釋了.env檔案的問題以及如何使用配置伺服器來解決這些問題。

作為回應，另一位作者建立了另一篇文章，名為 "繼續像往常一樣使用.env檔案"。正如你所想象的，作者重點解釋了.env檔案是可以接受的，並描述了使用配置伺服器的問題。

最初的帖子幾乎沒有描述這個問題，在一個簡短的章節中加速了這個問題。而在其中，作者寫道。

>我甚至不需要解釋為什麼這很糟糕

對不起，但不遺憾：的確，你要解釋

說實話，駁斥的帖子並沒有做得更好。兩人都專注於他們最喜愛的解決方案，但都沒有出色地解釋他們的問題，在他們的背景下。

PS：根本問題是.env檔案管理並不能擴充套件，這對於像谷歌這樣規模的組織來說，這是一個大問題；對於一個小組織來說，他們是沒有問題的。

微服務是解決不多問題的辦法
我們很難忽視微服務的熱潮。很多人評論微服務的優點和缺點；很少有人寫他們為什麼實施微服務。

在以前的文章中，我總是小心翼翼地解釋為什麼微服務在大多陣列織中是一個糟糕的想法。也許我沒有討論微服務所解決的問題，所以就在這裡。

成功的組織確實在成長。大多數時候，為了支援業務增長，開發人員的團隊也會隨之增長。在某一時刻，團隊必須分成幾個子團隊來處理增長問題。對，這就是問題所在。

現在，很多開發人員必須在同一個程式碼庫上工作。歷史上，我們透過以下方式處理這種複雜性。

不同的開發流程，例如，Git流程、GitHub流程、GitLab流程
由專人負責管理複雜的釋出管理
我的經驗告訴我，這種方法可以擴充套件......到一定程度。當開發人員的數量達到~70人時，我目睹了經驗豐富的開發人員團隊的同步問題。也許其他人有不同的經驗。

在任何情況下，這是我們需要討論的核心問題。只有這樣，我們才能決定哪些替代方案可以解決開發團隊的增長問題。

在技術支援中質疑問題
即使在技術支援中，也應該首先討論問題。支援確實經常直截了當地回答所問的問題。我認為這是最糟糕的事情：它可能會完全跳過根本問題，提供一個不合格的解決方案。

這裡有一個例子，取自StackOverflow：

我想新增一個從git拉來的專案，然後用Maven構建，問題是他們的pom.xml同時使用了私有和公共repo，他們告訴我刪除私有repo來構建，這樣就可以了，但我想用Jenkins自動構建過程。 — How to remove repo from pom.xml before building

答案集中在如何從pom.xml中刪除東西上，因為這就是那個人問的。但問題是不同的：它是如何構建一個引用了自己沒有訪問許可權的倉庫的專案。刪除XML行是眾多解決方案中的一個，但我認為這不是最優雅的一個。

我可能會提議在Maven的設定中配置一個映象。

Five whys
要想把重點放在解決方案而不是問題上，我認為應該採用五個為什麼的方法。

五個為什麼Five whys是一種反覆詢問的技術，用於探索某一特定問題背後的因果關係。該技術的主要目標是透過重複五次 "為什麼？"的問題來確定缺陷或問題的根本原因。對第五個 "為什麼 "的回答應該揭示出問題的根本原因。
- https://en.wikipedia.org/wiki/Five_whys

IMHO，一個人不需要五個為什麼來談論問題而不是解決方案。有幾個就夠了。透過走訪問題的解決方案，你會發現很多背景，並可能改變一個思想開放的利益相關者的推理。

此外，你可能會注意到，在某些情況下，一個非IT的解決方案將是最合適的。記住，最好的程式碼就是沒有程式碼。

總結
工程師們喜歡談論他們喜歡的解決方案。然而，在沒有背景的情況下對解決方案提出異議是沒有用的。在不討論問題的情況下同意一個解決方案甚至更糟。

討論問題為了解問題的本質提供了寶貴的洞察力。如果你想帶來更多的價值，你應該花更多的時間質疑問題是什麼。